Пошаговое руководство по настройке потоковой репликации PostgreSQL

Потоковая репликация является основополагающим механизмом для достижения высокой доступности (HA) и масштабирования чтения в средах PostgreSQL. Настраивая первичный (master) сервер для непрерывной передачи записей журнала упреждающей записи (WAL) на один или несколько резервных (replica) серверов, вы обеспечиваете синхронизацию данных с минимальной задержкой.

Это руководство проведет вас через асинхронную потоковую репликацию с использованием pg_basebackup, pg_hba.conf и файлов сигналов резервного сервера. В результате вы получите работающую пару первичный-резервный сервер и проверки, необходимые для подтверждения того, что репликация действительно происходит.

Предварительные требования и настройка среды

Перед началом убедитесь, что выполнены следующие предварительные требования. В этом руководстве предполагается наличие двух серверов, Primary и Standby, работающих под управлением одной и той же основной версии PostgreSQL (рекомендуется версия 12 или новее).

Сервер	Роль	IP-адрес (пример)
Primary	Источник данных	192.168.1.10
Standby	Реплика	192.168.1.11

• Пользователь: У вас должен быть административный доступ (например, sudo или системный пользователь postgres) на обоих серверах.
• Сеть: Резервный сервер должен иметь возможность подключиться к первичному серверу через порт PostgreSQL (по умолчанию 5432).

Шаг 1: Настройка первичного сервера

Первичный сервер должен быть настроен на генерацию и предоставление файлов WAL для репликации.

1.1 Изменение postgresql.conf

Отредактируйте основной файл конфигурации. В пакетах Debian и Ubuntu он часто находится в /etc/postgresql/<version>/main/postgresql.conf; во многих установках из исходных кодов или контейнеров он находится в каталоге данных. Установите следующие параметры:

# Разрешить подключения с других хостов
listen_addresses = '*'

# Установить уровень WAL в 'replica' или выше
wal_level = replica

# Максимальное количество одновременных подключений от резервных серверов
max_wal_senders = 5 

# Управляет количеством резервных подключений, которые могут быть активны одновременно
max_replication_slots = 5

# Разрешает запросы только для чтения на резервном сервере
hot_standby = on

1.2 Создание выделенного пользователя репликации

В целях безопасности создайте конкретного пользователя с атрибутом REPLICATION. Этот пользователь будет использоваться только резервным сервером для получения записей WAL.

# Подключиться к PostgreSQL
sudo -u postgres psql -c "CREATE ROLE replica_user WITH REPLICATION LOGIN PASSWORD 'use-a-real-secret-here';"

1.3 Обновление аутентификации клиентов (pg_hba.conf)

Разрешите пользователю репликации с IP-адреса резервного сервера подключаться к специальной псевдобазе данных replication.

# TYPE  DATABASE        USER            ADDRESS                 METHOD
host    replication     replica_user    192.168.1.11/32         md5

1.4 Перезапуск первичного сервера

Примените изменения конфигурации. Перезапуск — это простой вариант после изменения listen_addresses; если вы изменили только pg_hba.conf, достаточно перезагрузки.

sudo systemctl restart postgresql

Шаг 2: Подготовка резервного сервера

Перед клонированием данных убедитесь, что служба PostgreSQL на резервном сервере остановлена, а существующий каталог данных очищен.

2.1 Остановка службы PostgreSQL на резервном сервере

sudo systemctl stop postgresql

2.2 Очистка каталога данных

Предупреждение: Этот шаг навсегда удаляет все данные, находящиеся в настоящее время в каталоге данных резервного сервера. Подтвердите путь перед выполнением.

# Пример пути для PG 14
PG_DATA=/var/lib/postgresql/14/main

