В данном разделе будет рассмотрен вариант ручного переключения на резервный сервер PostgreSQL, например, силами администраторов. Вероятно, самой сложной частью здесь является создание единой точки входа со стороны клиентских приложений,  чтобы «1С:Предприятие» могло без перенастройки подключаться к текущему мастеру. Для этих целей можно использовать такие инструменты как PgBouncer и HAProxy, которые будут рассмотрены далее. 

Кроме того, возможно использовать расширенный формат подключения библиотеки libpq, которая позволяет перечислить в строке подключения к СУБД все узлы кластера и указать требования к серверу, например, ограничить выбор только серверами, которые могут принимать пишущие транзакции (параметр target_session_attrs=read-write). Формат строки подключения в 1С:

host1, host2, host3 port=5432 target_session_attrs=read-write

В этом случае «1С:Предприятие» будет пытаться подключиться к серверам, которые поддерживают режим чтения/записи, т.е. не являются репликами в порядке их перечисления в строке подключения. Первый доступный узел становится выбранным для подключения, остальные узлы уже не рассматриваются.

Здесь сразу хочется отметить, что такой способ потенциально может привести к разделению кластера Split Brain (запись части данных на один сервер, части на другой), если по каким-либо причинам несколько хостов, перечисленных в строке подключения, станут мастерами. Поэтому безопаснее использовать промежуточное звено в виде PgBouncer или HAProxy.

Подготовка кластера PostgreSQL

• Для разворачивания реплики на резервном сервере используется стандартная утилита pg_basebackup с параметрами -R, --slot=<имя слота> и --create-slot для инициализации режима физической репликации после создания резервной копии.
• Определить статус сервера: мастер/реплика можно по наличию файла standby.signal в каталоге PGDATA или командой PSQL select pg_is_in_recovery().
• Переключение на реплику выполняется утилитой pg_ctl promote или командой PSQL select pg_promote().

Далее необходимо настроить параметры в файле postgresql.conf, влияющие на репликацию:

• при использовании синхронной репликации на ведущем сервере нужно задать параметр synchronous_commit = on и указать список ведомых серверов в параметре synchronous_standby_names;
• для подключения к ведущему серверу на реплике указать строку подключения в параметре primary_conninfo;
• на реплике указать имя слота репликации в параметре primary_slot_name, который будет использоваться для подключения к ведущему серверу по протоколу потоковой репликации; 
• на реплике установить max_standby_streaming_delay в небольшое значение, чтобы не откладывать применение журнальных записей и применять их сразу. Конфликтующие запросы к реплике в этом случае будут прерваны с ошибкой, например, если реплики задействованы через механизм копий баз данных 1С; 
• на реплике выключить hot_standby_feedback = off,  чтобы запросы к ней не могли негативно влиять на основной сервер;
• если запросы к реплике не предполагаются, то можно отключить возможность их выполнения на реплике hot_standby = off;
•  max_wal_senders - максимально допустимое число одновременных подключений ведомых серверов. Для реплики значение этого параметра должно быть больше или равно значению на мастере. В противном случае на реплике не будут разрешены запросы;
• wal_keep_size - минимальный объём прошлых файлов WAL, который будет сохраняться в каталоге журнала транзакций, чтобы реплика могла их выбрать при потоковой репликации. Рекомендуется указывать на мастере и реплике для того, чтобы сохранить объем файлов WAL при переключении на новый мастер на время перенастройки репликации, иначе придется создавать реплику с нуля;
• max_slot_wal_keep_size - максимальный размер файлов WAL, который может оставаться в каталоге журнальных записей для слотов репликации после выполнения контрольной точки. Рекомендуется задать какое-то ограничение для того, чтобы файлы WAL не заняли все свободное пространство на диске при неработающем слоте репликации, который будет препятствовать их удалению.

Отказоустойчивый кластер основан на механизме физической репликации, которая реализована стандартными средствами Postgres, и в рамках текущей статьи ее подробная настройка не рассматривается, прежде всего, из-за объема информации.

Ссылка на документацию:

https://postgrespro.ru/docs/postgresql/16/warm-standby#STREAMING-REPLICATION

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

Схема настройки подключения через PgBouncer

Одним из способов организации единой точки входа из 1С может являться PgBouncer (рис. 1). При такой реализации сервер 1С подключается не к конкретному серверу Postgres, а к PgBouncer через порт 6432, который установлен на том же самом хосте. 

Для подключения к PgBouncer со стороны 1С необходимо указать параметры listen_addr, listen_port, auth_type, auth_file и auth_hba_file (если параметр auth_type = hba).

Для возможности административного подключения к PgBouncer также необходимо указать параметр admin_users.

Настройки подключения к серверам СУБД определяются в файле pgbouncer.ini в разделе [databases], в этом разделе определяются имена баз данных, к которым могут подключаться клиенты PgBouncer и указывает куда будут перенаправляться эти подключения.

 

Важно установить значение pool_size для строки подключения, например, 200, т.к. иначе оно равно значению параметра default_pool_size = 20 (по умолчанию) и соответственно при таких настройках нельзя запустить более 20 одновременных сеансов на стороне СУБД.

Изменение параметров сервера в конфигурационном фале при изменении роли мастер/реплика для узлов кластера можно выполнять вручную или с помощью скрипта, заменяя строку параметров подключения в разделе [databases], например, с помощью регулярных выражений.

Кроме того, есть полезная возможность по управлению пулом соединений через административную консоль (для пользователей, указанных в параметре admin_users). Например, это позволяет выполнить плановое переключение на резервный сервер, поставив текущие соединения с СУБД на паузу, так что пользователи почувствуют только временное зависание системы, но никаких ошибок при этом не будет (если не было активной транзакции).  

Рис. 1 Отказоустойчивый кластер (использование PgBouncer)

Схема настройки подключения через HAProxy

Другим вариантом может быть использование HAProxy (рис. 2), для которого возможно настроить автоматическое переключение на текущий мастер (вызов проверочного скрипта из внешней команды конфигурационного файла haproxy.cfg). 

  

В отличие от использования PgBouncer (рис. 1), здесь нет необходимости изменять файл конфигурации и потом перечитывать настройки, HAProxy будет периодически выполнять проверочный скрипт (pgcheck.sh), передавая в скрипт параметры подключения к серверу, и таким образом перенаправлять клиентские подключения только на те сервера, которые проходят проверку скриптом (являются мастером).  

Но здесь есть один важный момент: во избежание Split Brain (разделения данных в кластере) доступным для подключения должен быть только один мастер, поэтому скрипт в случае доступности нескольких серверов должен это учитывать, например, делать недоступными для подключения оба мастера. 

 

Рис. 2 Отказоустойчивый кластер (использование HAProxy)

Каждый из инструментов для создания единой точки входа успешно справляется с поставленной задачей, но есть нюансы, особенно при использовании HAProxy. 

Основным преимуществом PgBouncer является возможность поставить текущие клиентские соединения на паузу, при плановом переключении, т. е. пользователи не получат ошибки о недоступности сервера на время пока осуществляется переход на новый сервер.

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