§ PostgreSQL Streaming Replication

Настройка потоковой репликации в PostgreSQL.

Update: новая версия статьи доступна здесь.
Hot Standby это режим работы при котором существует возможность подключаться к серверу и выполнять запросы на чтение, в то время как выполняется восстановление из WAL-архивов или идет работа в standby-режиме. Это полезно в целях репликации или  восстановлении из резервной копии. Hot Standby так же означает возможность сервера переходить из режима восстановления в режим нормальной работы, в то время как пользователи выполняют запросы или держат открытые соединения.

Update: новая версия статьи доступна здесь.

master = 172.16.90.51

slave = 172.16.90.52

Настраиваем pg_hba.conf на мастере, разрешаем доверенные обращения со слэйва 

master # vi /var/lib/postgresql/db/pg_hba.conf
host    replication     postgres        172.16.90.52/32         trust

Включаем репликацию на мастере и запускаем его. Суть настройки сводится к включению режима hot_standby (wal_level), настройке архивирования (archive_mode, archive_command), определению количества процессов участвующих в пересылке WAL-лога на standby-сервер (max_wal_senders) и количество файлов WAL-журнала (wal_keep_segments). Чем больше значение wal_keep_segments, тем больше вероятность того что слейв сможет восстановиться после возобновления связи, но тут на выручку приходит способность PostgreSQL архивировать файлы WAL-журналов. Обратной стороной медали является то что архивы занимают приличный объем дискового пространства (следите за местом). 

Опции архивирования, не играют первостепенной роли при потоковой репликации. Достаточно перенести файлы БД и Standby запустится без ошибок и подключится к master'у. Архивирование необходимо в том случае когда есть необходимость бэкапить WAL-логи в статичные бэкапы. Практика показывает что использование архивирования очень полезно на случай разрыва сетевого соединения между мастером и слейвом, в таком случае мастер просто копит архивы и при возобновлении соединения, слейв самостоятельно скачает недостающие архивы и догонит мастера. Опция hot_standby на мастере, должна быть выключена или закоментирована, опция определяет можно ли подключаться и выполнять запросы во время восстановления, следовательно она актуальна только для слейва.

master # vi /var/lib/postgresql/db/postgresql.conf
listen_addresses = '172.16.90.51'
wal_level = hot_standby
archive_mode = on
archive_command = 'cp %p /var/lib/postgresql/db/archive/%f'
max_wal_senders = 2
wal_keep_segments = 64
# hot_standby = on
master # mkdir /var/lib/postgresql/db/archive/
master # chown postgres: /var/lib/postgresql/db/archive/
master # /etc/init.d/postgresql-9.2 restart

Переносим все файлы БД на слэйв. Для этого, на мастере нужно запустить процедуру, которая будет сигнализировать о том что PostgreSQL нужно перейти в режим архивирования. В таком режиме можно переносить файлы кластера. Формат функции в 9.2 отличается от 9.0 (про 9.1 не могу сказать наверняка). В 9.2 нужно указать только один аргумент, - метку. После включения режима архивации, переносим rsync'ом файлы кластера с мастера на слейв, после чего выключаем режим архивации.

master # psql -c "SELECT pg_start_backup('label')" -U postgres
master # rsync -av /var/lib/postgresql/db/ 172.16.90.52:/var/lib/postgresql/db/ --exclude postmaster.pid
master # psql -c "SELECT pg_stop_backup()" -U postgres

Настраиваем слэйв. В результате rsync'а postgresql.conf перенесется на standby. Оставляем там все неизменым за исключением двух опций: включаем режим hot_standby, это позволит выполнять к нему запросы на чтение, и меняем listen_address.

standby # vi /var/lib/postgresql/db/postgresql.conf
listen_addresses = '172.16.90.52'
hot_standby = on

Настраиваем конфигурацию репликации, это необходимый файл recovery.conf содержащий опции режима восстановления (когда между мастером и слейвом есть лаг). Находиться он должен в каталоге кластера БД. Файл определяет строку подключения к мастеру и параметры сбора архивных копий и команду удаления с мастера неиспользуемых копий.

standby # vi /var/lib/postgresql/db/recovery.conf 
standby_mode = 'on'
primary_conninfo = 'host=172.16.90.51 port=5432 user=postgres'
trigger_file = '/var/lib/postgresql/db/trigger'
restore_command = 'scp postgres@172.16.90.51:/var/lib/postgresql/db/archive/%f "%p"'
archive_cleanup_command = 'ssh postgres@172.16.90.51 "pg_archivecleanup /var/lib/postgresql/db/archive %r"'

Все готово для запуска. Запускаем слэйв и проверяем работоспособность.

standby # /etc/init.d/postgresql-9.2 start
standby # tail -f /var/lib/postgresql/db/postmaster.log 
LOG:  streaming replication successfully connected to primary
LOG:  consistent recovery state reached at 4/F7000000
LOG:  database system is ready to accept read only connections
standby # ps aux |grep receiver
postgres  4312  0.1  0.4  68088  2328 ?        Ss   11:11   0:00 postgres: wal receiver process   streaming 4/F7000000

Проверка через pgbench (создаем какую-нибудь тестовую базу например replitest, job в моем случае заранее созданная роль)

master # pgbench -i -s 2 -t 4 -U job replitest
  creating tables...
  200000 tuples done.
standby # psql -c "\dt+" -U job replitest
                          List of relations
 Schema |       Name       | Type  | Owner |    Size    | Description 
--------+------------------+-------+-------+------------+-------------
 public | pgbench_accounts | table | job   | 26 MB      | 
 public | pgbench_branches | table | job   | 8192 bytes | 
 public | pgbench_history  | table | job   | 0 bytes    | 
 public | pgbench_tellers  | table | job   | 8192 bytes | 
(4 rows)
standby # psql -c "select count(*) from pgbench_accounts;" -U job replitest
 count  
--------
 200000
(1 row)

Как видим данные реплицируются успешно. 

И напоследок привожу команду которая используется в нашем мониторинге лага репликации. Команда использует три SQL-запроса и определяет в какой позиции считывается/записывается WAL-журнал.

# psql -qAtX -h pc-db -U postgres -c "SELECT pg_current_xlog_location()" ; psql -qAtX -U postgres -c "select pg_last_xlog_receive_location()" ; psql -qAtX -U postgres -c "select pg_last_xlog_replay_location()"
6CD/EE4EB2E0
6CD/EE4EFE88
6CD/EE4EB2E0

В идеальном случае значения запросов должны совпадать друг с другом, это говорит о том что лага нет. О том как мониторить состояние потоковой репликации напишу позже в статье о полноценном мониторинге PostgreSQL через Zabbix.

На главную "Virtualizing Linux"