Введение
Потоковая репликация (streaming) подразумевает собой реплицирование всех существующих баз данных.
В новой версии PostgreSQL 12+ процесс настройки репликации отличается от того, что было ранее:
- файл recovery.conf теперь отсутствует
- параметр standby_mode выпилен, вместо него файл в корне файл standby.signal теперь уведомляет, что сервер standby (slave)
- в файл postgresql.auto.conf пишется primary_conninfo – инфа о мастере и пароле, которая ранее была в recovery.conf. Причем postgresql.auto.conf – это файл конфигурации, который читается в конце при запуске Postgres. Таким образом, если есть параметр, который имеет разные значения в файлах postgresql.conf и postgresql.auto.conf, значение, установленное в postgresql.auto.conf, рассматривается PostgreSQL в приоритете. Кроме того, любой параметр, который был изменен с помощью ALTER SYSTEM, будет автоматически записан также в postgresql.auto.conf.
Настройка репликации
Подразумевается, что уже запущено два инстанса PostgreSQL для выполнения дальнейшей работы.
На master-сервере необходимо создать пользователя, от имени которого будет реплицироваться БД, предоставить ему права для подключения и перечитать конфиг:
CREATE USER replication WITH REPLICATION ENCRYPTED PASSWORD 'secret';
echo "host replication replication 192.168.0.107/32 md5" >> $PGDATA/pg_hba.conf
psql -c "select pg_reload_conf()"
На сервере slave должна быть установлена утилита pg_basebackup также версии 12+ и подготовлена пустая директория, куда будет размещена копия с мастера:
mkdir -p /storage/postgresql-12.2/var/lib/postgresql/data
На slave-сервере перед дальнейшим продолжением необходимо остановить PostgreSQL!
Теперь допустимо выполнить копирование файлов с мастера на слейв:
pg_basebackup -h ${MASTER_IP} -U replication -p 5432 -D /storage/postgresql-12.2/var/lib/postgresql/data -R -P
-R — будет создан автоматически файл standby.signal и заполнен файл postgresql.auto.conf с информацией о подключении к мастеру
-P — примерный прогресс-бар
Есть также ключ -Xs, используется дефолтом, но для понимания нужно знать, что в таком случае открывается 2 соединения до мастера – в одном идёт копирование файлов, а во втором – копирование журналов предзаписи (внимание на параметр max_wal_senders мастера), в которых накапливаются изменения, пока копируются основные файлы. И по окончании вся информация из журналов будет прочитана и применена. Таким образом все изменения в процессе копирования будут учтены и на слейве будет получена полностью самодостаточная резервная копия.
Другие ключи для pg_basebackup не требуются, если нет никаких особенностей.
На этом всё, копирование через basebackup выполняется достаточно быстро, а также не мешает работе мастера. Слейв можно запускать и проверять логи, в которых не должно фигурировать ошибок.
Мониторинг
Отдельно стоит упомянуть про мониторинг настроенной реплики. Необходимо взять серверы с Master и Slave под наблюдение, чтобы следить за отставанием, статусом репликации.
На мастер-сервере после настройки репликации команда select * from pg_stat_replication; должна возвращать не пустые значения, а команда SELECT count(*) FROM pg_stat_replication возвращать минимум значение “1”.
На stabdby-сервере можно наблюдать за отставанием относительно мастера, для этого подойдут команды select pg_is_in_recovery(),pg_is_wal_replay_paused(), pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn(), pg_last_xact_replay_timestamp();. Но высчитывать здесь уже будет сложнее.
Поэтому рекомендую подключить комплексный шаблон мониторинга PostgreSQL через zabbix-agent2 в Zabbix 5+, где все вышеуказанные параметры (и множество других) учтены и позволят быть в курсе всех происходящих событий с базой и репликой.
Promotion slave to master
В случае возникновения проблем с мастер-сервером, можно переключить работу приложения на слейв сервер. Но для этого необходимо указать slave-серверу, что он теперь станет ведущим и может выполнять запись, т.е. выполнить promote. В Postgresql 12 есть три способа выполнить promotion для slave-сервера:
- Создать пустой файл с любым именем по пути, указанному в параметре
promote_trigger_file
конфигурационного файлаpostgresql.con
f. При этом файл standby.signal будет удален. - Запустить команду
pg_ctl promote
(в контейнере с postgresql она уже установлена) - В консоли postgresql вызвать функцию
select pg_promote();
Во втором и третьем случаях никакие файлы создавать не потребуется.