Давайте по порядку:
wal_level = hot_standby сервер начнет писать в WAL логи так же как и при режиме «archive», добавляя информацию, необходимую для восстановления транзакции (можно также поставить archive, но тогда сервер не может быть слейвом при необходимости);
max_wal_senders = 5 максимальное количество слейвов;
wal_keep_segments = 32 минимальное количество файлов c WAL сегментами в pg_xlog директории;
archive_mode = on позволяем сохранять WAL сегменты в указанное переменной archive_command хранилище. В данном случае в директорию «/path/to/archive/».
По умолчанию репликация асинхронная. В версии 9.1 добавили параметр synchronous_standby_names, который включает синхронную репликацию. В данные параметр передается application_name, который используется на слейвах в recovery.conf:
restore_command = 'cp /mnt/server/archivedir/%f %p' # e.g. 'cp /mnt/server/archivedir/%f %p' standby_mode = on primary_conninfo = 'host=masterdb port=59121 user=replication password=replication application_name=newcluster' # e.g. 'host=localhost port=5432' trigger_file = '/tmp/trig_f_newcluster'
После изменения параметров перегружаем PostgreSQL сервер. Теперь перейдем к slavedb.
Настройка слейва
Для начала нам потребуется создать на slavedb точную копию masterdb. Перенесем данные с помощью «Онлайн бекапа».
Для начала зайдем на masterdb сервер. Выполним в консоли:
$ psql -c "SELECT pg_start_backup('label', true)"
Теперь нам нужно перенести данные с мастера на слейв. Выполняем на мастере:
$ rsync -C -a --delete -e ssh --exclude postgresql.conf --exclude postmaster.pid \ --exclude postmaster.opts --exclude pg_log --exclude pg_xlog \ --exclude recovery.conf master_db_datadir/ slavedb_host:slave_db_datadir/
где
master_db_datadir директория с postgresql данными на masterdb
slave_db_datadir директория с postgresql данными на slavedb
slavedb_host хост slavedb(в нашем случае - 192.168.1.20)
После копирования данных с мастера на слейв, остановим онлайн бекап. Выполняем на мастере:
$ psql -c "SELECT pg_stop_backup()"
Для версии PostgreSQL 9.1+ можно воспользоватся командой pg_basebackup (копирует базу на slavedb подобным образом):
$ pg_basebackup -R -D /srv/pgsql/standby --host=192.168.0.10 --port=5432
Устанавливаем такие же данные в конфиге postgresql.conf, что и у мастера (чтобы при падении мастера слейв мог его заменить). Так же установим дополнительный параметр:
hot_standby = on
Внимание! Если на мастере поставили wal_level = archive, тогда параметр оставляем по умолчанию (hot_standby = off).
Далее на slavedb в директории с данными PostgreSQL создадим файл recovery.conf с таким содержимым:
# Specifies whether to start the server as a standby. In streaming replication, # this parameter must to be set to on. standby_mode = 'on' # Specifies a connection string which is used for the standby server to connect # with the primary. primary_conninfo = 'host=192.168.0.10 port=5432 user=postgres' # Specifies a trigger file whose presence should cause streaming replication to # end (i.e., failover). trigger_file = '/path_to/trigger' # Specifies a command to load archive segments from the WAL archive. If # wal_keep_segments is a high enough number to retain the WAL segments # required for the standby server, this may not be necessary. But # a large workload can cause segments to be recycled before the standby # is fully synchronized, requiring you to start again from a new base backup. restore_command = 'scp masterdb_host:/path_to/archive/%f "%p"'
где
standby_mode='on' указываем серверу работать в режиме слейв;
primary_conninfo настройки соединения слейва с мастером;
trigger_file
указываем триггер-файл, при наличии которого будет остановлена репликация;
restore_command команда, которой будут восстанавливаться WAL логи. В нашем случае через scp копируем с masterdb (masterdb_host - хост masterdb).
Теперь мы можем запустить PostgreSQL на slavedb.
Тестирование репликации
Теперь мы можем посмотреть отставание слейвов от мастера с помощью таких команд:
$ psql -c "SELECT pg_current_xlog_location()" -h192.168.0.10 (masterdb) pg_current_xlog_location -------------------------- 0/2000000 (1 row) $ psql -c "select pg_last_xlog_receive_location()" -h192.168.0.20 (slavedb) pg_last_xlog_receive_location ------------------------------- 0/2000000 (1 row) $ psql -c "select pg_last_xlog_replay_location()" -h192.168.0.20 (slavedb) pg_last_xlog_replay_location ------------------------------ 0/2000000 (1 row)
Начиная с версии 9.1 добавили дополнительные view для просмотра состояния репликации. Теперь master знает все состояния slaves:
# SELECT * from pg_stat_replication ; procpid | usesysid | usename | application_name | client_addr | client_hostname | client_port | backend_start | state | sent_location | write_location | flush_location | replay_location | sync_priority | sync_state ---------+----------+-------------+------------------+-------------+-----------------+-------------+------------------------------+-----------+---------------+----------------+----------------+-----------------+---------------+------------ 17135 | 16671 | replication | newcluster | 127.0.0.1 | | 43745 | 2011-05-22 18:13:04.19283+02 | streaming | 1/30008750 | 1/30008750 | 1/30008750 | 1/30008750 | 1 | sync