Репликация слота не работает в Postgres 9.4.

Вопрос или проблема

Я использую Postgres 9.4 на сервере Windows 2008. У меня есть три таких экземпляра. Один в качестве мастера, а остальные два — slave/standby. Версия Postgres 9.4 во всех трех экземплярах. Я настроил репликацию с использованием физического слота. Но репликация не работает. При выполнении запроса SELECT * from pg_stat_replication; возвращается 0 строк, а при SELECT * from pg_replication_slots; слот показывает, что он не активен (‘f’ в столбце ‘active’).

У меня следующая конфигурация:

На Primary/Master:

wal_level = hot_standby
max_wal_senders = 2
max_replication_slots = 2
hot_standby = on

На Secondary/Standby:

wal_level = hot_standby
hot_standby = on

Файл recovery.conf на secondary/standby:

standby_mode = on
primary_conninfo = ‘host=192.168.8.192 port=5432
user=postgres password=123456’
primary_slot_name=”testing”
recovery_min_apply_delay = 1min

Что может быть упущено? Я подготовил резервные серверы с помощью резервной копии данных Master. Спасибо.

У меня была подобная проблема на Ubuntu. Оказалось, что recovery.conf находился не в том месте.

Согласно Wiki Postgres на Потоковая репликация в разделе, описывающем recovery.conf:

$EDITOR recovery.conf

Обратите внимание, что recovery.conf должен находиться в каталоге $PGDATA.

Он не должен находиться в том же каталоге, что и postgresql.conf

Как только я переместил recovery.conf в правильное место и перезапустил Postgres, SELECT * from pg_stat_replication вернул active = true.

Надеюсь, это поможет.

Ответ или решение

Причины, по которым слоты репликации могут не работать в PostgreSQL 9.4, могут быть разнообразными. Рассмотрим ваше описание проблемы и попробуем разобраться, что могло пойти не так.

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

Пример: В вашем случае настройка репликации выглядит следующим образом:

На мастере установлены следующие параметры:
- wal_level = hot_standby: обеспечивает сохранение дополнительных данных для реплик, которые могут быть использованы для восстановления и чтения.
- max_wal_senders = 2 и max_replication_slots = 2: соответственно ограничивают количество программ-отправителей WAL и активных слотов репликации.
- hot_standby = on: позволяет выполнять запросы к реплике во время ожидания.
На стендаях в конфигурационном файле recovery.conf задаются критически важные параметры, такие как standby_mode = on, primary_conninfo, содержащий данные для подключения к мастеру, и primary_slot_name, указывающий на имя использующегося слота.

Применение: Рассмотрим некоторые моменты, которые могут быть причиной возникновения у вас проблем:

Местоположение recovery.conf: Убедитесь, что файл recovery.conf действительно находится в директории $PGDATA на всех стендая. Как указано в вашем тексте, часто ошибка заключается в том, что файл расположен неверно, из-за чего PostgreSQL не видит настройку стендая.
Логины и пароли: Проверьте вашу строку подключения в primary_conninfo. Ошибки в логине или пароле приведут к невозможности подключения стендая к мастеру, что вызовет неактивность слота репликации.
Сетевые настройки: Удостоверьтесь, что ваше сетевое окружение (включая файрволы и маршрутизаторы) позволяет открытую связь между сервером мастера и стендаем. Возможно, проблемой является заблокированный порт или IP-адрес.
Логи PostgreSQL: Исследуйте лог-файлы PostgreSQL на стендая и мастера на наличие предупреждений или ошибок. Это может дать более детальные подсказки о возникшей проблеме.
Проверка настроек на стендаях: Перепроверьте, что в postgresql.conf на стендаях также включен параметр hot_standby = on, чтобы обеспечить возможность чтения данных во время процесса репликации.
Обновления и поддержка: В силу того, что PostgreSQL 9.4 является довольно старой версией, некоторые особенности репликации могли быть улучшены в более новых релизах. Рассмотрите возможность обновления, если это соответствует вашим требованиям и политике IT инфраструктуры.
Инициализация реплики: Убедитесь, что инициализация стендая была выполнена корректно, включая создание базы данных из последней версии контрольной точки мастера.

Как только вы получите активное соединение, запрос SELECT * from pg_stat_replication; начнет возвращать строки, показывающие статус активных подключений реплик. Надеюсь, эти советы помогут вам выявить и устранить проблему с репликацией в вашей установке PostgreSQL.