Налаштування реплікації Master-Slave PostgreSQL з автоматичним failover

Ваше веб-застосунок зростає: 10 000 запитів на секунду, база задихається, LCP виріс до 3 секунд. Користувачі йдуть. Рішення – налаштування реплікації Master-Slave на PostgreSQL. При цьому економія на обладнанні для читання становить до 40% – репліки можуть бути на дешевих інстансах. Ми, команда з 5-річним досвідом (понад 50 проєктів з високонавантаженими системами), налаштуємо відмовостійкий кластер за 2-3 дні. Зв'яжіться для безкоштовного аудиту вашої інфраструктури.

Чому варто обрати реплікацію Master-Slave?

При навантаженні на читання до 10 000 запитів на секунду реплікація знижує LCP з 3 секунд до 200 мс. Використовуємо hot standby – репліка приймає SELECT-запити, розвантажуючи primary. Синхронна реплікація гарантує нульову втрату даних, але споживає на 30% більше ресурсів через очікування підтвердження. Асинхронна – швидша, але допускає втрату останньої транзакції (менше 1% втрат при збої). Вибір залежить від вимог до консистентності: для фінансів – синхронна, для вебу – асинхронна. Економія бюджету на інфраструктурі за рахунок використання реплік для читання досягає 30-50%.

Як налаштувати автоматичний failover з Patroni?

Patroni – стандарт для автоматичного failover PostgreSQL в production. Він використовує distributed lock через etcd. При відмові primary Patroni автоматично промоутить репліку з найменшим лагом. Це мінімізує downtime до 10 секунд. Вартість експлуатації знижується на 40% за рахунок використання реплік для читання та відсутності дорогого обладнання для відмовостійкості.

Кроки налаштування Patroni:

1. Розгорнути etcd кластер з 3 вузлів.
2. Встановити Patroni на кожен сервер PostgreSQL.
3. Налаштувати патроні-конфіг з вказівкою etcd.
4. Запустити Patroni – він автоматично обере master.
5. Налаштувати HAProxy для маршрутизації запитів до master та реплік.

Як ми налаштовуємо реплікацію?

Архітектура: застосунок пише тільки на primary, читання – на репліки. WAL передається потоково з використанням streaming replication.

Налаштування Primary

postgresql.conf:

wal_level = replica
max_wal_senders = 5
wal_keep_size = 1GB
max_replication_slots = 5
synchronous_commit = on

pg_hba.conf:

host replication replicator 10.0.1.0/24 scram-sha-256

Створюємо користувача реплікації:

CREATE ROLE replicator WITH REPLICATION LOGIN PASSWORD 'strong_password';

Налаштування Replica (PostgreSQL 12+)

Виконуємо pg_basebackup для початкової синхронізації. Прапор -R створює standby.signal та додає primary_conninfo:

pg_basebackup -h 10.0.1.10 -U replicator -D /var/lib/postgresql/14/main -P -Xs -R

postgresql.conf на репліці:

hot_standby = on
hot_standby_feedback = on
max_standby_streaming_delay = 30s

Моніторинг та керування

Реплікаційні слоти гарантують, що primary не видалить WAL-сегменти, доки вони не будуть отримані реплікою. Без слотів при перезавантаженні репліки primary може видалити невідправлені журнали, що призведе до необхідності повної повторної синхронізації. Слоти особливо важливі при асинхронній реплікації та частих простоях реплік. Моніторинг лагу:

-- Моніторинг реплікаційних слотів
SELECT slot_name, active, restart_lsn, confirmed_flush_lsn,
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS lag_bytes
FROM pg_replication_slots;

-- Моніторинг лагу реплік
SELECT application_name, client_addr, state, write_lag, flush_lag, replay_lag
FROM pg_stat_replication;

Порівняння синхронної та асинхронної реплікації

Порівняння інструментів failover

Що дає автоматичний failover з Patroni?

Автоматичний failover з Patroni виключає ручне втручання при збої primary. Час простою скорочується до 10 секунд, що критично для сервісів з вимогами 99.9% uptime. Крім того, Patroni дозволяє виконувати планові перемикання без зупинки застосунку.

Що входить в роботу?

• Розгортання Master та 1-2 реплік з оптимізацією параметрів wal.
• Конфігурація pg_hba, реплікаційних слотів та моніторингу.
• Налаштування PgBouncer для пулювання з'єднань та маршрутизації запитів.
• Встановлення та налаштування Patroni з etcd для автоматичного failover.
• Інтеграція з застосунком: налаштування read/write routing.
• Моніторинг лагу та продуктивності (Prometheus + Grafana).
• Документація по експлуатації та навчання вашого адміністратора.

Терміни та вартість

• Базове налаштування (Master + 1 репліка, без failover): 1 день.
• Повноцінний кластер з Patroni та моніторингом: 2-3 дні.

