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

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

Это подробное руководство проведет вас через основные шаги, необходимые для установления надежной асинхронной потоковой репликации. Мы рассмотрим необходимые изменения конфигурации как на основном, так и на резервном серверах, используя современные возможности PostgreSQL, такие как pg_basebackup и сигнальные файлы для упрощения настройки. Следуя этому руководству, вы получите надежную основу для стабильной работы PostgreSQL.

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

Перед началом убедитесь, что выполнены следующие предварительные требования. Данное руководство предполагает наличие двух серверов: 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

Отредактируйте основной файл конфигурации, обычно расположенный в каталоге данных (например, /etc/postgresql/14/main/postgresql.conf), и установите следующие параметры:

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

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

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

# Контролирует количество одновременно активных подключений резервных копий
max_replication_slots = 5

# Требуется для запросов только для чтения на резервной копии (Hot Standby)
hot_standby = on

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

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

# Подключение к PostgreSQL
psql -c "CREATE USER replica_user REPLICATION ENCRYPTED PASSWORD 'SuperSecurePassword123';"

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

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

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

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

Примените изменения, перезапустив службу PostgreSQL:

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) присутствует в каталоге данных, служба запустится в режиме чтения-записи (read-only standby) и немедленно попытается подключиться к основному серверу.

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 startup, вы почти у цели.
• 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_conninfo на резервном сервере, чтобы использовать этот слот:

primary_conninfo = 'host=192.168.1.10 user=replica_user ... application_name=standby_node **slotname=standby_slot_name**'

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

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

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

Заключение

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