Настройка потоковой репликации PostgreSQL с репликационными слотами на Debian 10

Краткое определение: потоковая (streaming) репликация — это физическая репликация, при которой WAL-записи передаются в реальном времени от primary к standby. Репликационные слоты — механизм, который заставляет primary сохранять WAL, пока downstream не их не подтвердит.

Что вы получите

• Полное пошаговое руководство по установке PostgreSQL и настройке потоковой репликации с репликационными слотами на Debian 10.
• Проверки работоспособности, сценарии failover и отката.
• Рекомендации по безопасности, тест-кейсы, чеклисты для ролей и runbook восстановления.

Основные моменты

Важно: репликационные слоты предотвращают усечение WAL до того, как standby подтвердит их получение. Это снижает риск потери данных, но увеличивает использование дискового пространства на master, если standby долго отстаёт.

Заметки: во многих продуктивных окружениях используют мониторинг и alerting, чтобы отслеживать размер несобранных WAL и задействовать ручной или автоматический failover, если backlog растёт слишком сильно.

Требования

• Два одинаковых экземпляра Debian 10 (идентичные по железу/виртуализации предпочтительны).
• root-доступ на обоих узлах.
• Переменная окружения $EDITOR установлена на обоих узлах (для удобного редактирования конфигураций).

Краткий план действий

1. Установка PostgreSQL на оба узла.
2. Откройте доступ к сети и разрешите слушать внешний интерфейс.
3. На master: создайте роль репликации и репликационный слот.
4. На standby: снимите снимок данных (pg_basebackup) и настройте recovery.
5. Тестирование репликации и тестирование failover.

Шаг 1: Установка PostgreSQL

Обновите и перезагрузите оба узла:

apt update
apt upgrade -y
reboot

Установите Postgres на обоих узлах и убедитесь, что служба включена и запущена:

apt install -y postgresql
systemctl enable --now [email protected]

Важно: при обновлении PostgreSQL безопаснее обновлять standby первым.

Шаг 2: Начальная конфигурация сети

По умолчанию PostgreSQL слушает только loopback и недоступен извне. Откройте postgresql.conf на обоих узлах:

$EDITOR /etc/postgresql/11/main/postgresql.conf

Найдите строку:

#listen_addresses = 'localhost'

Измените на адреса узла и локалхост (вставьте IP узла):

listen_addresses = 'node_ip_address,127.0.0.1'

Если оба узла в одной приватной сети, используйте приватные адреса; иначе — публичные. Сохраните и перезапустите PostgreSQL на обоих узлах:

systemctl restart [email protected]

Шаг 3: Конфигурация master (primary)

Эти действия выполняются только на primary.

Откройте терминал Postgres:

sudo -u postgres psql

Создайте роль репликации, которую будет использовать standby:

postgres=# CREATE ROLE replicator LOGIN REPLICATION ENCRYPTED PASSWORD 'replicator_password';

Создайте физический репликационный слот и выйдите:

postgres=# SELECT * FROM pg_create_physical_replication_slot('replicator');
postgres=# \q

Для простоты имя роли и слота одинаковы — это не обязательно.

Добавьте запись в pg_hba.conf, чтобы разрешить подключение роли replicator с IP standby:

$EDITOR /etc/postgresql/11/main/pg_hba.conf

В конец добавьте:

host    replication replicator  standby_ip_address/32       md5

Перезапустите master:

systemctl restart [email protected]

Шаг 4: Базовый бэкап (на standby)

Действия выполняются на вторичном (standby) сервере.

Остановите PostgreSQL на standby:

systemctl stop [email protected]

Резервная копия старого каталога данных:

mv /var/lib/postgresql/11/main/ /var/lib/postgresql/11/main.bak

Склонируйте данные с master с помощью pg_basebackup. Обратите внимание на параметр –slot, который привязывает snapshot к репликационному слоту на master:

pg_basebackup -h master_ip_address -U replicator -D /var/lib/postgresql/11/main/ -P --password --slot replicator

Вас попросят ввести пароль, который вы указали при создании роли replicator на master.

После завершения передачи назначьте владельца каталогу:

chown -R postgres:postgres /var/lib/postgresql/11/main

Шаг 5: Конфигурация standby

