Настройка горячего резервного сервера PostgreSQL 9.0 с репликацией и repmgr на OpenSUSE 11.4

Зачем это нужно

• Горячий standby (hot standby) позволяет выполнять запросы на вторичных серверах и использовать их для балансировки чтения или аварийного переключения.
• repmgr упрощает мониторинг и управление репликацией как единый кластер.

В этом руководстве показано, как сделать рабочую настройку на двух виртуальных серверах OpenSUSE 11.4 (32-bit) под VMware Workstation.

Автор и исходные заметки: [email protected], 20 июня 2011 г.

Окружение примера

• pgmaster: 192.168.5.187 (master)
• pgslave: 192.168.5.188 (slave / standby)

Добавьте эти записи в /etc/hosts на обоих серверах.

Важные замечания

Important: Перед началом убедитесь, что у вас есть резервная копия критичных данных и доступ по консоли к обоим серверам. Рекомендую выполнять все операции под пользователем root, переключаясь на postgres там, где это требуется.

Шаг 1. Установка PostgreSQL на master и slave

Установите пакеты на обоих серверах:

zypper install postgresql postgresql-contrib postgresql-server

Запустите сервер, чтобы убедиться, что всё в порядке:

/etc/init.d/postgresql start

Шаг 2. Настройка доверенной копии по SSH (на обоих серверах)

repmgr использует rsync и SSH от имени пользователя postgres. Нужно настроить безпарольный доступ между master и slave для пользователя postgres.

1. Установите пароль и сгенерируйте ключи под пользователем postgres:

passwd postgres
su - postgres
ssh-keygen -t rsa

2. Скопируйте публичный ключ на другой сервер:

ssh-copy-id -i ~/.ssh/id_rsa.pub pgslave

3. Проверьте подключение с master на slave:

ssh pgslave

4. Повторите те же действия со slave на master (чтобы доступ был двусторонним, если потребуется).

su - postgres
ssh-keygen -t rsa
ssh-copy-id -i ~/.ssh/id_rsa.pub pgmaster
ssh pgmaster

Важно: после проверки обязательно выйти из удалённой сессии (logout).

Шаг 3. Правки конфигурации PostgreSQL на master и перезапуск

Внесите следующие изменения в postgresql.conf на master (обычно /var/lib/pgsql/data/postgresql.conf):

listen_addresses = "*"
wal_level = hot_standby
checkpoint_segments = 30
archive_mode = on
archive_command = 'cd .'
max_wal_senders = 2
wal_keep_segments = 5000
hot_standby = on

В pg_hba.conf добавьте доступ для сети и для репликации (master):

host all all 192.168.5.0/24 trust
host replication all 192.168.5.0/24 trust

После правок перезапустите PostgreSQL:

/etc/init.d/postgresql restart

Создайте тестовую базу и сгенерируйте данные для проверки репликации:

su - postgres
createdb pgbench
pgbench -i -s 10 pgbench

Объяснение кратко: wal_level=hot_standby включает запись WAL с достаточной информацией для реплики; max_wal_senders — число параллельных отправителей WAL; wal_keep_segments сохраняет WAL-файлы, чтобы реплика могла догнать мастер.

Шаг 4. Подготовка slave: очистка каталога данных и проверка соединения (только на slave)

Остановите PostgreSQL на slave и очистите data-dir:

/etc/init.d/postgresql stop
cd /var/lib/pgsql/data
rm -rf *

Проверьте подключение к удалённой базе на master:

psql -h pgmaster -d pgbench

Если подключение успешно, можно переходить к получению копии данных и настройке repmgr. В оригинальном руководстве далее следует сборка repmgr из исходников с сайта 2ndQuadrant — скачайте последнюю совместимую версию repmgr и выполните сборку согласно инструкции в пакете.

Базовая методология (мини-процесс)

1. Установить ПО на обоих серверах.
2. Настроить SSH-доступ для postgres (без пароля).
3. Правки конфигураций на master (postgresql.conf, pg_hba.conf) и перезапуск.
4. Подготовить пустой data-dir на slave и получить копию данных с master (rsync/pg_basebackup/repmgr).
5. Настроить recovery.conf (или соответствующую директиву в вашей версии) на slave для подключения к master.
6. Запустить slave и проверить статус репликации.
7. Установить repmgr, зарегистрировать master и slave, настроить мониторинг и failover.

Роль — контрольный чеклист для администратора

• Проверить версию PostgreSQL: psql –version
• Убедиться, что порты открыты и маршрут между серверами доступен
• Настроить SSH-ключи и протестировать вход без пароля
• Скорректировать postgresql.conf и pg_hba.conf на master
• Создать тестовую базу и данные
• Очистить data-dir на slave и подготовить резервную копию
• Установить и настроить repmgr, провести регистрацию узлов
• Тестировать восстановление и переключение вручную и с помощью repmgr

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

• Slave успешно подключается к master и применяет WAL
• На slave доступна возможность выполнения SELECT-запросов (hot standby)
• repmgr показывает оба узла в статусе OK
• Тестовое переключение на standby проходит без потери данных при корректной настройке

Типичные ошибки и как их найти

• Неверные права SSH/отсутствие ключей: проверьте ~/.ssh/authorized_keys и права 700/600
• postgresql.conf не перезапущен: проверьте процесс и логи в /var/log/postgresql
• Неправильные записи в pg_hba.conf: протестируйте подключение psql -h pgmaster
• WAL-файлы удаляются раньше, чем реплика успевает их применить: увеличьте wal_keep_segments или настройте архивирование

Небольшой глоссарий (1 строка)

• WAL: журнал предзаписи (Write-Ahead Log), записи которого используются для репликации и восстановления.
• repmgr: инструмент управления и мониторинга кластеров PostgreSQL.
• hot standby: режим, в котором вторичный сервер принимает подключаемые запросы на чтение.

Полезные примечания

• Альтернативы репликации: логические реплики (logical replication), сторонние решения для HA (Patroni, Pacemaker). repmgr хорошо подходит для простого управления failover и мониторинга.
• На OpenSUSE 11.4 могут потребоваться дополнительные зависимости при сборке repmgr из исходников; читайте документацию repmgr.

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

• Настройка hot standby требует правок postgresql.conf и pg_hba.conf на master, настройки SSH для postgres и корректной инициализации data-dir на slave.
• repmgr упрощает управление репликацией и failover, но его нужно установить и зарегистрировать узлы после базовой настройки репликации.

Если нужно, могу дополнить статью примерами конфигурации recovery.conf, шагами сборки repmgr из исходников или шаблоном systemd-скрипта для управления repmgr-клиентом.