Предисловие
Доброго времени суток. Так уж исторически сложилось, что из коробки Postgresql 8й ветки(а светлое будущее с 9й в стейбле еще не наступило) не имеет системы репликации. Поэтому для этих целей написан внешний инструмент — Slony1.
Как это работает
.Работает он довольно просто: демон slon подключается к Postgresql-серверу, цепляется за триггеры и ждёт, когда произойдёт какое-нибудь событие, изменяющее содержимое базы. Так же есть slonik — конфигурационная утилитка, употребляющая в STDIN конфиги и еще несколько управляющих утилит для различных целей.
В рамках репликации, когда речь заходит о Postgresql, обычно используются следующие термины:
- Нода(node) — пара «сервер-база». То есть, например, если у вас на одном сервере несколько баз, участвующих в репликации — это не одна нода, а несколько.
- Кластер(cluster) — группа нод. Тут всё просто, я полагаю: мастер и слейв(ы).
- Таблицы(tables) — тут всё еще проще. :)
- Секвенсы(sequences) — счётчики для таблиц.
- Сеты(sets) — набор таблиц и счетчиков. Для каждой базы создаётся отдельный сет.
После удачной конфигурации Slony создаёт в базе, которая подлежит репликации схему _cluster(где «cluster» — название кластера, указанное в конфиге), а в ней — несколько своих таблиц. С назначением таблиц можно ознакомиться в офф. документации, ну или применив psql. Так что если вдруг в процессе настройки вы столкнулись с трудностями, а после перезапуска получили сообщение вида «эта нода/кластер/таблица уже есть в списке» — возможно вас спасёт дроп схемы.
Так же вам нужно знать, что репликации подлежат только те таблицы, которые имеют primary key.
Главной неприятной особенностью слонов, для меня стало то, что оно не умеет делать реплику всех таблиц в базе — обязательно нужно перечислить одну за другой. Когда у вас в базе >50 таблиц — написание конфигов становится крайне утомительным занятием. Для этих целей мной был написан скрипт, выложенный ниже.
Самые любознательные из вас наверняка видели подобные маны и возможно считают, что этот пост — очередной дубль. Нет, это не так. Все маны, которые я видел, предлагали скармливать конфиг непосредственно в slonik через STDIN. При таком подходе система заработает, но(по крайней мере в случае с Debian/Ubuntu) будут две проблемы:
- Не будет работать init-скрипт
- Не будут работать вспомогательные утилитки слонов.
Правильный же подход заключается в том, чтобы хранить perl-овидный конфиг в /etc/slony1/slon_tools.conf(пример вы можете найти в ls /usr/share/doc/slony1-bin/examples/slon_tools.conf-sample.gz), а в /etc/default/slony1 — номера нод, которые живут на данной машине и будут запущены init-скриптом. Как я уже сказал — первый конфиг является perl-скриптом и инклюдится в скрипт slon_start. В целом — конфигурация руками в этом посте не рассматривается — только рассказывается, где можно найти примеры.
Подготовка.
Будем считать, что база, равно как и настроенный Postgresql, у вас уже есть, в ней есть таблицы с primary key и вы готовы приступить к настройке. Заранее оговорюсь, что всё делалось на различных версиях серверной Ubuntu, в Debian будет примерно то же самое, а вот что будет в других дистрах — я не знаю.
Итак нам нужны пакеты postgresql-8.3-slony1 и slony1-bin. Желательно, чтобы оба пакета были второй ветки(она стабильнее).
Настройка серверов
Сначала в postgresql.conf нужно раскомментировать строку, содержащую «listen_addresses» и поставить вместо localhost указать ip-адрес интерфейса, смотрящего в сторону слейва. Так же можно вместо адреса поставить '*' — тогда сервер будет ожидать подключения по всем интерфейсам.
Далее, в pg_hba.conf(тоже в /etc/postgresql лежит) нужно добавить строку вида
host all all 192.168.1.0/24 md5 , где вместо 192.168.0.0/24 нужно указать сеть или ip слейва. Далее делаем тоже самое на слейве, указывая ip мастера.
Далее рестартим Postgresql на мастере и слейве, дабы оно подхватило новые настройки.
Еще нам нужно будет создать pg-суперпользователя на обеих машинах:
createuser -sP slonyСкрипт
Дабы не увеличивать в несколько раз размер поста, скрипт вынесен сюда. Заранее скажу, что я не претендую на приз за красоту кода — напротив, он писался на коленке в свободное время. Важно другое — он работает. Теперь я расскажу о том, что он делает.
Для нормальной работы вам потребуется запускать его от root`a или через sudo(т.к. там, используется su в пользователя postgres, а так же производится запись в /etc и выполняются init-скрипты) так же желательно(для выполнения последних двух стадий), чтобы slave пускал к себе root`a по ssh(лучше ключом, т.к. пароль вводить быстро надоест). Так же необходим пакет libdbd-pg-perl.
Текущая версия не жрёт параметры из командной строки(хотя следовало бы), поэтому после запуска вы вступите в диалог со скриптом. Итак, алгоритм работы пошагово:
1. Опрос пользователя на предмет названия кластера и реквизитов к мастеру/слейву.
Если ошиблись — не беда, в случае проблем с подключением к базе скрипт предложит ввести данные еще раз. Название кластера произвольно.
2. Диалог выбора баз.
Тут всё просто. Скрипт опрашивает сервер на предмет имеющихся баз и предлагает выбрать те, которые нужно реплицировать. Для выбора(или отмены выбора) базы нужно ввести её номер. Звёздочкой можно выбрать все. По окончанию нужно нажать Enter.
3. Добавление таблиц/последовательностей.
Имея список выбранных баз, скрипт собирает из них список таблиц. В список добавляются все таблицы и последовательности, находящиеся в выбранных базах.
4. Перенос структуры базы с мастера на слейв
Последовательно выполняется удалённые createdb, createlang. Далее локальный pg_dump -s после чего структура передаётся по ssh на slave.
5.Непосредственная генерация конфига и его пересылка.
Все необходимые данные есть, теперь генерится конфиг и, если вы root, кладётся в /etc/slony1(в том числе на слейв), редактируется /etc/default/slony1(указывается, какие ноды следует запускать).
6. Запуск демона
Ну вот собственно и всё. Осталось запустить. :)
P.S.
Надеюсь, кому-нибудь это будет полезно, если есть вопросы или вдруг что-то работает не так — велкам в комменты.
