Настройка репликации postgresql

Встроенная потоковая репликация (Streaming Replication), есть в PostgreSQL начиная с версии 9.0, , усовершенствованна и реализована с помощью передачи WAL (write-ahead logs, журналов (логов) опережающей записи) с главного (Master/Primary) сервера на подчиненный (Slave/Secondary/Replica).
Это асинхронная репликация Master/Slave, когда на ведущий/главный сервер идут запросы, приводящие к изменениям в БД, а на подчиненном сервере эти изменения будут выполнены только через некоторое время. В данном случае реализация состоит в том, что создается сетевое подключение между Standby и Master СУБД вместо копирования журналов по 16 мегабайт, как при Warm Standby и Hot Standby. Как известно, механизм используемый в Warm Standby и Hot Standby основан на пересылке от мастера к слейву.
Мы сначала настроим Hot Standby репликацию, а затем добавим возможность потоковой репликации.
Можно совмещать Hot Standby и Streaming Replication. Это позволяет увидеть на слейве почти мгновенно изменения, выполненные на мастере. Хотя и при работе только потоковой репликации записи с WAL-логов востанавливаются сразу же при процессе их получения. При потоковой репликации на серверах создаются специальных два дополнительных процесса walsender и walreceiver на каждую пару серверов управления базами данных, взаимодействующих между собой через сеть. Потоковая репликация позволяет легко реализовать работу нескольких ведомых.

Исходные данные.
Мастер-сервер ip-адрес: 192.168.200.62
Slave-сервер ip-адрес: 192.168.51.52
postgresql версия: 9.0.8. Важно! Для настройки репликации postgresql: Версия postgresql и операционной системы должна быть одинаковой для мастера и slave серверов
OS: OpenSuSE 11.4

1. Внесем некоторые изменения на мастер сервере:
mkdir /opt/scripts
mkdir /usr/local/pgsql/wal_archive
chown postgres /usr/local/pgsql/wal_archive
2. Добавим скрипты необходимые для репликации postgresql:
/opt/scripts/master_save_wal.pl:

показать файл »

/opt/scripts/slave_get_wal.pl:

показать файл »

/opt/scripts/slave_wal_cleanup.pl:

показать файл »

3. На мастер сервере в конфигурационном файле /usr/local/pgsql/postgresql.conf добавим следующий строчки:

wal_level = hot_standby

archive_mode = on
archive_command = ‘/opt/scripts/master_save_wal.pl %p %f /usr/local/pgsql/wal_archive’
archive_timeout = 3600
4. Перезагрузим postgresql и убедимся что wal-logs создаются в директории /usr/local/pgsql/wal_archive:
/etc/init.d/postgres restart
ls -al /usr/local/pgsql/wal_archive/
psql -c «select pg_switch_xlog();»
ls -al /usr/local/pgsql/wal_archive/
Для возможности создания снимка данных postgresql посылается запрос к серверу:
select pg_start_backup(‘label’,true);
,где ‘label’ может быть любым словом.
Этот запрос переводит мастер в режим создание резервной копии, при котором можно копировать директорию data на slave (например rsync). Полученный таким образом «snapshot» будет не противоречивый и будет содержать файл, указывающий ведомому серверу когда он был сделан для дальнейшего приведения данных в БД к актуальному состоянию. До посылки на мастере запроса «select pg_stop_backup();» никакие изменения в базу не записываются, а заносятся в транзакционные логи, что стоит учесть и не забывать выйти с данного режима.

5. Переводим мастер в режим бекапа:
psql -c «SELECT pg_start_backup(‘label’, true)»
6. Останавливаем postgresql на slave:
/etc/init.d/postgres stop
7. Копируем postgresql instance на slave:
rsync —rsh=ssh -avrz —progress —delete —exclude=pg_xlog —exclude=postmaster.pid [email protected]:/usr/local/pgsql/data/ /usr/local/pgsql/data/
После окончания не забудем выключить режим бекапов на мастере:
psql -c «SELECT pg_stop_backup()»
8. Для настройки репликации postgresql на slave-сервере. Создадим файл следующего содержания:
/usr/local/pgsql/data/recovery.conf:

standby_mode = ‘on’
restore_command = ‘/opt/scripts/slave_get_wal.pl %f %p /usr/local/pgsql/wal_archive_in’
trigger_file = ‘/usr/local/pgsql/data/trigger_file’
archive_cleanup_command = ‘/opt/scripts/slave_wal_cleanup.pl %r /usr/local/pgsql/wal_archive_in’
#primary_conninfo = ‘host=192.168.200.62 port=5432 user=postgres’ //для потоковой репликации

trigger_file нужен для того, чтобы в случае падения мастера, можно было бы сделать слейв-мастером. Т.е. доступным на запись.

9. На slave-сервере внесем одно изменение в файл /usr/local/pgsql/postgresql.conf:
hot_standby=on
Создадим директорию в которую будут попадать wal-logs с мастера:
mkdir /usr/local/pgsql/wal_archive_in
chown -R postgres /usr/local/pgsql/wal_archive_in
10. Запускаем postgresql на slave-сервере:
/etc/init.dpostgres start
11.Добавим в cron пользователя postgres копировать wal-logs с мастер сервера:
* * * * * /opt/scripts/wal_copy.pl [email protected]:/usr/local/pgsql/wal_archive/ /usr/local/pgsql/wal_archive_in 2>&1 | /bin/logger -t pgsql.error
12. Для настройки потоковой репликации postgresql достаточно на мастер сервере:
/usr/local/pgsql/data/postgresql.conf:
max_wal_senders = 2
13. Добавить в файл /usr/local/pgsql/data/pg_hba.conf :
# for streaming replication
host replication postgres 192.168.51.52/32 trust
14. На slave расскоментировать строку:
primary_conninfo = ‘host=192.168.200.62 port=5432 user=postgres’
15. Мониторинг репликации postgresql:
При настроенной репликации на мастере и slave запускаются дополнительные процессы: postgres: wal sender process и postgres: wal receiver process, соответственно.

postgres  3510 11745  0 Apr15 ?        00:21:11 postgres: wal sender process postgres 192.168.51.52(47161) streaming 19/E493D4F8

postgres: wal receiver process   streaming 19/E496A050

Для анализа от полученных результатов нужно взять только шестнадцатиричное (HEX) значение, которое после слеша ‘/’ и перевести в десятичный (DEC) формат. Разница этих чисел даст некоторое значение от которого можно отталкиваться при подсчете отставания слейва от мастера. Для перевода HEX to DEC, т.е. шестнадцатиричного в десятичное число можно воспользоваться, к примеру, такими утилитами:

echo «ibase=16; FF»|bc
255
printf «%d\n» 0xff
255

Если у вас есть некоторая таблица в которую данные поступают регулярну то можно просто написать запрос который будет сравнивать время последнего изменения в данной таблицы с текущим — таким образом можно будет определить на сколько отстает slave от мастера.

Ссылки:
Мониторинг репликации postgresql
Настройка репликации postgresql