Это мощная система управления реляционными базами данных, поддерживающая расширенное подмножество стандарта SQL. Включает в себя: транзакции, внешние ключи, подзапросы, триггеры, пользовательские типы данных, функции и многое другое. Причем функции могут быть написаны на C, Perl, Python, Tcl и JDBC. Также следует учесть, что это чудо разработано не на «коленках», а в University of California at Berkeley (UCB).
Как PostgreSQL «попадает в дом» – есть несколько способов. Начинаем его использовать как хранилище однотипных данных для сайта, или покупаем систему класса CRM, ERP отечественной сборки, в принципе это не важно. Важно то, что данных становится со временем все больше, от этого увеличивается их важность, и даже за кратковременную паузу в доступе к данным вам «стучат по голове» и не дают долгожданную премию.
Простои в работе любого хранилища данных неизбежны (плановая профилактика, замена комплектующих или «уборщица пробралась в серверную») и встает вопрос: «Как сделать так, чтобы доступ к данным был возможен всегда?». Ответ прост – нужно иметь как минимум две параллельные системы, взаимозаменяющие друг друга, чтобы во время простоя одной – другая работала как ни в чем не бывало. Однако наряду с преимуществами данной схемы, мы получаем сопутствующие недостатки, а именно:
PgPool – подсоединяемый пул/репликационный сервер для PostgreSQL. Он написан Tatsuo Ishii (t-ishii@sra.co.jp). На сегодняшний день проект имеет оттестированную версию. Разрешается использовать по BSD-лицензии (бесплатно), можно ставить на FreeBSD, Linux, SunOS/Solaris и собственно написан программный продукт на всеми любимом C.
При ближайшем рассмотрении выясняется, что PgPool представляет из себя прослойку-демон, то есть запускается между клиентами и хранилищем данных, причем клиентов дополнительно настраивать не надо, что безусловно хорошо. Этот демон может образовывать пул к PostgreSQL для ограничения предоставленных соединений самой базой данных. И, наконец, может объединить два сервера в систему (master – slave).
PgPool посылает одинаковые SQL-команды на оба сервера, тем самым достигается эффект репликации. Если один из серверов ломается/отключается – демон пытается продолжить работу с оставшимся в живых. К сожалению, чтобы ввести сервер обратно в строй, придется остановить всю систему, провести синхронизацию данных, например утилитой rsync или дистрибутивными pg_dump/pg_restore и после этого все опять включить.
Преимущество данной схемы очевидно – система отключается не тогда, когда она хочет, а тогда, когда запланируем мы, конечно же, при условии низкой вероятности отказа двух серверов в течение, скажем, 4-12 часов, столько времени вполне хватит для прибытия на работу и неспешного восстановления работоспособности программных средств.
Устанавливать и настраивать PgPool очень легко. Допустим, у нас есть два сервера PostgreSQL. На один из них устанавливаем демон и в конфигурационном файле выставляем ему master, другому – slave, еще немного правим его (он всего один!), если необходимо, и все – мы имеем в наличии репликационный сервер.
PGCluster – синхронизирующаяся репликационная система с мультимастерной композиционной схемой для PostgreSQL. Сейчас проект имеет пограничный статус между стадией тестирования и работающей без видимых ошибок, но будем считать, что проект можно использовать, ибо программных продуктов без скрытых дефектов все равно не бывает. Лицензия – BSD. Устанавливается на FreeBSD, Linux, SunOS/Solaris.
Схема работы гораздо более сложная, чем в предыдущем случае. PGCluster состоит из трех видов серверов (в данном случае я советую не использовать контексты, а разнести все по разным машинам), а именно: балансер (front-end), кластер БД (здесь данные), репликационный сервер. Хотя схема, показанная на следующем рисунке, довольно проста (рис. 1), для того чтобы привести систему в рабочее состояние, может потребоваться очень много времени.
Установка PGCluster есть установка PostgreSQL, ибо PGCluster и есть модифицированный PostgreSQL, а вот настройка трех типов конфигурационных файлов (по одному на каждый тип серверов) является задачей не тривиальной. Сколько нужно настроить параметров, станет очевидным после рассмотрения схемы репликации (рис. 2).
Рассмотрим самое тяжелое. Когда один из кластеров БД «падает», балансер и репликационный сервер, постоянно отслеживающие жизнедеятельность кластеров БД, отделяют сломанный кластер БД от работоспособной части системы и продолжают работу с оставшимися кластерами БД. После этого необходимо устранить неисправность упавшего сервера и подсоединить к системе в режиме репликации. После этого репликационный сервер запишет данные с работающих серверов поверх имеющихся на реплицируемом сервере плюс выполнит запросы за время простоя в автоматическом режиме, останется только включить сервер в обычном режиме.
Как мы видим, наряду с преимуществами PgPool, мы имеем еще и горячую замену, что позволяет не выключать систему целиком. В заключение лишь добавлю, что по начальным настройкам можно использовать максимально 128 кластеров БД.
Slony-I – это репликационная система по схеме «один master плюс много slave». Запускается на POSIX и этим все сказано. Лицензия – BSD. Забегая вперед, скажу – поддерживает динамическое реконфигурирование кластера.
Данный проект задумывался как репликационная система, независящая от какой-то конкретной версии PostgreSQL, и одновременно с этим не требующая перезапуска серверов БД, для того чтобы начать или прекратить работу. Однако, как и все универсальные системы, Slony-I имеет очень много недостатков. Первое – неумение определить недоступность базы данных и как следствие отстранить ее от работы. Второе – Slony-I не является мультимастерной репликационной системой, что в совокупности с невозможностью автоматического перехода сервера с режима slave на master делает область ее применения довольно узкой.
Вот лишь некоторые примеры, где данная система не будет работать:
Примерное описание репликации приведено в документации – http://slony1.projects.postgresql.org/slony_tip/adminguide/slonyadmin.html#FIRSTDB, от себя лишь добавлю, что оно ввиду чрезмерной сложности заслуживает отдельной статьи.