Потоковая репликация (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. Различний, конечно, очень много. Как и нюансов работы, но принцип тот же — передача записей лога транзакций на реплики.
Другая информация по PostgreSQL может быть найдена в этом репозитории.
