PostgreSQL Failover - Какие инструменты мне следует использовать?

Вот сценарий:

На CentOS 6.2 установлены две машины - machine0 и machine1

На обоих установлен PostgreSQL 9.1.

Один из них должен быть активным, поскольку в качестве главной системы и посредством асинхронной потоковой репликации на другом компьютере резервный сервер должен копировать изменения в базу данных из главной системы.

Предполагая, что machine0 является ведущим, а machine1 является резервным в начале.

Если мастер (скажем, machine0) выходит из строя (в данном случае сбой означает, что сервер postgresql дает сбой), резервный сервер должен получить управление от мастера и стать новым мастером.

machine1, новый мастер обрабатывает все операции с базой данных, и когда сервер postgresql на machine0 возвращается в оперативный режим, он должен перейти в режим ожидания, начать синхронизацию с той точки, в которой он потерял связь с machine1, и скопировать все изменения в базу данных и остаться в режиме ожидания.

Когда машина1 выходит из строя, весь цикл повторяется.

Когда сбой в режиме ожидания возвращается в рабочее состояние, он должен начать чтение с мастера и синхронизировать данные.

Я не совсем понимаю, какие инструменты мне нужно использовать для настройки, так как я понимаю, что PostgreSQL по умолчанию не поддерживает аварийное переключение.

Если кто-то может связать меня с темами / страницами, которые описывают, как делать то, что я пытаюсь, я буду очень благодарен.

Если вы заинтересованы в синхронной репликации БД и отказоустойчивости, у меня есть предложение. Вы можете изучить использование двух инструментов:

• DRBD (блочное устройство с репликацией дисков) обеспечивает репликацию на уровне дисков (синхронно) между дисками на двух разных серверах. Изменения диска реплицируются по сети. Лучше всего использовать перекрестный кабель на eth2 для сетевых карт, использующих сетевой блок 192.168.xx.

• ucarp обеспечивает управление DBVIP и отработку отказа между двумя разными серверами.

Вы можете использовать их вместе следующим образом:

• DBServer1 имеет IP 10.1.2.30
• DBServer2 имеет IP 10.1.2.40
• БД VIP 10.1.2.70

Настройте ucarp на два разных сервера таким образом, чтобы каждый экземпляр ucarp связывался с другим по идентификатору виртуального маршрутизатора.

DBServer1 будет иметь

/usr/local/sbin/ucarp -v 200 -p sometagname --interface=eth2 -a 10.1.2.70 -s 10.1.2.30 -b 3 -r 5 --upscript=/usr/local/sbin/vip-up.sh --downscript=/usr/local/sbin/vip-down.sh --neutral -z -B

DBServer2 будет иметь

/usr/local/sbin/ucarp -v 200 -p sometagname --interface=eth2 -a 10.1.2.70 -s 10.1.2.40 -b 4 -r 5 --upscript=/usr/local/sbin/vip-up.sh --downscript=/usr/local/sbin/vip-down.sh --neutral -z -B

В чем причина -b (широковещательные сообщения) - 3 на одном сервере и 4 на другом? В случае перезапуска обоих серверов, сервер с наименьшим значением -b сначала выведет ucarp. Что касается -r, это соотношение мертвых. Таким образом, DBServer1 появится через 15 секунд (3X5), а DBServer2 появится через 20 секунд (4X5).

Допустим, сбой DBServer1. ucarp на DBServer2 в течение 20 секунд проверяет наличие подтверждения связи с ucarp на DBServer1. Если ничего не обнаружено, сценарий vip-up.sh на DBServer2 будет управлять DBVIP.

ОК, все это только для отработки отказа и управления DBVIP. А как насчет базы данных PostgreSQL? Удивительно, но PostgreSQL одновременно работает только на одном сервере. Кто бы ни имел DBVIP, должен иметь DRBD в Первичном состоянии. Это связано со сценарием vip-up. Как вы это сценарий?

Вот скрипт /usr/local/sbin/vip-down.sh (концептуальный)

#! /bin/sh
exec 2> /dev/null
/sbin/drbdadm disconnect drbd0
/sbin/drbdadm  primary drbd0 &&
/bin/mount postgres-data-folder /mnt/drbd0
/sbin/ip addr add 10.1.2.70/24 dev eth2
/sbin/service postgres start &&
/usr/local/sbin/vipmon.sh &
touch /tmp/vip-up

Вот скрипт /usr/local/sbin/vip-down.sh (концептуальный)

#! /bin/sh
exec 2> /dev/null
/sbin/service postgres stop
/bin/umount -l  /dev/drbd0
/sbin/drbdadm secondary drbd0
/sbin/ip addr del 10.1.2.70/24 dev eth2
/bin/rm /tmp/vip-up
/usr/bin/killall -9 ucarp
/usr/local/sbin/vip-down.sh
kill `ps auxww | grep vipmon | awk '{print $2}'`

Все, что вам нужно сделать, это настроить pg_hba.conf, чтобы убедиться, что все пользователи приходят через 10.1.2.70

По сути, vip-up выполняет эту последовательность

• У ДРБД пройти начальную школу
• Смонтировать папку данных postgres в / dev / drbd0
• Стартап постгрес
• начать процесс vipmon

И наоборот, vip-down выполняет эту последовательность

• Отключение postgres
• unount / dev / drbd0
• У ДРБД перейти на среднее

Как насчет vipmon.sh? Вы можете написать это, чтобы проверить в неопределенном цикле состояние postgres (он запущен), проверить устройство DRBD (вы все еще можете записать в папку данных posts)

При такой настройке у вас есть postgres на первичном DRBD и на уровне диска копия папки данных postgres на другом DBServer (вторичном DRBD). Postgres не работает на вторичном сервере DRBD.

Когда происходит аварийное переключение, вам просто нужно время, чтобы ucarp обнаружил, безопасно ли монтировать данные postgres, запускать postgres и активировать скрипт vipmon.

Что хорошо в этой настройке, так это то, что в случае аварийного переключения DBServer, который становится DRBD Primary, должен иметь 100% копию уровня диска сервера, с которого вы отказались. Таким образом, запуск postgres должен выровнять вас в согласованном состоянии. Журналы транзакций (в pg_xlog) должны быть в такте (меньше прерываний из-за аварийного переключения)

Я надеюсь, что эти предложения помогут. Хотя я и являюсь администратором баз данных MySQL, я регулярно использую MySQL и DRBD в веб-хостинговой компании моего работодателя. Я установил MySQL / DRBD вышеупомянутым способом. Я сделал это один раз для клиента, использующего PostgreSQL / DRBD. Это прекрасно работает. Это с открытым исходным кодом. Вам просто нужно провести должную осмотрительность в изучении DRBD и ucarp. Это будет включать в себя повторное подключение DRBD после аварийного переключения, обработку сценария с разделенным мозгом, когда оба сервера БД переходят на основной, и тому подобное.