Професійні послуги з адміністрування баз даних

Адміністрування PostgreSQL, MySQL, MongoDB, Redis, Elasticsearch

Уявіть: реплікацію налаштовано, бекап за розкладом, моніторинг показує зелений. А потім primary‑нода PostgreSQL падає о 3 ночі, replica не перемикається автоматично — replication slot завис, LSN відстав на 8 годин. Додаток деградує, DBA отримує дзвінок. Це знайома ситуація. Ми вирішуємо такі проблеми щодня. За 5 років ми провели понад 120 проєктів з database‑інфраструктури — від стартапів до enterprise з петабайтами даних.

Більшість проблем з базами даних у production — не баги самої СУБД, а неправильно налаштована HA‑конфігурація, відсутність connection pooling під навантаженням та ігнорування query planner hints до моменту, коли запит починає займати 30 секунд замість 300ms. Нижче розберемо типові сценарії та наші рішення.

Чому варто налаштувати PostgreSQL HA через Patroni?

Patroni — де‑факто стандарт для PostgreSQL HA в Kubernetes і bare metal. Він керує leader election через DCS (etcd, Consul або ZooKeeper). Один лідер приймає запис, інші — hot standby зі streaming replication. Якщо лідер не відповідає на healthcheck довше за ttl секунд — Patroni ініціює вибори і промоутить найкращу репліку. Автоматичний failover відбувається за 30 секунд — у 10 разів швидше ніж ручне перемикання, яке часто займає хвилини.

Типова конфігурація трьохнодового кластера:

scope: postgres-ha name: pg-node-1 restapi: listen: 0.0.0.0:8008 connect_address: 10.0.1.1:8008 etcd3: hosts: 10.0.0.10:2379,10.0.0.11:2379,10.0.0.12:2379 bootstrap: dcs: ttl: 30 loop_wait: 10 retry_timeout: 10 maximum_lag_on_failover: 1048576 # 1МБ — репліка з відставанням > 1МБ не стане лідером postgresql: use_pg_rewind: true parameters: max_connections: 200 shared_buffers: 4GB wal_level: replica hot_standby: "on" wal_keep_size: 2GB synchronous_commit: "on" postgresql: listen: 0.0.0.0:5432 connect_address: 10.0.1.1:5432 data_dir: /data/postgresql/14/main pg_hba: - host replication replicator 10.0.0.0/24 md5 - host all all 0.0.0.0/0 md5 

Параметр maximum_lag_on_failover: 1048576 — один мегабайт WAL‑відставання. Репліка, що відстала більше, не промоутиться, щоб не втратити транзакції. Для нульових втрат потрібен synchronous_standby_names.

Ще одна проблема, яку всі ігнорують: replication slots. Якщо додаток підключений до репліки через logical replication slot і репліка лагає — slot на primary тримає WAL‑файли, і диск заповнюється до відмови. PostgreSQL не видаляє WAL доки slot не звільнено. Рішення: моніторити pg_replication_slots і виставити max_slot_wal_keep_size в PostgreSQL 13+:

SELECT slot_name, active, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS lag FROM pg_replication_slots ORDER BY lag DESC; SELECT pg_drop_replication_slot('slot_name'); -- обережно — втрата даних для підписника 

Як уникнути connection exhaustion з PgBouncer?

PostgreSQL створює окремий процес на кожне підключення. При 500 одночасних з'єднаннях з shared_buffers=4GB витрачається ~500MB тільки на proc structures. Додатки на Node.js або Go з connection pool по 20 підключень на інстанс при 30 інстансах дають 600 підключень — і max_connections=200 повертає FATAL: sorry, too many clients already.

PgBouncer в режимі transaction pooling тримає N підключень до PostgreSQL і мультиплексує тисячі клієнтських сесій:

[databases] mydb = host=10.0.1.1 port=5432 dbname=mydb [pgbouncer] pool_mode = transaction max_client_conn = 2000 default_pool_size = 50 reserve_pool_size = 10 reserve_pool_timeout = 5 server_idle_timeout = 600 log_connections = 0 log_disconnections = 0 

Обмеження transaction pooling: не можна використовувати SET LOCAL, LISTEN/NOTIFY, advisory locks та prepared statements без server_reset_query. Це потрібно враховувати при міграції.

Як обрати топологію HA: Patroni, Redis Cluster чи ReplicaSet?

Кожна СУБД має власні підходи до високої доступності. PostgreSQL — Patroni, Redis — Cluster, MongoDB — Replica Set. Вибір залежить від вимог до консистентності, latency та бюджету.

Для критичних даних PostgreSQL + Patroni з synchronous_commit — єдиний варіант з нульовими втратами. Для кеша з високою пропускною здатністю Redis Cluster без персистентності дає ~100k ops/sec. Для документів з гнучкою схемою — MongoDB Replica Set з w: "majority".

