В мире высоконагруженных приложений и круглосуточной доступности простои базы данных недопустимы. Репликация PostgreSQL — это не просто резервное копирование, а мощный механизм создания отказоустойчивых, масштабируемых и высокопроизводительных систем. Давайте разберемся, как правильно настроить этот процесс, чтобы ваши данные были в безопасности, а приложение работало без перебоев.
Что такое репликация и зачем она нужна?
Репликация — это процесс постоянного копирования данных с одного сервера PostgreSQL (мастера) на один или несколько других серверов (реплик). Основные цели:
- Отказоустойчивость: При падении мастера реплика мгновенно становится новым основным сервером.
- Балансировка нагрузки: Реплики могут обслуживать запросы на чтение, разгружая мастер для операций записи.
- Геораспределение: Размещение реплик ближе к пользователям в разных регионах.
- Аналитика и отчетность: Тяжелые запросы можно выполнять на репликах, не влияя на основную транзакционную нагрузку.
PostgreSQL поддерживает несколько методов репликации: потоковая (streaming), логическая (logical) и с использованием слота репликации. Выбор зависит от ваших задач.
Настройка потоковой репликации (Streaming Replication)
Это самый популярный метод физической репликации на уровне WAL (Write-Ahead Logging).
Шаг 1: Подготовка мастера
На основном сервере отредактируйте postgresql.conf:
wal_level = replica(илиlogicalдля логической репликации)max_wal_senders = 5(количество одновременно подключаемых реплик + запас)wal_keep_size = 1GB(объем WAL-файлов, хранимых для реплик)listen_addresses = '*'или указание конкретных IP
В pg_hba.conf добавьте правило для подключения реплики:
host replication replica_user IP_реплики/32 md5
Создайте пользователя для репликации и перезапустите сервер:
CREATE USER replica_user WITH REPLICATION ENCRYPTED PASSWORD 'strong_password';
Шаг 2: Создание базовой копии на реплике
Остановите PostgreSQL на будущей реплике (если он был установлен) и выполните:
pg_basebackup -h IP_мастера -U replica_user -D /var/lib/postgresql/data -P -R
Ключ -R автоматически создаст файл standby.signal и настроит primary_conninfo в postgresql.auto.conf.
Всегда проверяйте, что на реплике достаточно свободного места перед выполнением pg_basebackup. Процесс может занять много времени на больших базах.
Шаг 3: Запуск и мониторинг
Запустите PostgreSQL на реплике. Проверить статус можно запросом на мастере:
SELECT client_addr, state, sync_state FROM pg_stat_replication;
Если вы видите строку с состоянием streaming — репликация работает!
Логическая репликация: Гибкость и выборочное копирование
В отличие от потоковой, логическая репликация работает на уровне таблиц и строк, позволяя:
- Реплицировать только определенные таблицы.
- Иметь разные схемы на мастере и реплике.
- Выполнять запись в реплику (с осторожностью).
Настройка включает создание публикации на мастере:
CREATE PUBLICATION my_pub FOR TABLE users, orders;
И подписки на реплике:
CREATE SUBSCRIPTION my_sub CONNECTION 'host=master dbname=mydb user=rep_user' PUBLICATION my_pub;
Автоматическое переключение при сбое (Failover)
Для автоматического переключения потребуются дополнительные инструменты:
- Patroni: Популярный фреймворк для управления кластерами PostgreSQL с поддержкой etcd, ZooKeeper.
- pg_auto_failover: Решение от создателей PostgreSQL для автоматического failover.
- Repmgr: Классический инструмент для репликации и управления failover.
Эти инструменты отслеживают состояние мастера и автоматически повышают реплику до мастера при его отказе.
Типичные проблемы и их решение
- Задержка репликации (replication lag): Увеличьте
wal_keep_size, проверьте сеть и нагрузку на реплику. - Реплика не поднимается: Проверьте пароли, права доступа в
pg_hba.confи наличие WAL-файлов на мастере. - Расхождение данных: При логической репликации — следите за конфликтами. Может потребоваться повторное создание подписки.
Регулярно тестируйте процедуру failover на стенде. Умение вручную переключить мастер-реплику в экстренной ситуации бесценно.
FAQ: Часто задаваемые вопросы
В чем разница между потоковой и логической репликацией?
Потоковая реплицирует все данные на физическом уровне (блоки диска), создавая точную бинарную копию. Логическая реплицирует изменения на уровне строк и таблиц, что дает гибкость, но может быть медленнее.
Можно ли писать данные в реплику?
В потоковой репликации — нет, она работает в режиме «только чтение». В логической репликации — технически да, но это может привести к конфликтам репликации. Обычно реплики используются для чтения.
Как выбрать между синхронной и асинхронной репликацией?
Синхронная (synchronous_commit = on) гарантирует, что транзакция на мастере подтвердится только после записи на реплику. Это дает максимальную надежность, но снижает производительность. Асинхронная — быстрее, но есть риск потери небольшого объема данных при аварии мастера.
Сколько реплик можно создать?
Теоретически — десятки. Практически — ограничено ресурсами мастера (параметр max_wal_senders) и сетью. Для большинства задач хватает 2-3 реплик.
Как мониторить репликацию?
Используйте системные представления pg_stat_replication (на мастере) и pg_stat_wal_receiver (на реплике). Также полезны мониторинговые системы вроде Zabbix, Prometheus с Grafana.