Впервые встала задача единоличной реализации полноценной репликации и впервые был написан мини-мануал, который и хочу здесь представить.
Для системы репликации Мастер-Слейв использовалась комбинация PostgreSQL 9.1 (БД) + Bucardo 4.5 (репликатор) + PgPool-II (пулер и файловер)
Bucardo
Асинхронная Postgres replication system написанная на Perl5.
Удобна встраиваемостью в постгрес и легкой, отражаемой в бд, настройкой.
Создает свою БД, в которой прописываются реплицируемые сервера, базы, таблицы, заключаемые в листы (списки). Используется тип связи Pushdelta (Trigger. One way master-slave). Изменение структуры не поддерживает. Работает в обе стороны, т.е. в случае временного отключения мастера, при его восстановлении, он автоматически «догонит» слейв.
Далее вручную создать управляющую бд bucardo, наполнить ее из bucardo.schema (по умолчанию он прицеплен к 8.4 и в старших версиях осечка с автосозданием управляющей бд)
sudo bucardo_ctl add db bucardo_dbname name=master_dbname # Назначение БД-мастера # + в бд ручками пароль в bucardo.db (дабы не возникало проблем) sudo bucardo_ctl add db bucardo_dbname name=slave_dbname # Назначение БД-слейва sudo bucardo_ctl add table tbl_name db=bucardo_dbname herd=source_name # Добавление таблиц мастера в список(herd) sudo bucardo_ctl add sync sync_name type=pushdelta source=herd_name targetdb=slave_dbname # Назначение списка для репликации sudo bucardo_ctl start # Запуск репликации
На слейве я его устанавливала, но не заполняла (т.к. слейв один и с него идти все равно некуда)
PgPool-II
Имеет широкие возможности, страдает нехваткой мануалов. Поддерживает параллельные запросы, балансировку нагрузки, распределение коннектов к БД по пулам, а так же является FailOver'ом, т.е. автоматическим переключателем с мастера на слейв и обратно в случаях проблем с соединениями.
На debian ставится из репозитория, от версии postgres не зависит. sudo aptitude install pgpool2
Конфиги хранит в /etc/pgpool2/
pgpool.conf — Основные настройки (о них чуть ниже) pcp.conf — Системное — можно не трогать pool_hba.conf — Настройка доступов подключения. Можно юзать свой, можно — посгресовый. Лучше — постгресовый
Я использовала PgPool как пулер, распределитель нагрузки и, что самое главное, файловер.
Пример настройки /etc/pgpool2/pgpool.conf (частично) Для Мастера: listen_addresses = '*' port = 9999 socket_dir = '/var/run/postgresql' pcp_port = 9898 pcp_socket_dir = '/var/run/postgresql'
Так же в /etc/pgpool2/ создаются скрипты следующего содержания, указанные в конфиге:
''failover.sh'' — Собственно скрипт, отрабатывающий в случае падения мастера #!/bin/bash -x FALLING_NODE=$1 # %d OLDPRIMARY_NODE=$2 # %P NEW_PRIMARY=$3 # %H PGDATA=$4 # %R
if [ $FALLING_NODE = $OLDPRIMARY_NODE ]; then if [ $UID -eq 0 ] then su postgres -c "ssh -T postgres@$NEW_PRIMARY touch $PGDATA/trigger" else ssh -T postgres@$NEW_PRIMARY touch $PGDATA/trigger fi exit 0; fi; exit 0;
''recovery_1st_stage.sh'' — Скрипт с говорящим названием #!/bin/bash -x
Таким образом получаем Мастер-моноСлейв репликацию с распределением нагрузки и файловером.
Подключение идет всегда только к мастеру через порт pgPool'a (здесь — 9999). При нормальной работе идет запись в мастер, бэкэндово реплицируется на слейв, а чтение производится и с того и с другого. В случае отключения слейва, при возобновлении его работы все данные времени простоя автоматически дореплицируются. В случае отключения мастера, без разрыва пользовательского соединения pgpool перенаправляет чтение и запись полностью на реплику, временно делая ее «мастером». При поднятии мастера, он догоняет все данные со слейва и происходит обратное переключение, опять же без разрыва пользовательского соединения.
Есть определенная проблема в том, что не удалось как то создать управление правами, чтобы при живом мастере на слейв были бы права только RO, а при его падении переключались на RW (а потом при восстановлении — обратно), но поскольку внешнее обращение идет только к адресу Мастера, то опасность остается только в шаловливых ручках разработчиков.