Эти действия выполняются только на standby.

Включите режим hot standby в postgresql.conf:

$EDITOR /etc/postgresql/11/main/postgresql.conf

Найдите и раскомментируйте строку:

#hot_standby = on

Создайте файл recovery.conf в каталоге данных PostgreSQL:

$EDITOR /var/lib/postgresql/11/main/recovery.conf

Добавьте в него следующие параметры:

standby_mode = 'on'

Настройте соединение с master (вставьте реальные значения):

primary_conninfo = 'host=master_ip_address port=5432 user=replicator password=replicator_password'

Укажите имя репликационного слота, созданного на master:

primary_slot_name = 'replicator'

Опционально укажите файл-триггер для failover:

trigger_file = '/var/lib/postgresql/11/main/failover.trigger'

Если trigger_file указан, то создание этого файла заставит standby выйти из режима репликации и принять роль primary.

Назначьте права владельца файла recovery.conf:

chown postgres:postgres /var/lib/postgresql/11/main/recovery.conf

Запустите Postgres на standby:

systemctl start [email protected]

Теперь standby должен быть в режиме репликации и принимать WAL в реальном времени.

Тестирование

Тест репликации

На master выполните любую запись, например создайте базу данных:

sudo -u postgres psql -c "CREATE DATABASE replitest"

Через несколько секунд проверьте списки баз на standby:

sudo -u postgres psql -c "\l"

Вы должны увидеть созданную базу replitest. Пример вывода:

List of databases
   Name    |  Owner   | Encoding |   Collate   |    Ctype    |   Access privileges
-----------+----------+----------+-------------+-------------+-----------------------
 postgres  | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 |
 replitest | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 |
 template0 | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =c/postgres          +
           |          |          |             |             | postgres=CTc/postgres
 template1 | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =c/postgres          +
           |          |          |             |             | postgres=CTc/postgres
(4 rows)

Тест failover

До failover standby работает в режиме только для чтения. Попытка записи должна привести к ошибке:

sudo -u postgres psql -c "CREATE DATABASE test"

Ожидаемая ошибка:

ERROR:  cannot execute CREATE DATABASE in a read-only transaction

Чтобы инициировать failover, создайте trigger-файл на standby:

touch /var/lib/postgresql/11/main/failover.trigger

Через несколько секунд попытка записи должна пройти успешно:

sudo -u postgres psql -c "CREATE DATABASE test2"

Postgres переименует recovery.conf в recovery.done и удалит trigger-файл. Чтобы вернуть узел в режим standby, остановите Postgres, сбросьте каталог данных и выполните pg_basebackup снова, затем восстановите recovery.conf как показано далее.

Откат после failover (возврат в режим standby)

Остановите Postgres на (бывшем) secondary:

systemctl stop [email protected]

Сбросьте каталог данных и снимите новый бэкап с актуального master:

mv /var/lib/postgresql/11/main/ /var/lib/postgresql/11/main.2.bak
pg_basebackup -h master_ip_address -U replicator -D /var/lib/postgresql/11/main/ -P --password --slot replicator
chown -R postgres:postgres /var/lib/postgresql/11/main

При необходимости восстановите recovery.conf из recovery.done:

cp /var/lib/postgresql/11/main.2.bak/recovery.done /var/lib/postgresql/11/main/recovery.conf

И перезапустите Postgres:

systemctl start [email protected]

Теперь standby снова в режиме репликации.

Завершение

Удалите тестовые базы и старые каталоги данных, если они больше не нужны:

sudo -u postgres psql
postgres=# DROP DATABASE replitest;

И удалите резервные каталоги на standby:

rm /var/lib/postgresql/11/main.bak -r
rm /var/lib/postgresql/11/main.2.bak -r

Почему репликационные слоты важны

Репликационные слоты заставляют primary удерживать WAL, пока standby их не считал. Это особенно важно при:

• временных сетевых разрывах;
• длительном восстановлении standby после обслуживания;
• предотвращении потери данных между primary и standby.

Побочный эффект: если standby долго не доступен, на primary накопится много WAL-файлов и может закончиться место на диске. Планируйте мониторинг размера несобранных WAL.

Когда не использовать репликационные слоты

