Создаём кластер для PostgreSQL

Андрей Тренин

Создаём кластер для PostgreSQL

PostgreSQL – мощная СУБД с конвейера Open Source, способная легко конкурировать с такими гигантами, как Oracle и MS SQL. К сожалению, наряду с полезными утилитами, такими как pg_autovacuum, в нем отсутствует возможность репликации. Что делать, если такая опция вам необходима?

Эта статья будет интересна читателям, имеющим начальные знания в области РБД, и будет полезна системным администраторам организаций, использующим PostgreSQL (http://www.postgresql.org) для хранения достаточно большого объема информации (1 Гб и более), которая является не статической, а наоборот, динамично изменяющейся и дополняющейся, которую очень легко потерять и трудно восстановить в установленные руководством сроки.

Немного о PostgreSQL

Это мощная система управления реляционными базами данных, поддерживающая расширенное подмножество стандарта SQL. Включает в себя: транзакции, внешние ключи, подзапросы, триггеры, пользовательские типы данных, функции и многое другое. Причем функции могут быть написаны на C, Perl, Python, Tcl и JDBC. Также следует учесть, что это чудо разработано не на «коленках», а в University of California at Berkeley (UCB).

Как PostgreSQL «попадает в дом» – есть несколько способов. Начинаем его использовать как хранилище однотипных данных для сайта, или покупаем систему класса CRM, ERP отечественной сборки, в принципе это не важно. Важно то, что данных становится со временем все больше, от этого увеличивается их важность, и даже за кратковременную паузу в доступе к данным вам «стучат по голове» и не дают долгожданную премию.

Простои в работе любого хранилища данных неизбежны (плановая профилактика, замена комплектующих или «уборщица пробралась в серверную») и встает вопрос: «Как сделать так, чтобы доступ к данным был возможен всегда?». Ответ прост – нужно иметь как минимум две параллельные системы, взаимозаменяющие друг друга, чтобы во время простоя одной – другая работала как ни в чем не бывало. Однако наряду с преимуществами данной схемы, мы получаем сопутствующие недостатки, а именно:

• систем становится как минимум больше одной – надо думать над синхронизацией данных;
• поломка одной из систем – нужно сделать период времени между сбоем и отключением вышедшей из строя системы как можно менее продолжительным для внешних приложений.

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

PgPool

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

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

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

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

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

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

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

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

Slony-I

Slony-I – это репликационная система по схеме «один master плюс много slave». Запускается на POSIX и этим все сказано. Лицензия – BSD. Забегая вперед, скажу – поддерживает динамическое реконфигурирование кластера.

Данный проект задумывался как репликационная система, независящая от какой-то конкретной версии PostgreSQL, и одновременно с этим не требующая перезапуска серверов БД, для того чтобы начать или прекратить работу. Однако, как и все универсальные системы, Slony-I имеет очень много недостатков. Первое – неумение определить недоступность базы данных и как следствие отстранить ее от работы. Второе – Slony-I не является мультимастерной репликационной системой, что в совокупности с невозможностью автоматического перехода сервера с режима slave на master делает область ее применения довольно узкой.

Вот лишь некоторые примеры, где данная система не будет работать:

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

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

Примерное описание репликации приведено в документации – http://slony1.projects.postgresql.org/slony_tip/adminguide/slonyadmin.html#FIRSTDB, от себя лишь добавлю, что оно ввиду чрезмерной сложности заслуживает отдельной статьи.

Сравниваем  продукты

Перейдем к оценке этих изделий. Определим её параметры, так как системы три, то и оценивать будем по трехбалльной шкале (3 – хорошо, 2 – могло быть и лучше, 1 – плохо).

• Установка – данный показатель оценивает возможность установки на максимальное количество типов ОС, простоту процесса инсталляции, размер дистрибутива и сложность постинсталляционной настройки.
• Системные требования – следующий показатель, оценивающий количество серверов и его мощность, необходимые для нормального функционирования системы в целом.
• Документация – этот показатель ставит оценку наличию, доступности и понятности изложения всех источников информации (сайт производителя, документация на продукт, mail-листы) необходимых для установки и обслуживания системы.
• Скорость работы – данный показатель количественно в ходе опыта оценить не удалось ввиду того, что составленный стресс-тест проверял в основном надежность, к тому же на сайтах производителей количественная оценка есть (результаты pgbench). Однако качественную оценку скорости каждому продукту поставить получилось на основе их архитектурных особенностей и визуальных наблюдений в ходе опытов (браузер, «ps ax» и т. д.).
• Стабильность работы – здесь обещанное в документации я сравнивал с действительностью, то есть с тем, что я видел на системе, установленной мною лично.
• Широта области применения – при оценке данного показателя я принимал во внимание следующие параметры: количество работающих одновременно серверов БД, возможность горячего исключения/подключения серверов БД. Все тесты и оценки делались на тестовом полигоне крупного зарубежного online-аукциона c количеством ставок при стресс-тестах порядка 430 тысяч в день и базой данных на 8 Гб.

Результаты оценки сведены в таблицу.

Таблица показателей

Подведем итог

Как мы видим, в таблице нет колонки «Итого», потому что если просуммировать проставленные оценки, то получим лидера PgPool, если введем вес для каждого показателя, то, безусловно, выиграет PGCluster, так как вес буду проставлять я.

Целью данной статьи является не выдвижение вперед какого-то одного продукта или занижение ценности другого. Наоборот, статья явным образом показывает, что все продукты достойны использования, но именно там, где они будут наиболее эффективны. Например, у вас есть сайт информационного значения, его простои не несут ощутимых убытков, вы не можете позволить себе дополнительное оборудование, да и желания разбираться с новым софтом, быть может, не имеете, то PgPool – ваш выбор. Или же у вас есть мощная корпоративная система, остановка работы которой пользователи воспримут как выходной, а вы как увольнение, содержание отдела программно-технического обеспечения не несет серьезных трат для компании, то ваш выбор очевиден – PGCluster. Это и мой выбор, ведь для приемлемой работы проекта вполне достаточно использовать конфигурацию по умолчанию – большая часть необходимых параметров уже инициализированы. А при необходимости вы всегда сможете изменить настройки на нужные вам.

Постараюсь объяснить, где можно использовать Slony-I. Данный программный продукт необходимо использовать в совокупности с другими средствами, как хорошо настраиваемую, с большим запасом интегрируемости часть какой-то большой системы. Скорее всего, проект будет полезен больше разработчикам информационных систем, чем их пользователям.

Ссылки:

1. http://pgpool.projects.postgresql.org.
2. http://pgcluster.projects.postgresql.org.
3. http://slony1.projects.postgresql.org.