Redis Cluster: шардування та gotchas

Redis Cluster ділить keyspace на 16384 хеш‑слоти, розподілені по мастер‑нодах. Мінімальна конфігурація — 3 мастери + 3 репліки. Кожен ключ маппиться через CRC16(key) mod 16384.

Найчастіша помилка — CROSSSLOT на мультиключових операціях. MGET key1 key2 key3 впаде, якщо ключі потрапляють на різні слоти. Рішення — hash tags: {user:123}:session та {user:123}:cart гарантовано на один слот, тому що Cluster дивиться тільки на частину в {}.

# Створення кластера redis-cli --cluster create \ 10.0.1.1:6379 10.0.1.2:6379 10.0.1.3:6379 \ 10.0.1.4:6379 10.0.1.5:6379 10.0.1.6:6379 \ --cluster-replicas 1 

Redis Cluster не підтримує database 0‑15 (лише db 0), Lua scripts з ключами на різних слотах і SCAN по всьому кластеру без перебору нод. Якщо потрібні ці можливості — розгляньте KeyDB або Valkey як drop‑in replacement з multi‑threading. Для кеша персистентність часто вимикають (save "", appendonly no); для session storage — AOF з appendfsync everysec (втрата 1 секунди даних прийнятна), для критичних даних — AOF з appendfsync always (падіння throughput з ~100k до ~10‑20k ops/sec).

Коли використовувати Redis Cluster, а коли — KeyDB?

Якщо вам потрібна масштабованість по slots — обирайте Redis Cluster. Якщо критична низька затримка на одній ноді і можливість використовувати всі бази — KeyDB дасть у 2‑3 рази більший throughput завдяки multi‑threading.

MongoDB та MySQL: коротко

MongoDB Replica Set з трьох нод — стандарт. Проблема: writeConcern: { w: 1 } — дані можуть загубитися при падінні primary. На production ми налаштовуємо w: "majority" і j: true. Індекси будуємо за порядком ESR (Equality → Sort → Range), інакше IXSCAN з in‑memory сортуванням.

MySQL в режимі Galera Cluster (Percona XtraDB Cluster) дає synchronous multi‑master, але вбиває write‑heavy навантаження certification conflicts. Альтернатива — InnoDB ReplicaSet з MySQL Router і Group Replication: менше гарантій, вище throughput.

Elasticsearch: управління індексами

Elasticsearch — не база даних. Спроби використовувати його як таку призводять до mapping explosions при dynamic: true. Ми вимикаємо dynamic, явно маппимо поля та налаштовуємо ILM для time‑series даних (rollover по 50GB/1 день, forcemerge в warm, freeze в cold, delete через 90 днів).

Що входить у результат

• Повністю працездатний HA‑кластер PostgreSQL з автоматичним failover
• PgBouncer з транзакційним пулінгом, налаштований під навантаження
• Моніторинг ключових метрик (lag, connection count, disk usage, WAL generation) через Prometheus + Grafana
• Runbook для типових операцій (ручний failover, відновлення з бекапу, додавання ноди)
• Скрипти бекапів з перевіркою цілісності (pg_verifybackup)
• Рекомендації щодо реплікації та шардування для MongoDB/Redis
• Супровід після налаштування: 2 тижні реактивної підтримки

Як ми налаштовуємо database layer: процес і результати

Наш процес включає чотири етапи:

1. Аудит — збираємо pg_stat_statements, SHOW STATUS LIKE 'Innodb%', перевіряємо реплікацію, бекапи, connection pooling, версії СУБД.
2. Проектування — обираємо топологію HA (Patroni, Redis Cluster, ReplicaSet), налаштовуємо DCS, моніторинг, alerting.
3. Реалізація — розгортаємо кластер, налаштовуємо PgBouncer, бекапи (pgBackRest, WAL‑G), тестуємо failover.
4. Документація та передача — віддаємо topology diagram, runbook failover, процедуру відновлення з реальними RTO/RPO, доступи до моніторингу.

Вартість розраховується індивідуально після аудиту інфраструктури. Типовий проєкт з налаштування PostgreSQL HA для інтернет‑магазину з 10 млн замовлень на місяць допоміг клієнту значно зменшити витрати на хмарні інстанси (до цього тримали 4 standalone БД для відмовостійкості, після міграції на Patroni з 3 нодами знизили витрати на 40% — щомісячна економія склала $2,500).

Оцінимо ваш проєкт — зв'яжіться з нами, щоб отримати консультацію та попередній розрахунок. Замовте аудит бази даних під ключ: за 2 дні ви отримаєте список проблем та план їх усунення. Наші інженери мають сертифікації PostgreSQL Professional та MongoDB Associate — гарантія якості на кожному етапі.