• Если у вас ограничено место на диске и standby может долго отсутствовать.
• Если вы используете асинхронную репликацию и допускаете потерю незафиксированных транзакций.
• Для краткосрочных тестовых окружений, где проще пересоздать standby.

Альтернативные подходы

• File-based log shipping: вы копируете WAL-файлы как файлы. Удобно при медленных линках.
• Logical replication: репликация отдельных таблиц и DDL не реплицируется автоматически.
• Использование сторонних инструментов (Barman, WAL-G, repmgr) для управления резервированием и failover.

Подход: мини-методология (шаги проверки перед вводом в прод)

1. Подготовка окружения: сети, firewall, права.
2. Установка и тест сервисов на каждом узле.
3. Создание роли репликации и слота на master.
4. Получение корректного basebackup на standby.
5. Включение и проверка hot_standby.
6. Тестовая запись и проверка на standby.
7. Тест failover и возврат в standby.
8. Настройка мониторинга и алертов.

Ролевые чеклисты

DBA:

• Убедиться, что версия PostgreSQL совпадает на обоих узлах.
• Создать роль replicator и слот.
• Настроить pg_hba.conf и протестировать подключение репликации.

Системный администратор:

• Настроить firewall (разрешить порт 5432 между узлами).
• Проверить системные лимиты (disk, inode).
• Настроить резервное копирование и мониторинг дискового пространства.

Разработчик/QA:

• Проверить, что данные реплицируются корректно для CRUD операций.
• Записать тест-кейсы, проверяющие видимость данных на standby.

Runbook восстановления и отката (быстрый сценарий)

1. Если standby не получает WAL и backlog растёт — оповестите команду и оцените причину.
2. Если проблема с сетью — восстановите связь или вставьте standby в режим catch-up после восстановления сети.
3. Если диск на master заполнен — временно остановите acceptor запросы, выполните очистку или перенос WAL (при использовании архивации). Не удаляйте слоты вручную без плана.
4. В случае failover: пометьте новый primary и переконфигурируйте другие standby на новый primary.

Тестовые случаи / Критерии приёмки

• После создания базы на master она видна на standby в течение допустимого времени (например, 30 с).
• При создании trigger-файла standby становится writable и сохраняет изменения.
• После отката standby снова подключается и реплицирует новые транзакции.
• Размер несобранных WAL не превышает допустимого порога в течение 24 часов.

Безопасность и права доступа

• Роль replicator должна иметь минимум прав — только LOGIN и REPLICATION.
• Подключения репликации должны ограничиваться IP-адресами через pg_hba.conf и сетевые ACL.
• Используйте шифрованные каналы (VPN/SSH туннелирование) при репликации через публичные сети.
• Регулярно проверяйте пароли и ключи; рассмотрите использование Kerberos или SSL для аутентификации.

Совместимость и миграция

• Инструкции приведены для PostgreSQL 11 на Debian 10. При других версиях пути и конфиги могут отличаться (/etc/postgresql/<версия>/main).
• При миграции между мажорными версиями используйте pg_upgrade или делайте логическую репликацию и переключение ролей по плану.
• Всегда тестируйте процедуру обновления в staging перед прод.

Быстрый список проверок перед вводом в эксплуатацию

• Версия PostgreSQL совпадает на обоих узлах.
• Настроены pg_hba.conf и listen_addresses.
• Создана роль replicator и слот replicator.
• Проведён pg_basebackup и права на папки корректны.
• Настроен мониторинг роста WAL и алерты.
• Проведён тест failover и восстановление.

Однострочный глоссарий

• WAL: журнал предзаписи — записи изменений перед коммитом на диск.
• Репликационный слот: серверный маркер, который предотвращает удаление WAL до чтения downstream.
• hot_standby: режим, в котором standby принимает только чтение.
• pg_basebackup: утилита для получения физического бэкапа данных PostgreSQL.

Краткое резюме

Репликационные слоты — надёжный способ защитить репликацию от потери WAL-записей. Внедряйте слоты вместе с мониторингом и планом действий на случай, если standby отстанет и начнёт накапливать WAL. Тестируйте failover и процедуру возврата в standby перед вводом в прод.

Важно: не оставляйте репликационные слоты без наблюдения — они могут привести к исчерпанию диска на master, если standby долго недоступен.