§ Skytools-3.0 Simple replication.

Настройка потабличной репликации в PostgreSQL с помощью Skytools.

В статье описывается процесс настройки потабличной репликации с помощью Skytools 3.0. Как известно встроенная потоковая репликация, реплицирует полностью кластер, в том числе и все базы входящие в кластер. Но иногда случается что среплицировать нужно всего одну базу или даже всего несколько таблиц. Здесь на помощь приходит Londiste из пакета Skytools.
Итак у нас есть мастер и машина которая в итоге будет выполнять роль слейва. В терминах Skytools это провайдер (provider) и подписчик (subscriber). Всю настройку будем выполнять на стороне подписчика. Вообще Skytools удобен тем что настройку репликации можно с одинаковым успехом выполнять как на провайдере так и на подписчике, итоговый результат будет один. Если сравнивать с потоковой репликацией, то можно отметить что необходимо делать специальные правки как на мастере так и на слейве. 
Есть два хоста: fobos - provider, он же мастер. И deimos - subscriber, он же слейв. Все действия выполняются только на deimos. Предварительно стоит отметить что на обоих хостах установлены пакеты PostgreSQL и с обоих хостов можно заходить в консоль psql удаленного сервера (pg_hba.conf).

Устанавливаем Skytools.

# cave resolve skytools
# chown postgres: /var/run/skytools/
# chown postgres: /var/log/skytools/

Выполняем настройку Londiste, у нас будет два конфигурационных файла, один для провайдера и один для подписчика. В конфигурации указывается хост для подключения и имена задачи и очереди. Имя очереди в обоих конфигах должно совпадать.
# vi /etc/skytools/londiste-master.ini
[londiste3]
job_name = appqueue
db = dbname=appdb host=fobos
queue_name = appqueue
logfile = /var/log/skytools/fobos.log
pidfile = /var/run/skytools/fobos.pid

# vi /etc/skytools/londiste-slave.ini 
[londiste3]
job_name = appqueue
db = dbname=appdb
queue_name = appqueue
logfile = /var/log/skytools/deimos.log
pidfile = /var/run/skytools/deimos.pid

Выполняем установку схемы londiste на хост провайдера
# qadmin -h fobos -U postgres -d appdb -c "install londiste"
Server version 9.0.7
INSTALL

После чего нужно перенести пустую схему реплицируемой базы на хост подписчика
# pg_dump -h fobos -s -C -U postgres appdb |psql -U postgres

Теперь выполняем инициализацию провайдера
# su postgres -c "londiste3 /etc/skytools/londiste-master.ini create-root fobos 'dbname=appdb host=fobos'"
INFO plpgsql is installed
INFO pgq is installed
INFO pgq.get_batch_cursor is installed
INFO pgq_ext is installed
INFO pgq_node is installed
INFO londiste is installed
INFO londiste.global_add_table is installed
INFO Initializing node
INFO Location registered
INFO Node "fobos" initialized for queue "appqueue" with type "root"
INFO Done

На очереди инициализация подписчика
# su postgres -c "londiste3 /etc/skytools/londiste-slave.ini create-leaf deimos dbname=appdb --provider='host=fobos dbname=appdb'"
INFO plpgsql is installed
INFO pgq is installed
INFO pgq.get_batch_cursor is installed
INFO pgq_ext is installed
INFO pgq_node is installed
INFO londiste is installed
INFO londiste.global_add_table is installed
INFO Initializing node
INFO Location registered
INFO Location registered
INFO Subscriber registered: deimos
INFO Location registered
INFO Location registered
INFO Node "deimos" initialized for queue "appqueue" with type "leaf"
INFO Done

Теперь запускаем Londiste для обоих узлов в качестве сервисов.
# su postgres -c "londiste3 -d /etc/skytools/londiste-slave.ini worker"
# su postgres -c "londiste3 -d /etc/skytools/londiste-master.ini worker"

Теперь следует настроить и запустить сервис PgQ
# vi /etc/skytools/pgqd.ini
[pgqd]
logfile = /var/log/skytools/pgqd.log
pidfile = /var/run/skytools/pgqd.pid
base_connstr = host=fobos
# /etc/init.d/pgqd start

Теперь все готово для непосредственного запуска процесса репликации, но сначала проверим состояние сервисов
# su postgres -c "londiste3 /etc/skytools/londiste-master.ini status"
Queue: pulscen   Local node: fobos
fobos (root)
  |                           Tables: 0/0/0
  |                           Lag: 13s, Tick: 13
  +--deimos (leaf)
                              Tables: 0/0/0
                              Lag: 13s, Tick: 13

