Если вы заинтересованы в синхронной репликации БД и отказоустойчивости, у меня есть предложение. Вы можете изучить использование двух инструментов:
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 после аварийного переключения, обработку сценария с разделенным мозгом, когда оба сервера БД переходят на основной, и тому подобное.