sudo rm -rf $PG_DATA/*

2.3 Клонирование данных с помощью pg_basebackup

Используйте pg_basebackup для создания точной копии каталога данных первичного сервера. Флаг -R имеет решающее значение, поскольку он автоматически генерирует необходимые файлы конфигурации (standby.signal и primary_conninfo), необходимые для потоковой репликации (PostgreSQL 12+).

Выполните эту команду на резервном сервере:

PG_DATA=/var/lib/postgresql/14/main

sudo -u postgres pg_basebackup -h 192.168.1.10 -D $PG_DATA -U replica_user -P -v -R

Опция	Описание
-h	Имя хоста/IP-адрес первичного сервера.
-D	Путь к локальному каталогу данных.
-U	Имя пользователя репликации (replica_user).
-P	Показывать прогресс.
-v	Подробный вывод.
-R	Автоматически создать файл конфигурации репликации.

Шаг 3: Настройка и запуск резервного сервера

3.1 Проверка конфигурации резервного сервера

Если вы использовали флаг -R на шаге 2.3, pg_basebackup создал файл standby.signal и заполнил настройку primary_conninfo, обычно в сгенерированном файле конфигурации с именем postgresql.auto.conf в каталоге данных.

Проверьте содержимое строки primary_conninfo. Она должна выглядеть примерно так (проверьте внутри $PG_DATA/postgresql.auto.conf):

primary_conninfo = 'host=192.168.1.10 user=replica_user password=SuperSecurePassword123 application_name=standby_node'

Совет: Убедитесь, что пароль включен в primary_conninfo или что вы используете аутентификацию на основе сертификатов. Если вы используете pg_hba.conf с trust или cert, пароль можно опустить.

3.2 Запуск службы резервного сервера

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

sudo systemctl start postgresql

Шаг 4: Проверка потоковой репликации

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

4.1 Проверка на первичном сервере

Подключитесь к первичному серверу и выполните запрос к представлению pg_stat_replication. Вы должны увидеть строку, представляющую подключение от резервного сервера.

psql -c "SELECT client_addr, state, sync_state, sent_lsn, write_lsn, flush_lsn FROM pg_stat_replication;"

Ожидаемый вывод (ключевые поля):

• client_addr: Должен соответствовать IP-адресу резервного сервера (например, 192.168.1.11).
• state: Должен быть streaming. Если отображается startup или catching up, подождите немного. Если отображается запуск walsender, вы близки к цели.
• sync_state: Должен быть async (для стандартной асинхронной репликации).

4.2 Тестирование синхронизации данных

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

На первичном сервере:

CREATE TABLE replication_test (id serial primary key, message text);
INSERT INTO replication_test (message) VALUES ('Data synchronized successfully');

На резервном сервере (только для чтения):

-- Это должно выполниться без ошибок
psql -c "SELECT * FROM replication_test;"

Если данные видны на резервном сервере, потоковая репликация успешно настроена и активна.

Лучшие практики и устранение неполадок

Постоянное соединение: слоты репликации

Хотя это и необязательно, слоты репликации настоятельно рекомендуются. Слот репликации гарантирует, что первичный сервер не удалит преждевременно сегменты WAL, необходимые резервному серверу, даже если резервный сервер временно отключится.

На первичном сервере:

SELECT * FROM pg_create_physical_replication_slot('standby_slot_name');

Затем установите primary_slot_name на резервном сервере. Не помещайте имя слота внутрь primary_conninfo.

primary_conninfo = 'host=192.168.1.10 user=replica_user password=use-a-real-secret-here application_name=standby_node'
primary_slot_name = 'standby_slot_name'

Предупреждение: Слоты репликации требуют тщательного мониторинга. Если резервный сервер выйдет из строя на длительный период, накопленные файлы WAL, защищенные слотом, могут быстро заполнить дисковое пространство первичного сервера.

Устранение распространенных проблем

Проблема	Возможная причина	Решение
Резервный сервер не может подключиться	Сетевой брандмауэр, неправильный listen_addresses или неверный pg_hba.conf на первичном сервере.	Проверьте доступность порта 5432; убедитесь, что pg_hba.conf соответствует IP-адресу и пользователю резервного сервера.
pg_basebackup завершается ошибкой аутентификации	Неверный пароль или отсутствующая запись хоста в pg_hba.conf.	Перепроверьте пароль для replica_user; убедитесь, что первичная база данных перезапущена после изменения pg_hba.conf.
Резервный сервер только для чтения	Это ожидаемое поведение.	Наличие standby.signal переводит сервер в режим восстановления.

Следующий шаг

Настройка потоковой репликации является критическим шагом в создании отказоустойчивой архитектуры PostgreSQL. Выполнив эти шаги, вы успешно настроили пару первичный-резервный сервер, которая обеспечивает непрерывную синхронизацию данных, значительно повышая возможности высокой доступности вашей системы. Следующим логическим шагом является интеграция решения для мониторинга и механизма отработки отказа (например, Patroni или Repmgr) для полной автоматизации настройки HA.