# su postgres -c "londiste3 /etc/skytools/londiste-master.ini members"
Member info on fobos@appqueue:
node_name        dead             node_location
---------------  ---------------  -------------------------
deimos           False            dbname=appdb
fobos            False            dbname=appdb host=fobos

Так все хорошо, узлы отображаются как и положено. Теперь настроим репликацию для любой произвольной таблицы. Сначала добавляем ее на стороне провайдера, затем добавляем ее на стороне подписчика. Как только она будет добавлена в подписчике, для этой таблицы, тут же запустится механизм репликации.
# su postgres -c "londiste3 /etc/skytools/londiste-master.ini add-table ip_infos"
INFO Table added: public.ip_infos
# su postgres -c "londiste3 /etc/skytools/londiste-slave.ini add-table ip_infos"
INFO Table added: public.ip_infos

Смотрим состояние таблицы (колонка merge_state)
# su postgres -c "londiste3 /etc/skytools/londiste-slave.ini tables"
Tables on node
table_name       merge_state      table_attrs
---------------  ---------------  ---------------
public.ip_infos  in-copy
# su postgres -c "londiste3 /etc/skytools/londiste-slave.ini tables"
Tables on node
table_name       merge_state      table_attrs
---------------  ---------------  ---------------
public.ip_infos  ok

Также можно просмотреть ход выполнения репликации в журналах
# tail -f /var/log/skytools/deimos.log
INFO Table added: public.ip_infos
INFO Dropping fkey: fk_ip_infos_city_id
INFO storing state of public.ip_infos: copy:0 new_state:in-copy
INFO Table public.ip_infos status changed to 'in-copy'
INFO Launching copy process
INFO Registering consumer on source queue
INFO Consumer appdb.copy.public.ip_infos registered on queue appqueue
INFO Consumer uptodate = 1
INFO pgq.maint_operations is installed
INFO Starting full copy of public.ip_infos
INFO Dropping public.i_uniq_ip_infos_on_ip_end
INFO Dropping public.i_uniq_ip_infos_on_ip_start
INFO Dropping ip_infos_pkey
INFO public.ip_infos: truncating
INFO public.ip_infos: start copy
INFO public.ip_infos: copy finished: 1706174 bytes, 48106 rows
INFO storing state of public.ip_infos: copy:1 new_state:catching-up
INFO Creating ip_infos_pkey
INFO Creating public.i_uniq_ip_infos_on_ip_start
INFO Creating public.i_uniq_ip_infos_on_ip_end
INFO storing state of public.ip_infos: copy:1 new_state:wanna-sync:47
INFO Table public.ip_infos status changed to 'wanna-sync:47'
INFO storing state of public.ip_infos: copy:0 new_state:do-sync:47
INFO Table public.ip_infos status changed to 'do-sync:47'
INFO storing state of public.ip_infos: copy:1 new_state:ok
INFO Table public.ip_infos status changed to 'ok'
INFO Unregistering consumer from source queue
INFO Consumer appdb.copy.public.ip_infos unregistered from appqueue
INFO got SystemExit(0), exiting
INFO storing state of public.ip_infos: copy:0 new_state:ok

На данный момент таблицы ip_infos успешно среплицирована. Среплицировать все таблицы можно следующим образом:
# su postgres -c "londiste3 /etc/skytools/londiste-master.ini add-table --all"
# su postgres -c "londiste3 /etc/skytools/londiste-slave.ini add-table --all"

Проверить работу репликации можно следующим образом
 # su postgres -c "londiste3 /etc/skytools/londiste-slave.ini compare"
INFO Locking public.ip_infos
INFO Syncing public.ip_infos
INFO Counting public.ip_infos
INFO srcdb: 48106 rows, checksum=216581594890
INFO dstdb: 48106 rows, checksum=216581594890

В процессе выполнения команды создается логическая точка относительно которой подсчитывается количество строк и контрольная сумма строк в таблицах на стороне провайдера (мастера) и подписчика (слейва).

На этом все... В качестве вывода, как бы отвечу на вопрос, где может понадобиться такая репликация. Мы использовали Londiste из пакета Skytools 2 для онлайн миграции с PostgreSQL 8.4 на 9.0 и Skytools 3 для перехода с PostgreSQL 9.0 на недавно вышедший 9.2. Применение Londiste позволило прозрачно для клиентов обновить production кластер без остановки проекта. Во втором случае обновлялся кластер с потоковой репликацией. Об этом в следующий раз.

На главную "Virtualizing Linux"