Репликация

Для увеличения надежности функционирования сервера СУБД МФЦ возможна организация потоковой репликации. Это позволит иметь в любой момент времени «горячий» резервный сервер. В случае отказа основного сервера переход на резервный занимает несколько секунд. Данный материал описывает настройку сервера «горячего резерва». Более подробную информацию можно получить из соответствующих разделов документации по PostgreSQL.

Будем считать, что серверы master и slave уже установлены, ip-адрес master 192.168.1.100, ip-адрес slave 192.168.1.200, базы postgres-a у вас лежат в /var/lib/postgresql/9.1/, если это не так — используйте корректный для вас путь

1.Прописываем адреса серверов:

postgresql.conf slave строка :

listen_addresses = '192.168.1.100'

pg_hba.conf на master добавить строку:

host replication postgres 192.168.1.200/32 trust

2.Прописываем настройки master:

создать папку /var/lib/postgresql/9.1/main/archive и дать пользователю postgres полный доступ к ней. файл postgresql.conf

#Выставляем ведение журнала таким образом, чтобы слейв мог использоваться для чтения.
wal_level = hot_standby

#Максимальное количество слейвов
max_wal_senders = 2

#Сколько кусков лога будем хранить? Если вдруг у вас большая нагрузка на запись в базу - возможно это значение нужно будет увеличить, чтобы всё успевало доезжать до реплики.
wal_keep_segments = 32

#дублируем журнал в отдельное место(лучше чистить по крону эту локацию, удаляя всё, чему больше суток). Хотя, офф. ман говорит, что оно вообще не обязательно.
archive_mode = on
archive_command = 'cp %p /var/lib/postgresql/9.1/main/archive/%f'

Перезапускаем master.

sudo /etc/init.d/postgresql restart

3.Копирование базы на slave

Остановить slave, если он запущен.

sudo /etc/init.d/postgresql stop

Копируем папку /var/lib/postgresql/9.1/main/ с master на slave, например, с помощью rsync

$ psql -c "SELECT pg_start_backup('label', true)"
$ rsync -a /var/lib/postgresql/9.1/main/ slave:/var/lib/postgresql/9.1/main/ --exclude postmaster.pid
$ psql -c "SELECT pg_stop_backup()"

4.На slave

в postgresql.conf добавляем строку

hot_standby = on

5.Создать файл recovery.conf

в папке /var/lib/postgresql/9.1/main

standby_mode = 'on'        #включить режим горячего резерва
primary_conninfo = 'host=192.168.1.100 port=5432 user=postgres'
trigger_file = '/var/lib/postgresql/9.1/main/trigger'
restore_command = 'cp /var/lib/postgresql/9.1/main/archiv/%f "%p"'
archive_cleanup_command = '"pg_archivecleanup /var/lib/postgresql/9.1/archiv/ %r"'

6.Запускаем postgresql на slave

sudo /etc/init.d/postgresql start

7. Если на слейве команда

ps aux | grep receiver

Показывает что-то вида

postgres 1953 0.0 0.0 101980 4156 ? Ss 19:19 0:00 postgres: wal receiver process streaming 2/B40001D0

(читай — есть процесс postgres с описанием wal receiver) — можно считать, что всё работает.

8. В случае отказа master

в папке /var/lib/postgresql/9.1/main/ создать файл trigger ( имя из строки trigger_file файла recovery.conf)
переключить ИС МФЦ на сервер slave (файл server.ini).
Далее, когда машина, обслуживающая мастер, вернётся в строй — оборачиваем процесс вспять — делаем из изначального мастера реплику — выполняем на мастере 5й пункт. Когда оно восстановится — удаляем на слейве триггер-файл — всё должно вернуться в норму.