Проблеми з БД (shared Postgres / Valkey / Typesense)

Симптоми

Таймаути запитів у Abitly API / Strapi / Studsearch backend (часто одночасно — характерний індикатор shared-RDS).
too many connections.
Повільні відповіді API.
Помилки connection refused / SSL required.
BullMQ-задачі стоять у черзі (Valkey недоступний).
Пошук не повертає результати (Typesense).

Швидкий тріаж

Postgres живий? — aws rds describe-db-instances --db-instance-identifier studsearch-prod --query 'DBInstances[].{status:DBInstanceStatus,storage:AllocatedStorage,free:FreeStorageSpace}'.

Конекшени — підключитись через psql (з dev-bastion або локально з aws ssm start-session) і:

SELECT count(*), state FROM pg_stat_activity GROUP BY state;
SELECT pid, application_name, now()-query_start AS dur, query
  FROM pg_stat_activity WHERE state='active' ORDER BY dur DESC LIMIT 10;

Місце на диску — aws cloudwatch get-metric-statistics --metric-name FreeStorageSpace ....
Valkey — aws elasticache describe-cache-clusters --cache-cluster-id abitly-prod-cache --show-cache-node-info.
Typesense — curl https://<TYPESENSE_HOST>:<TYPESENSE_PORT>/health -H 'X-TYPESENSE-API-KEY: ...'.

Виправлення

Postgres

Симптом	Що робити
Завис довгий запит	Спочатку зрозуміти, який сервіс/схема. `SELECT pg_terminate_backend(<pid>)` — обережно, на чужій схемі може зламати інший сервіс.
Вичерпано пул конекшенів	Перевірити який саме сервіс відкрив максимум (`application_name`). Перезапустити тільки його сервіс (не торкатися інших).
Місце закінчується	Збільшити `AllocatedStorage` (`aws rds modify-db-instance --allocated-storage <new>`). Це не requires reboot на gp3.
Версія/тимчасова недоступність	Перевір `Pending modifications` (`aws rds describe-db-instances`).

Valkey

Симптом	Що робити
OOM / eviction	Перевірити `maxmemory` policy + ключі BullMQ (`BULL:*`). Можливо застрягли failed-jobs — почистити.
Pub/sub дроп	Можливий мережевий issue між ECS та ElastiCache (SG / route table).

Typesense

Одна EC2-інстанція, без replica → якщо впала, пошук повністю мовчить. Restart: aws ssm start-session --target i-0c5c322b1c3fbbe24 --profile abitly → перевірити docker/systemd.

DDL / міграції — критично

Координувати з власниками усіх трьох прод-сервісів. Спершу staging/dev, потім prod.
Ніколи не запускати DROP SCHEMA CASCADE чи DROP DATABASE — це знищить чужі дані.
TypeORM synchronize: true (в SSM /studsearch/prod/db/synchronize) — перевірити, що вимкнено в prod.

Ескалація

DBA / power-user: @Vladbandurin (поки що self — bus factor 1). Рекомендується явно зафіксувати backup-контакт коли команда виросте.
AWS Support: через AWS Console → Support Center (рівень підтримки TODO: — Developer/Business/Enterprise).

Профілактика

Connection-pool ліміти на сервіс (щоб один не з’їв усе).
Індекси на гарячих запитах.
Моніторинг pg_stat_activity у Grafana.
Регулярні automated RDS backups + Lambda abitly-dev-db-backup (S3 abitly-db-backups-v2).
Тримати t4g.small FreeStorageSpace > 5 GB (avg 25% reserved для WAL і temp).
Розглянути переходу на окремі RDS для prod-сервісів, якщо trade-off cost vs SPoF змінюється.