Также с версии 9.1 добавили view pg_stat_database_conflicts, с помощью которой на слейв базах можно просмотреть сколько запросов было отменено и по каким причинам:
# SELECT * from pg_stat_database_conflicts ; datid | datname | confl_tablespace | confl_lock | confl_snapshot | confl_bufferpin | confl_deadlock -------+-----------+------------------+------------+----------------+-----------------+---------------- 1 | template1 | 0 | 0 | 0 | 0 | 0 11979 | template0 | 0 | 0 | 0 | 0 | 0 11987 | postgres | 0 | 0 | 0 | 0 | 0 16384 | marc | 0 | 0 | 1 | 0 | 0
Еще проверить работу репликации можно с помощью утилиты ps:
$ ps -ef | grep sender postgres 6879 6831 0 10:31 ? 00:00:00 postgres: wal sender process postgres 127.0.0.1(44663) streaming 0/2000000 [slavedb] $ ps -ef | grep receiver postgres 6878 6872 1 10:31 ? 00:00:01 postgres: wal receiver process streaming 0/2000000
Теперь проверим реприкацию. Выполним на мастере:
$ psql test_db test_db=# create table test3(id int not null primary key,name varchar(20)); NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "test3_pkey" for table "test3" CREATE TABLE test_db=# insert into test3(id, name) values('1', 'test1'); INSERT 0 1 test_db=#
Теперь проверим на слейве:
$ psql test_db test_db=# select * from test3; id | name ----+------- 1 | test1 (1 row)
Как видим, таблица с данными успешно скопирована с мастера на слейв.
Общие задачи
Переключение на слейв при падении мастера
Достаточно создать триггер-файл (trigger_file) на слейве, который становится мастером.
Остановка репликации на слейве
Создать триггер-файл (trigger_file) на слейве. Также с версии 9.1 добавили команды pg_xlog_replay_pause() и pg_xlog_replay_resume() для остановки и возобновления репликации.
Перезапуск репликации после сбоя
Повторяем операции из раздела «Настройка слейва». Хочется заметить, что мастер при этом не нуждается в остановке при выполнении данной задачи.
Перезапуск репликации после сбоя слейва
Перезагрузить PostgreSQL на слейве после устранения сбоя.
Повторно синхронизировать репликации на слейве
Это может потребоваться, например, после длительного отключения от мастера. Для этого останавливаем PostgreSQL на слейве и повторяем операции из раздела «».
PostgreSQL Bi-Directional Replication (BDR)
BDR (Bi-Directional Replication) это новая функциональность добавленая в ядро PostgreSQL которая предоставляет расширенные средства для репликации.
имя кластера.
Подготовка master базы
Для начала нам нужно создать пользователя в базе, под которым будет действовать Slony. По умолчанию, и отдавая должное системе, этого пользователя обычно называют slony.
$ createuser -a -d slony $ psql -d template1 -c "ALTER USER slony WITH PASSWORD 'slony_user_password';"
Также на каждом из узлов лучше завести системного пользователя slony, чтобы запускать от его имени репликационного демона slon. В дальнейшем подразумевается, что он (и пользователь и slon) есть на каждом из узлов кластера.
Подготовка slave базы
Здесь я рассматриваю, что серверы кластера соединены посредством сети. Необходимо чтобы с каждого из серверов можно было установить соединение с PostgreSQL на master хосте, и наоборот. То есть, команда:
anyuser@customers_slave$ psql -d customers \ -h customers_master.com -U slony
должна подключать нас к мастер-серверу (после ввода пароля, желательно). Если что-то не так, возможно требуется поковыряться в настройках firewall-a, или файле pg_hba.conf, который лежит в $PGDATA.
Теперь устанавливаем на slave-хост сервер PostgreSQL. Следующего обычно не требуется, сразу после установки Postgres «up and ready», но в случае каких-то ошибок можно начать «с чистого листа», выполнив следующие команды (предварительно сохранив конфигурационные файлы и остановив postmaster):
pgsql@customers_slave$ rm -rf $PGDATA pgsql@customers_slave$ mkdir $PGDATA pgsql@customers_slave$ initdb -E UTF8 -D $PGDATA pgsql@customers_slave$ createuser -a -d slony pgsql@customers_slave$ psql -d template1 -c "alter \ user slony with password 'slony_user_password';"
Запускаем postmaster.
Внимание! Обычно требуется определённый владелец для реплицируемой БД. В этом случае необходимо создать его тоже!
pgsql@customers_slave$ createuser -a -d customers_owner pgsql@customers_slave$ psql -d template1 -c "alter \ user customers_owner with password 'customers_owner_password';"
Эти две команды можно запускать с customers_master, к командной строке в этом случае нужно добавить -h customers_slave, чтобы все операции выполнялись на slave.
На slave, как и на master, также нужно установить Slony.
Инициализация БД и plpgsql на slave
Следующие команды выполняются от пользователя slony. Скорее всего для выполнения каждой из них потребуется ввести пароль (slony_user_password). Итак:
slony@customers_master$ createdb -O customers_owner \ -h customers_slave.com customers slony@customers_master$ createlang -d customers \ -h customers_slave.com plpgsql
Внимание! Все таблицы, которые будут добавлены в replication set должны иметь primary key. Если какая-то из таблиц не удовлетворяет этому условию, задержитесь на этом шаге и дайте каждой таблице primary key командой ALTER TABLE ADD PRIMARY KEY.