Еще пара слов о потоковой репликации в postgres…

Асинхронная потоковая репликация — полезная штука. Для нее нынче есть много различных утилит, можно выстроить большую, мощную и верную систему.

Но предположим, что у Вас небольшая задача, пара серверов и встроенная postgres-репликация. О ее настройке материалов достаточно, и о действиях в случае отказа мастера тоже можно найти.

А вот с вопросом восстановления мастера оказалась беда, поэтому делюсь с Вами собранным по кусочкам с просторов интернета руководством к действию, опробованным и протестеным мною на связках серверов Debian GNU/Linux и FreeBSD 8.2 с PostgreSQL 9.1



Для начала мы имеем:

Serv1 — Мастер
Serv2 — Слейв

Падение Мастера

Предположим, что БД на Serv1 (мастере) обвалилась, погибла и восставать сама никак не будет. При этом Serv2 стабильно работает в режиме слейва.

Тогда на Serv2 в postgresql.conf надо раскомментировать

wal_level = hot_standby
max_wal_senders = 2
wal_keep_segments = 64
archive_mode = on
archive_command = 'cp %p $LOG_DIR/archive/%f Serv1'

в $HOME переименовать recovery.conf в recovery.done


Рестартнуть Serv2. Так Serv2 станет мастером.

Восстановление прежнего Мастера

Теперь у нас Serv2 работает в режиме мастера, Serv1 отключен.

Надо сделать Serv1 слейвом следующим образом:

На Serv2 выполнить:

psql -c "SELECT pg_start_backup('label', true)"
rsync -avzh --progress $HOME/ Serv1:$HOME/ --exclude postmaster.pid
psql -c "SELECT pg_stop_backup()"

В конфиге postgresql.conf на Serv1 закомментировать то, что раскомментировали на Serv2, а именно:

#wal_level = hot_standby
#max_wal_senders = 2
#wal_keep_segments = 64
#archive_mode = on
#archive_command = 'cp %p $LOG_DIR/archive/%f Serv2'

И раскомментировать:

hot_standby = on

В $HOME переименовать recovery.done в recovery.conf

Запустить postgres на Serv1.
Теперь Serv1 работает в режиме слейва.

Проверить работу слейва можно выполнив на нем

ps aux | grep receiver

и получив результат вида

postgres: wal receiver process  (postgres)

Переключение обратно на Мастер

( см. первый пункт и делаем наоборот )

Сейчас экс-мастер Serv1 является слейвом Serv2. Оба стабильно работают, копия слейва верна, расхождение минимально.

Для становления мастером Serv1:

На нем в postgresql.conf раскомментировать

wal_level = hot_standby
max_wal_senders = 2
wal_keep_segments = 64
archive_mode = on
archive_command = 'cp %p $LOG_DIR/archive/%f'

Остановить Serv2 (который пока что мастер) а на Serv1 в $HOME переименовать recovery.conf в recovery.done

Теперь Serv1 вновь является работающим мастером.

Для прицепления слейвом Serv2:

На Serv1 выполнить:

psql -c "SELECT pg_start_backup('label', true)"
rsync -avzh --progress $HOME/ Serv2:$HOME/ --exclude postmaster.pid
psql -c "SELECT pg_stop_backup()"

На Serv2 в postgresql.conf закомментировать:

#wal_level = hot_standby
#max_wal_senders = 2
#wal_keep_segments = 64
#archive_mode = on
#archive_command = 'cp %p $LOG_DIR/archive/%f'

И раскомментировать:

hot_standby = on

Так же на Serv2 в $HOME переименовать recovery.done в recovery.conf

Запустить postgres на Serv2. Теперь Serv2 снова работающий слейв.

Готово. Теперь все на своих местах: Serv1 — master, Serv2 — slave.

---

Заранее прошу прощения за долю копипаста и низкоуровневое разжевывание, но целостно и доступно для простых смертных эта информация в сети не нашлась, так что, надеюсь, найдет применение (: