§ PostgreSQL Streaming Replication Setup. Updated.

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

Как-то я уже писал о настройке потоковой репликации. Пришло время слегка переписать статью, т.к. теперь процесс изменился в лучшую сторону. Настроить потоковую репликацию стало еще проще.
Пара слов, для тех кто сталкивается с этим впервые. Потоковая (Streaming) репликация в PostgreSQL это master-slave репликация при которой подчиненный slave-сервер работает в hot-standby режиме. Hot Standby это режим работы при котором существует возможность подключаться к серверу и выполнять запросы на чтение. Более того в случае аварии на master-сервере, запасной hot-standby сервер может быть оперативно переключен в режим мастера.

Для начала определимся с участниками мероприятия.
master = 172.16.90.51, он же мастер, главный сервер.

slave = 172.16.90.52, он же слэйв, stand-by, подчиненный и т.п.

Перед тем как начать, добавлю что все файлы конфигурации находятся в /var/lib/postgresql/db/. В зависимости от дистрибутива каталог может отличаться.
Итак, поехали. Первое что мы делаем это настраиваем доступы. Редактируем pg_hba.conf на мастере, разрешаем доверенные обращения со слэйва по протоколу репликации. 

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

Дальше, следует перезапустить мастер с поддержкой репликации. Суть настройки сводится к включению режима hot_standby для WAL (wal_level), определению максимального количества процессов участвующих в пересылке WAL-логов на standby-сервер (max_wal_senders) и количество сегментов WAL-журналов (wal_keep_segments). Настройка wal_keep_segments играет роль в случае когда слэйв потерял связь с мастером. В этом случае мастер начинает копить WAL сегменты, чтобы отдать их слэйву когда восстановится связь. Таким образом чем больше wal_keep_segments, тем больше вероятность того что слейв сможет восстановиться после возобновления связи. Архивирование WAL сегментов можно не настраивать. Опции архивирования, не играют первостепенной роли при потоковой репликации. 

master # vi /var/lib/postgresql/db/postgresql.conf
listen_addresses = '172.16.90.51'
wal_level = hot_standby
max_wal_senders = 3
wal_keep_segments = 64
# hot_standby = on
master # /etc/init.d/postgresql-9.3 restart

Переносим все файлы БД на слэйв. В прошлой статье это делалось с помощью rsync. Теперь будем делать это через pg_basebackup. Этот инструмент предназначен для создания т.н. base бэкапов. При использовании pg_basebackup не нужно запускать функции для перевода БД в режиме бэкапа (pg_start_backup()). Однако в pg_basebackup пока нет возможности ограничивать поток (такая возможность есть у rsync).
Итак переносить будем со слейва. Каталог /var/lib/postgresql/db должен быть пуст, иметь права 700 и принадлежать аккаунту от имени которого будет запущен сервис postrges (как правило это postgres или pgsql).

standby # su - postgres
standby $ mkdir /var/lib/postgresql/db/
standby $ chmod 700 /var/lib/postgresql/db/
standby $ pg_basebackup -P -R -X stream -c fast -h 172.16.90.51 -U postgres -D /var/lib/postgresql/db/

В результате pg_basebackup выполнит два подключения к мастеру по протоколу репликации, одно подключение для переноса данных, второе (-X stream) для переноса WAL журналов. Затем выполнит checkpoint (-c fast) - аналог pg_start_backup, после чего начнет переносить данные в каталог /var/lib/postrgesql/db. По завершению будет создан рабочий прототип recovery.conf (-R) который будет вполне пригоден для использования.
После завершения pg_basebackup редактируем postgresql.conf слэйва. Оставляем там все неизменным за исключением двух опций: включаем режим hot_standby, это позволит выполнять к нему запросы на чтение, и меняем listen_address.

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

Проверяем конфигурацию репликации в созданном recovery.conf.
По большей части нас должно интересовать значение опции trigger_file (по умолчанию оно не добавляется в recovery.conf) - файл наличие которого будет означать что postgres должен переключиться на работу в режиме мастера.

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'

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

standby # /etc/init.d/postgresql-9.3 start
standby # tail -f /var/lib/postgresql/db/postmaster.log 
LOG:  entering standby mode
LOG:  redo starts at 4/8D225FB0
LOG:  consistent recovery state reached at 4/8D2260C0
LOG:  record with zero length at 4/8D2260C0
LOG:  database system is ready to accept read only connections
LOG:  started streaming WAL from primary at 4/8D000000 on timeline 1
standby # ps aux |grep receiver
postgres 13211  0.0  0.1 349052  4088 ?        Ss   17:30   0:00 postgres: wal receiver process

На стороне мастера проверка выполняется с помощью pg_stat_replication:

postgres@master # SELECT * FROM pg_stat_replication;
-[ RECORD 1 ]----+------------------------------
pid              | 13212
usesysid         | 10
usename          | postgres
application_name | walreceiver
client_addr      | 172.16.90.52
client_hostname  | 
client_port      | 60897
backend_start    | 2014-03-04 17:30:23.901967+06
state            | streaming
sent_location    | 4/8D2260C0
write_location   | 4/8D2260C0
flush_location   | 4/8D2260C0
replay_location  | 4/8D2260C0
sync_priority    | 0
sync_state       | async

Еще вариант, создать что-либо на стороне мастера и проверить наличие на стороне слэйва. Например можно создать простенькую таблицу:

postgres@master # CREATE TABLE t1 AS SELECT generate_series(1,100);
SELECT 100
postgres@standby # SELECT count(*) from t1;
 count 
-------
   100
(1 row)

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

И напоследок привожу команду которую можно использовать для мониторинга лага репликации. Команду следует выполнить на слэйве (через psql), результатом будет время отставания слэйва от мастера. 

postgres@standby # psql -U postgres -c "select now() - pg_last_xact_replay_timestamp();"
    ?column?    
----------------
 00:00:02.15845
(1 row)

В идеальном лаг должен стремится к нулю  и его увеличение говорит о наличии проблем (нагрузка на сеть или на сервера).

Upd. и небольшое видео как это делается.

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