Вартість розраховується індивідуально і залежить від складності інфраструктури. Отримайте консультацію – ми безкоштовно проаналізуємо ваш проєкт і запропонуємо оптимальне рішення. Замовте налаштування зараз і забезпечте uptime 99.9%!

Кілька слів про наш досвід

Ми виконали понад 50 проєктів з налаштування кластерів PostgreSQL для веб-застосунків з навантаженням до 100 000 запитів на секунду. Наші інженери мають сертифікати PostgreSQL Professional і регулярно виступають на профільних конференціях. Гарантуємо якість та підтримку після запуску.

Послуги бекенд-розробки: production-grade надійність

На production-сервері о 3:14 ночі черга Laravel Jobs перестала оброблятися — 40 000 необроблених завдань у Redis. Причина: worker упав через memory leak у статичній змінній Eloquent observer, supervisor не перезапустив через misconfigured stopwaitsecs. Ми розбирали такий інцидент на проекті з 500 RPS: діагностика 4 години, фікс — 20 хвилин. Щоб ви не втрачали гроші, пропонуємо послуги бекенд-розробки з акцентом на production-grade надійність — 10+ років досвіду, 50+ проектів, 5 років на ринку. Оцінимо ваш проект за 2 дні.

Які проблеми вирішуємо

N+1 запити: головний вбивця швидкості

N+1 — найпоширеніша причина повільних сторінок у Laravel-додатках. Стандартна історія: сторінка працювала нормально на dev з 10 записами, на production з 10 000 — 8-секундне завантаження.

Laravel Debugbar у dev-оточенні показує кількість запитів. Більше 20 — сигнал для audit.

Model::preventLazyLoading(! app()->isProduction());

Telescope для профілювання: логує всі запити, jobs, mail, notifications з деталізацією. Після впровадження eager loading час завантаження сторінки падає з 8 с до 0.3 с — у 27 разів.

Memory leak у статичних змінних

У Laravel Octane або Swoole додаток тримається в пам’яті між запитами. Статичні змінні не скидаються — призводять до неконтрольованого росту пам’яті. Використовуємо defer-функції та контейнерні біндинги для коректного скидання стану.

Неправильний connection pool

Rails, Laravel, Django відкривають нове з'єднання PostgreSQL на кожен PHP/Python процес. 100 воркерів — 100 з'єднань. PostgreSQL деградує від 200+ активних з'єднань через overhead на управління.

PgBouncer у transaction pooling: 1000 воркерів → 20–50 реальних з'єднань. Це знижує latency на 40% та зменшує витрати на хостинг на 30% — при середній вартості хостингу $2,000/міс економить $600/міс. GIN-індекс для JSONB до 100 разів швидший за B-tree при пошуку.

Як Octane справляється з високим навантаженням?

Laravel Octane (RoadRunner або Swoole) прибирає overhead bootstrap на кожен HTTP-запит. Приріст: 3–8x на синтетичних бенчмарках, 2–4x на реальних додатках. Важливо: не зберігати стан у статичних змінних — застосовуємо це на проектах >1000 RPS.

Як PostgreSQL допомагає уникнути повільних запитів?

Використовуємо composite indexes для WHERE + ORDER BY, partial indexes для фільтрів з високою селективністю, GIN-індекси для JSONB та full-text search. to_tsvector + GIN замість LIKE '%query%' — запобігає seq scan навіть на мільйонах записів. Аналізуємо плани через EXPLAIN ANALYZE та pg_stat_statements.

Як обрати стек для вашого проекту?

Node.js виправданий для realtime: Laravel публікує події в Redis Pub/Sub, Node.js підписується та транслює клієнтам. Go — для goroutines (10k з'єднань на сервер — норма), але розробка повільніша, ніж Laravel.

Чому Redis критичний для продуктивності?

Redis виконує кілька ролей:

Redis Cluster для горизонтального масштабування, Sentinel для автоматичного failover. Замовте консультацію щодо оптимізації Redis для вашого проекту.

Що входить в роботу під ключ

• Архітектурне проектування (документація API, схема БД, діаграма сервісів)
• Реалізація за узгодженим ТЗ з code review
• Налаштування CI/CD (GitHub Actions, Docker), моніторингу (Sentry, Grafana), алертингу
• Навантажувальне тестування (k6, wrk) зі звітом
• Передача вихідних кодів, доступів, інструкція з деплою
• Навчання команди замовника (2–3 сесії)
• Гарантійна підтримка 1 місяць після здачі

Орієнтири по термінах

Вартість розраховується індивідуально після аналізу вимог до навантаження, інтеграцій та бізнес-логіки. Зв'яжіться з нами для безкоштовного аудиту вашого поточного backend — отримайте план оптимізації за 2 дні. Замовте консультацію та дізнайтеся, як знизити витрати на інфраструктуру на 30% без втрати продуктивності.