Ваше веб-приложение растёт: 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:
- Развернуть etcd кластер из 3 узлов.
- Установить Patroni на каждый сервер PostgreSQL.
- Настроить паттрони-конфиг с указанием etcd.
- Запустить Patroni — он автоматически выберет master.
- Настроить 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; Сравнение синхронной и асинхронной репликации
| Параметр | Синхронная репликация | Асинхронная репликация |
|---|---|---|
| Задержка записи | +30-50% | 0-5% |
| Потеря данных | 0 | ≤ 1 транзакция |
| Производительность чтения | Высокая | Высокая |
| Рекомендуется | Финансовые системы | Веб-приложения |
Сравнение инструментов failover
| Инструмент | Координация | Время failover | Сложность |
|---|---|---|---|
| Patroni | etcd/Consul | <10 с | Средняя |
| repmgr | Standalone | <30 с | Низкая |
| PAF (Pacemaker) | Corosync | <20 с | Высокая |
Что даёт автоматический 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 и регулярно выступают на профильных конференциях. Гарантируем качество и поддержку после запуска.