Репликация баз данных PostgreSQL по типу Master/Slave

Ubuntu | Amber | 1 Comment

PostgreSQL, или postgres – это популярная система управления базами данных (СУБД), предназначенная для  систематизации и управления данными сайта или приложения. Репликация – это метод обеспечения высокой доступности и отказоустойчивости БД путём копирования информации из базы данных на вторую систему.

Существует множество способов настройки репликации в PostgreSQL. Данное руководство продемонстрирует репликацию путём горячего резервирования, преимущество которой состоит в относительно простой настройке.

Для этого понадобится два виртуальных выделенных сервера Ubuntu 12.04. Один из них будет ведущим сервером (master), а второй – ведомым (slave), который и будет выполнять репликацию БД главного сервера.

Установка PostgreSQL

Примечание: Инструкции этого раздела нужно выполнить на двух серверах.

СУБД PostgreSQL доступна в стандартных репозиториях Ubuntu. Чтобы установить необходимые пакеты, запустите команду:

sudo apt-get update
sudo apt-get install postgresql postgresql-contrib postgresql-client

Для управления исходными базами данных PostgreSQL создаёт пользователя по имени postgres. Чтобы упростить обмен файлами между серверами, настройте их взаимодействие по ssh.

Также нужно установить пароль для пользователя postgres. После передачи файлов пароль можно будет удалить.

sudo passwd postgres

Переключитесь в сеанс пользователя postgres:

sudo su - postgres

Создайте ssh-ключ для этого пользователя.

ssh-keygen

На все появившиеся подсказки нажмите Enter.

Передайте ключ на другой сервер:

ssh-copy-id IP_адрес_другого_сервера

Теперь серверы могут легко взаимодействовать по ssh как пользователь postgres.

Настройка ведущего сервера

Сначала нужно настроить ведущий сервер, или сервер master.

Примечание: Все перечисленные ниже команды нужно выполнять как пользователь postgres.

Сначала создайте нового пользователя по имени rep, специально предназначенного для репликации.

psql -c "CREATE USER rep REPLICATION LOGIN CONNECTION LIMIT 1 ENCRYPTED PASSWORD 'пароль';"

Примечание: Не забудьте указать надёжный пароль.

Откройте каталог конфигураций postgres:

cd /etc/postgresql/9.1/main

Отредактируйте следующий файл, указав в нём нового пользователя:

nano pg_hba.conf

В любой точке файла (только не в конце) поместите следующие строки, которые откроют новому пользователю доступ к этому серверу:

host    replication     rep     IP_адрес_slave_сервера/32   md5

Сохраните и закройте файл.

Затем нужно открыть главный конфигурационный файл postgres:

nano postgresql.conf

Найдите в нём следующие параметры, раскомментируйте их и измените их значения таким образом:

listen_addresses = 'localhost,IP_адрес_ТЕКУЩЕГО_хоста'
wal_level = 'hot_standby'
archive_mode = on
archive_command = 'cd .'
max_wal_senders = 1
hot_standby = on

Сохраните и закройте файл.

Перезапустите master сервер, чтобы обновить настройки.

service postgresql restart

Настройка ведомого сервера

Для начала отключите на ведомом сервере (или slave) программу postgresql:

service postgresql stop

Теперь нужно отредактировать файлы postgresql. Откройте каталог настроек:

cd /etc/postgresql/9.1/main

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

nano pg_hba.conf

Добавьте в файл следующую строку (опять же, только не в конец файла):

host    replication     rep     IP_адрес_master_сервера/32  md5

Сохраните и закройте файл.

Откройте конфигурации postgresql:

nano postgresql.conf

Можно использовать те же опции, что и на master сервере, изменив только IP-адрес.

listen_addresses = 'localhost,IP_адрес_ТЕКУЩЕГО_хоста'
wal_level = 'hot_standby'
archive_mode = on
archive_command = 'cd .'
max_wal_senders = 1
hot_standby = on

Сохраните и закройте файл.

Репликация начальной базы данных

Прежде чем сервер slave начнёт выполнять репликацию сервера master, на сервере slave нужно подготовить БД, поскольку он читает данные ведущего сервера и вносит изменения в собственную БД. эта БД должна соответствовать базе данных ведущего сервера.

На сервере master можно использовать  команду запуска резервного копирования Postgres, чтобы создать backup label. Затем нужно будет передать данные сервера master на сервер slave и использовать внутреннюю команду backup stop.

psql -c "select pg_start_backup('initial_backup');"
rsync -cva --inplace --exclude=*pg_xlog* /var/lib/postgresql/9.1/main/ slave_IP_address:/var/lib/postgresql/9.1/main/
psql -c "select pg_stop_backup();"

Команда rsync может выдать ошибку при изменении файлов сертификата, но это поведение можно считать нормальным.

Теперь нужно подготовить файл для восстановления данных на сервере slave. Откройте каталог:

cd /var/lib/postgresql/9.1/main

Создайте в нём файл по имени recovery.conf:

nano recovery.conf

Внесите в файл следующий код, указав IP-адрес ведущего сервера и пароль пользователя rep:

standby_mode = 'on'
primary_conninfo = 'host=IP_адрес_master_сервера port=5432 user=rep password=пароль_rep'
trigger_file = '/tmp/postgresql.trigger.5432'

Строка trigger_file – одна из самых важных в настройке. Если создать файл в этой точке на машине slave, сервер slave выполнит перенастройку и будет функционировать как master.

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

Итак, теперь slave сервер готов к работе. Введите:

service postgresql start

Проверьте логи, чтобы убедиться, что всё работает без ошибок. На всех серверах они находятся здесь:

less /var/log/postgresql/postgresql-9.1-main.log

Тестирование репликации

Теперь нужно убедиться, что репликация данных выполняется без ошибок. Внесите изменения на сервер master и проверьте их на slave.

На ведущем сервере запустите PostgreSQL как пользователь postgres.

psql

Командная строка изменится, сообщая, что на данный момент вы работаете в строке БД PostgreSQL.

Создайте тестовую таблицу:

CREATE TABLE rep_test (test varchar(40));

Внесите в таблицу следующие условные данные:

INSERT INTO rep_test VALUES ('data one');
INSERT INTO rep_test VALUES ('some more words');
INSERT INTO rep_test VALUES ('lalala');
INSERT INTO rep_test VALUES ('hello there');
INSERT INTO rep_test VALUES ('blahblah');

Закройте интерфейс БД:

\q

Теперь вернитесь на сервер slave и откройте интерфейс БД:

psql

Посмотрите, появились ли добавленные данные в БД этого сервера:

SELECT * FROM rep_test;
test
-----------------
data one
some more words
lalala
hello there
blahblah
(5 rows)

Как видите, данные были записаны в обе БД.

Теперь попробуйте добавить данные в БД slave:

INSERT INTO rep_test VALUES ('oops');
ERROR:  cannot execute INSERT in a read-only transaction

Как видите, добавить данные на сервер slave невозможно, поскольку данные здесь могут передаваться только в одном направлении.

Заключение

Итак, теперь у вас есть ведущий и ведомый серверы, правильно настроенные и успешно взаимодействующие.

Если приложение вносит данные и создаёт запросы к базам данных, можно настроить балансировку нагрузки, чтобы приложение вносило все данные на сервер master и могло читать их на двух серверах. Это позволяет увеличить производительность баз данных.