В мире высоконагруженных приложений и критически важных данных простои — это роскошь, которую нельзя себе позволить. Репликация PostgreSQL — это не просто функция, а фундаментальный механизм построения отказоустойчивых, масштабируемых и производительных систем. Давайте разберёмся, как правильно настроить этот мощный инструмент, превратив вашу базу данных в оплот стабильности.
Что такое репликация и зачем она нужна?
Репликация — это процесс постоянного копирования данных с одного сервера PostgreSQL (мастера) на один или несколько других серверов (реплик). Основные цели:
- Высокая доступность (High Availability): При падении мастера реплика мгновенно может стать новым основным сервером.
- Балансировка нагрузки (Load Balancing): Реплики могут обслуживать запросы на чтение, разгружая мастер для операций записи.
- Резервное копирование и восстановление: «Горячая» копия данных всегда готова.
- Геораспределение: Размещение реплик ближе к пользователям в разных регионах.
Основные методы репликации в PostgreSQL
1. Физическая репликация (Streaming Replication)
Самый популярный и надёжный метод. Репликация происходит на уровне файлов WAL (Write-Ahead Log). Реплика получает поток изменений (WAL-записи) от мастера и применяет их, поддерживая бинарно идентичную копию данных. Это синхронный или асинхронный процесс.
Важно: Физическая репликация реплицирует ВСЕ данные в кластере, включая все базы данных. Выборочную репликацию отдельных таблиц она не поддерживает.
2. Логическая репликация
Появилась в PostgreSQL 10. Реплицирует не файлы, а логические изменения (INSERT, UPDATE, DELETE) на уровне таблиц. Это позволяет:
- Реплицировать отдельные таблицы или даже части таблиц.
- Иметь разные версии PostgreSQL на мастере и реплике (с ограничениями).
- Отправлять данные из нескольких источников в одну таблицу (консолидация).
Пошаговая настройка физической репликации
Рассмотрим базовый сценарий «мастер-реплика» с асинхронной репликацией.
Шаг 1: Подготовка мастера (Primary)
В файле postgresql.conf на мастере необходимо установить:
wal_level = replica(илиlogicalдля логической репликации).max_wal_senders = 5(количество одновременных подключений от реплик).wal_keep_size = 1GB(сколько WAL-файлов хранить для отстающих реплик).listen_addresses = '*'или указать конкретный IP для подключения реплик.
Шаг 2: Настройка аутентификации
В файле pg_hba.conf на мастере добавить строку, разрешающую подключение реплики:
host replication replica_user IP_адрес_реплики/32 md5Создать пользователя для репликации на мастере: CREATE USER replica_user WITH REPLICATION ENCRYPTED PASSWORD 'strong_password';
Шаг 3: Создание базовой копии на реплике
Остановите PostgreSQL на будущей реплике (если он запущен). Выполните с реплики команду:
pg_basebackup -h IP_адрес_мастера -D /путь/к/data -U replica_user -P -v -R -WКлюч -R автоматически создаст файл standby.signal и настроит postgresql.auto.conf.
Совет: Для больших баз используйте флаг --wal-method=stream для параллельного копирования данных и WAL-файлов.
Шаг 4: Запуск и проверка
Запустите PostgreSQL на реплике. Проверьте статус репликации на мастере запросом:
SELECT client_addr, state, sync_state, replay_lag FROM pg_stat_replication;Если вы видите строку с IP вашей реплики и состоянием streaming — поздравляем, репликация работает!
Синхронная vs Асинхронная репликация
- Асинхронная (по умолчанию): Мастер подтверждает запись клиенту ДО того, как изменение будет получено репликой. Выше производительность, но есть риск потери данных при аварии мастера.
- Синхронная: Мастер ждёт подтверждения от одной или нескольких реплик, прежде чем подтвердить запись клиенту. Гарантия сохранности данных, но снижение производительности записи. Настраивается через параметр
synchronous_standby_names.
Мониторинг и устранение неполадок
Ключевые метрики:
- Replay Lag: Задержка применения WAL на реплике. Запрос:
SELECT pg_last_wal_replay_lsn(), pg_last_wal_receive_lsn(); - Статус реплики: Файл
pg_wal/recovery.signalна реплике означает, что она работает в режиме восстановления (репликации). - Логи: Всегда проверяйте логи PostgreSQL на обеих нодах (
log_directory).
Продвинутые сценарии: Каскадная репликация и HA-кластеры
PostgreSQL позволяет строить сложные топологии: реплика может, в свою очередь, быть мастером для других реплик (каскад). Для промышленного использования рассмотрите использование менеджеров кластеров (Patroni, repmgr), которые автоматизируют переключение при сбоях (failover) и мониторинг.
FAQ: Часто задаваемые вопросы
Можно ли писать на реплику?
Нет, физическая реплика по умолчанию доступна только для чтения. Для записи в несколько узлов нужны логическая репликация или сторонние решения (например, на основе BDR).
Что делать, если реплика отстала и не может догнать?
Если реплика отстала слишком сильно и мастер уже удалил необходимые WAL-файлы (контролируется wal_keep_size), репликацию придётся пересоздавать заново командой pg_basebackup.
Как выполнить переключение (failover) на реплику вручную?
1. Остановите мастер (или убедитесь, что он недоступен).
2. На реплике выполните: pg_ctl promote.
3. Файл standby.signal удалится, реплика станет самостоятельным мастером, готовым к записи.
Логическая или физическая репликация — что выбрать?
Физическая — для целостного резервирования всей БД и высокой доступности. Логическая — для выборочной репликации, обновления мажорных версий «на лету» или консолидации данных.