PgPool посылает одинаковые SQL-команды на оба сервера, тем самым достигается эффект репликации. Если один из серверов ломается/отключается – демон пытается продолжить работу с оставшимся в живых. К сожалению, чтобы ввести сервер обратно в строй, придется остановить всю систему, провести синхронизацию данных, например утилитой rsync или дистрибутивными pg_dump/pg_restore и после этого все опять включить.

Преимущество данной схемы очевидно – система отключается не тогда, когда она хочет, а тогда, когда запланируем мы, конечно же, при условии низкой вероятности отказа двух серверов в течение, скажем, 4-12 часов, столько времени вполне хватит для прибытия на работу и неспешного восстановления работоспособности программных средств.

Устанавливать и настраивать PgPool очень легко. Допустим, у нас есть два сервера PostgreSQL. На один из них устанавливаем демон и в конфигурационном файле выставляем ему master, другому – slave, еще немного правим его (он всего один!), если необходимо, и все – мы имеем в наличии репликационный сервер.

PGCluster

PGCluster – синхронизирующаяся репликационная система с мультимастерной композиционной схемой для PostgreSQL. Сейчас проект имеет пограничный статус между стадией тестирования и работающей без видимых ошибок, но будем считать, что проект можно использовать, ибо программных продуктов без скрытых дефектов все равно не бывает. Лицензия – BSD. Устанавливается на FreeBSD, Linux, SunOS/Solaris.

Схема работы гораздо более сложная, чем в предыдущем случае. PGCluster состоит из трех видов серверов (в данном случае я советую не использовать контексты, а разнести все по разным машинам), а именно: балансер (front-end), кластер БД (здесь данные), репликационный сервер. Хотя схема, показанная на следующем рисунке, довольно проста (рис. 1), для того чтобы привести систему в рабочее состояние, может потребоваться очень много времени.

Рисунок 1. Общая схема работы PGCluster

Установка PGCluster есть установка PostgreSQL, ибо PGCluster и есть модифицированный PostgreSQL, а вот настройка трех типов конфигурационных файлов (по одному на каждый тип серверов) является задачей не тривиальной. Сколько нужно настроить параметров, станет очевидным после рассмотрения схемы репликации (рис. 2).

Рисунок 2. Схема репликации в PGCluster

Рассмотрим самое тяжелое. Когда один из кластеров БД «падает», балансер и репликационный сервер, постоянно отслеживающие жизнедеятельность кластеров БД, отделяют сломанный кластер БД от работоспособной части системы и продолжают работу с оставшимися кластерами БД. После этого необходимо устранить неисправность упавшего сервера и подсоединить к системе в режиме репликации. После этого репликационный сервер запишет данные с работающих серверов поверх имеющихся на реплицируемом сервере плюс выполнит запросы за время простоя в автоматическом режиме, останется только включить сервер в обычном режиме.

Как мы видим, наряду с преимуществами PgPool, мы имеем еще и горячую замену, что позволяет не выключать систему целиком. В заключение лишь добавлю, что по начальным настройкам можно использовать максимально 128 кластеров БД.