Установка repmgr и клонирование standby для PostgreSQL

Обзор

В этом руководстве описаны шаги 5–8 из более общего процесса настройки репликации PostgreSQL с помощью repmgr. Покрываются: установка зависимостей, компиляция repmgr из исходников, клонирование master на standby, базовая конфигурация repmgr и регистрация узлов для мониторинга.

Важно: инструкции ниже предполагают, что у вас есть два сервера — master (pgmaster) и slave/standby (pgslave) — и вы выполняете команды под пользователем root или postgres в зависимости от шага.

Шаг 5. Ручная установка исходников repmgr на master и slave

Скачайте исходники repmgr:

wget http://projects.2ndquadrant.it/sites/default/files/repmgr-1.1.0.tar.gz -O /tmp/repmgr-1.1.0.tar.gz

Перед компиляцией нужно установить зависимости. Для SUSE/openSUSE (zypper):

zypper install make gcc postgresql-devel libxslt-devel pam-devel libopenssl-devel krb5-devel

А затем соберите и установите repmgr:

cd /tmp && tar xzf repmgr-1.1.0.tar.gz && cd repmgr-1.1.0
make USE_PGXS=1
make USE_PGXS=1 install

Проверьте установку:

repmgr --version
repmgrd --version

Совет: убедитесь, что на обеих машинах (master и slave) установлены одинаковые версии repmgr и PostgreSQL, иначе возможны несовместимости.

Шаг 6. Клонирование master на slave (только на slave)

На сервере-standby выполните переключение на пользователя postgres и команду клонирования:

su - postgres
repmgr -D /var/lib/pgsql/data -d pgbench -p 5432 -R postgres --verbose standby clone pgmaster

В процессе вы увидите лог клонирования похожий на этот:

После успешного клона запустите PostgreSQL на slave:

/etc/init.d/postgresql start

Важно: путь к каталогу данных (-D) и имя базы (-d) должны соответствовать вашей конфигурации. Если у вас иная иерархия каталогов, скорректируйте команды.

Шаг 7. Настройка repmgr.conf на master и slave

Создайте каталог для repmgr (обычно /var/lib/pgsql/repmgr) и файл /var/lib/pgsql/repmgr/repmgr.conf. Пример для master:

cluster=test
node=1
conninfo='host=pgmaster user=postgres dbname=pgbench'

Пример для slave:

cluster=test
node=2
conninfo='host=pgslave user=postgres dbname=pgbench'

Примечание: вместо user=postgres лучше создать отдельного пользователя repmgr с минимально необходимыми правами (см. раздел «Рекомендации по безопасности»).

Шаг 8. Регистрация master и slave, запуск мониторинга

На master зарегистрируйте мастер-узел:

repmgr -f /var/lib/pgsql/repmgr/repmgr.conf --verbose master register

На slave зарегистрируйте standby:

repmgr -f /var/lib/pgsql/repmgr/repmgr.conf --verbose standby register

Проверка состояния репликации (выполните на одной из машин):

psql pgbench -c 'select * from repmgr_test.repl_status'

В нормальном случае slave отстает на ~1 секунду.

Быстрая проверка репликации

На master создаём таблицу и вставляем строку:

psql pgbench -c "create table test ( test varchar(30));"
psql pgbench -c "insert into test values ( 'test123');"

Проверяем на slave:

psql -h pgslave pgbench -c "select * from test"

Если вы видите запись, репликация работает.

Работа, требующая улучшений в будущем

Это быстрый туториал для настройки SR-репликации с PostgreSQL 9. Обратите внимание на следующие пункты:

1. Создать отдельного пользователя repmgr вместо использования postgres.
2. Обнаруженная ошибка в репмгр: возможен фикс в upstream, см. ссылку на коммит для подробностей — https://github.com/greg2ndQuadrant/repmgr/commit/7427988628f754e57069453d65a71f79117c3a3d
3. Прочитать документацию repmgr по процедурам повышения standby в master при отказе.
4. Есть несколько способов проверить репликацию — смотрите материалы на postgresql.org.
5. Читайте README в упаковке repmgr.
6. Регулярно делайте резервные копии и тестируйте восстановление.

Дополнительные рекомендации и полезные методики

Когда этот подход может не подойти

• Если у вас управляемый облачный кластер (например, Amazon RDS), доступ к исходникам и прямой сборке repmgr может быть ограничен.
• При больших задержках сети или нестабильном соединении клонирование может завершиться с ошибками или занять очень много времени.
• Несовпадение версий PostgreSQL/repmgr между узлами приведёт к проблемам.

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

• Установить repmgr из пакета RPM/DEB, если доступен релиз для вашей ОС, вместо сборки из исходников — это проще для поддержки.
• Использовать встроенные инструменты PostgreSQL (pg_basebackup, streaming replication) ручной конфигурацией без repmgr.
• Рассмотреть Patroni или Patroni+etcd/consul для автоматического управления HA и failover.

Проверка и отладка — чеклист для ролей

Администратор базы данных (DBA):

• Проверить версии PostgreSQL и repmgr на обеих нодах.
• Убедиться в наличии сетевого доступа между узлами (порт 5432).
• Проверить права пользователя, используемого в conninfo.

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

• Установить зависимости и обеспечить одинаковые системные библиотеки.
• Настроить корректные системные сервисы (systemd или init.d для postgresql).

DevOps / SRE:

• Автоматизировать сборку/установку и проверку версий.
• Настроить мониторинг задержки репликации и алертинг.

Мини-методология развёртывания (шаблон)

1. Подготовка окружения: установить зависимости, проверить дисковое пространство, сетевые правила.
2. Тест в staging: собрать и установить repmgr в тестовом окружении.
3. Клонирование: выполнить standby clone и запустить PostgreSQL.
4. Регистрация и мониторинг: зарегистрировать узлы в repmgr и настроить репортинг.
5. Тест на отказ: имитировать отказ master и проверить процесс повышения standby.

Краткий словарь (1 строка)

repmgr — утилита для управления репликацией PostgreSQL и упрощённого failover; standby — реплика/резервный сервер; master — основной сервер с записью.

Рекомендации по безопасности

• Не используйте superuser postgres в продуктивных скриптах мониторинга — создайте отдельного пользователя repmgr с минимальными правами.
• Ограничьте доступ по сети к портам PostgreSQL и репликации с помощью firewall и правил безопасности.
• Логи и данные репликации могут содержать чувствительную информацию — контролируйте доступ к ним.

Критерии приёмки

• На master и slave установлены совместимые версии PostgreSQL и repmgr.
• standby успешно клонирован и запущен, проверка psql возвращает ожидаемые данные.
• repmgr зарегистировал оба узла и отображает корректный статус репликации.

Итог

Вы собрали repmgr из исходников, клонировали master на standby, настроили repmgr.conf и зарегистрировали узлы. Далее рекомендуем: создать отдельного пользователя repmgr, автоматизировать шаги установки и протестировать процедуру failover в контролируемой среде.

Ссылки и ресурсы

2ndquadrant: http://projects.2ndquadrant.com/repmgr
PostgreSQL Wiki — Hot Standby: http://wiki.postgresql.org/wiki/Hot_Standby
PostgreSQL Wiki — Binary Replication Tutorial: http://wiki.postgresql.org/wiki/Binary_Replication_Tutorial

Контакт для вопросов (как в оригинале): [email protected]