Потоковая репликация PostgreSQL

2022-03-25

#PostgreSQL

#репликация

#потоковая репликация

#масштабирование

Общая информация

Потоковая репликация (Streaming Replication) - это репликация, при которой от основного сервера PostgreSQL на реплики передается WAL (Write Ahead Log). И каждая реплика затем по этому журналу изменяет свои данные. Для настройки такой репликации все серверы должны быть одной версии, работать на одной ОС и архитектуре.

Шаги настройки:

Настройка master-сервера
Настройка доп. сервера (slave)
Тестирование репликации

Все действия в инструкции выполняются на PostgreSQL 14 и Ubuntu 20.04, но в целом инструкция актуальная для предыдущих (и возможно будущих) версий. Есть некоторые отличия версия PostgreSQL до 12 версии, о них смотрите в документации.

В нашем примере у нас будут два сервера:

Основной (master) с адресом 192.168.233.140
Дополнительный (slave) с адресом 192.168.233.141

Поехали!

Настройка master-сервера

Первым делом открываем “postgresql.conf” и изменяем в нем параметры.

# Определяет как много информации записывать в WAL. 
# Со значением replica в журнал записываются данные для поддержки архивирования WAL и репликации.
# В т.ч. для запросов только на чтение.
# wal_level = hot_standby - для версий до 9.6
# https://www.postgresql.org/docs/9.6/runtime-config-wal.html
wal_level = replica

# Число одновременных подключений для резервных серверов. Жалательно установить на 1 подключение
# больше, чем фактическое количество резервных серверов, т.к. в случае неожиданного отключения
# старое соединение будет некоторое время использоваться.
# https://www.postgresql.org/docs/9.4/runtime-config-replication.html
max_wal_senders = 10

# Задает минимальный размер в мегабайтах сегментов файлов журнала, хранящихся в каталоге pg_wal, на случай,
# если резервному серверу потребуется извлечь их для потоковой репликации.
# В ранних версиях параметр назывался wal_keep_segments и указывал количество файлов, а не их размер.
# https://www.postgresql.org/docs/13/runtime-config-replication.html
wal_keep_size = 1024

Создадим пользователя replication, чтобы через него дополнительный сервер мог подключаться к основному.

sudo -u postgres psql

CREATE ROLE replication WITH REPLICATION PASSWORD '<superpassrowd>' LOGIN;

В файле pg_hba.conf разрешаем подключение этому пользователю.

# TYPE  DATABASE        USER            ADDRESS                 METHOD
host    replication     replication     192.168.233.0/24         md5

И перезапускаем PostgreSQL.

systemctl restart postgresql

Настройка доп. сервера (slave)

Останавливаем PostgreSQL.

systemctl stop postgresql

Очищаем всё, что внутри data_directory, т.к. мы скопируем эти файлы с основного сервера.

rm -Rf /var/lib/pgsql/data/*

Копируем текущее состояние с основного сервера на дополнительный.

# В предыдущих версиях параметр wal-method=stream назывался xlog-method=stream,
# поэтому смотрите документацию для вашей версии PostgreSQL.
su postgres -c "pg_basebackup -h 192.168.233.140 -D /var/lib/pgsql/data -P -U replication --wal-method=stream"

Далее вносим изменения в файл postgresql.conf.

# Создает возможность выполнять запросы в момент восстановления транзакций.
# https://www.postgresql.org/docs/9.0/hot-standby.html
hot_standby = on

# Строка подключения к основному серверу
# https://www.postgresql.org/docs/12/runtime-config-replication.html
primary_conninfo = 'user=replication password=<superpassrowd> host=192.168.233.140 port=5432 sslmode=prefer sslcompression=1 krbsrvname=postgres'

Чтобы репликация заработала, также в каталоге с данными (обычно где файл конфигурации сервера) нужно создать файл standby.signal.

touch standby.signal
chown postgres:postgres standby.signal

Теперь все готово для запуска службы!

systemctl start postgresql

Профит!

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

Создадим на основном сервере базу AmazingReplication, а в ней таблицу “TestReplication”.

CREATE TABLE "TestReplication" ("SomveValue" varchar(100));
INSERT INTO "TestReplication" VALUES ('test 1');
INSERT INTO "TestReplication" VALUES ('test 2');
INSERT INTO "TestReplication" VALUES ('test 3');

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

select
    *
from "TestReplication"

В результате мы должны получить три записи, которые мы добавили выше. Если так - то дело сделано. А если нет, то Вам путь в логи сервера PostgreSQL для поиска проблем.

Вместо заключения

PostgreSQL имеет множество механизмов репликации данных, которые позволяют организовать горизонтальное масштабирование, повысить уровень отказоустойчивости и так далее. Мы рассмотрели простую настройку потоковой репликации, которая чем-то похожа на механизм групп высокой доступности AlwaysOn в SQL Server. Различний, конечно, очень много. Как и нюансов работы, но принцип тот же - передача записей лога транзакций на реплики.