Как разрешить репликеудаленное подключение кmaster-серверу PostgreSQL

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

Почему реплика не подключается

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

Причина обычно в правилах клиентской аутентификации: по умолчанию PostgreSQL не разрешает удаленные подключения, если они не прописаны в конфигурации.

Что нужно изменить на master-сервере

Для разрешения подключения используется файл pg_hba.conf. Именно в нем задаются правила доступа для клиентов, в том числе для репликации.

В примере рассматривается PostgreSQL 17. Путь к файлу в таком случае указан как:

/etc/postgresql/17/main/pg_hba.conf

Если точное расположение файла неизвестно, его можно узнать из самой СУБД командой:

sudo -u postgres psql -c "SHOW hba_file;"

Пример правила для реплики

В конфигурацию нужно добавить строку, которая разрешает подключение пользователю replicator с IP-адреса ведомого сервера:

host replication replicator REPLICA_ВНУТРЕННИЙ_IP/32 scram-sha-256

После этого у роли replicator должна быть включена привилегия репликации:

ALTER ROLE replicator WITH REPLICATION;

Для подключения используется механизм scram-sha-256.

Как применить изменения

После редактирования pg_hba.conf PostgreSQL нужно перечитать конфигурацию авторизации. В материале указаны несколько способов:

systemctl reload postgresql

или

pg_ctl reload

Также можно отправить сигнал HUP процессу postmaster либо вызвать SQL-функцию pg_reload_conf().

Что это означает для администраторов и владельцев сайтов

Для системного администратора такая настройка — базовый шаг при запуске репликации и подготовке отказоустойчивого контура. Без правильного правила в pg_hba.conf ведомый сервер не сможет начать синхронизацию.

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

Но сама по себе запись в конфигурации не решает все задачи production-среды. В материале отдельно отмечается, что при эксплуатации кластера нужно учитывать WAL-журналы, задержку между репликами, сетевую доступность узлов, резервное копирование и проверку сценариев аварийного переключения.

Когда стоит пересматривать подход к эксплуатации

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

Вне зависимости от выбранной схемы, доступы для репликации стоит настраивать аккуратно: ограничивать их конкретным IP-адресом, проверять привилегии роли и не забывать о порядке правил в pg_hba.conf.