Меня зовут Алексей Васильев, я сертифицированный эксперт по PostgreSQL и технический эксперт компании «1С-Премиум». Это мой первый гостевой пост в блоге компании Postgres Professional. По итогам взаимодействия компаний «1С-Премиум» и Postgres Professional, коллеги предложили рассказать о настройке отказоустойчивого кластера СУБД Postgres Pro для систем на базе «1С:Предприятие». Так родилась эта статья. Также хотел бы пригласить читателей ознакомиться с другими статьями на сайте нашей компании, где я планирую опубликовать цикл статей с подробными описаниями различных сценариев использования «1С:Предприятие» в связке с PostgreSQL.
Введение
Целью данной статьи является описание возможных способов построения отказоустойчивого кластера на Postgres Pro Enterprise для систем на базе «1С:Предприятие» по аналогии с группами доступности Always On для MS SQL Server.
Реализация отказоустойчивости на PostgreSQL является нетривиальной задачей, так как. в стандартной поставке он не предоставляет возможностей для автоматического переключения на резервный сервер и создания единой точки входа со стороны клиентских приложений.
Статья ориентирована в первую очередь на технических специалистов, которые будут осуществлять настройку и разворачивание отказоустойчивого кластера, но также может быть полезна для принятия решения о том, какие инструменты оптимальнее использовать для реализации отказоустойчивости в зависимости от потребностей бизнеса.
Определение потребностей и ценности для бизнеса
Для того чтобы правильно выбрать решение по отказоустойчивости, важно определить потребности бизнеса, в первую очередь технические требования к системе, а также определить решение каких задач имеет ценность:
требования к доступности системы (допустимое время простоя, размер технологических окон);
требования к допустимой потере данных при отказе основного сервера;
необходимость планового переключения на резервный сервер, например для апгрейда оборудования;
уменьшение риска потери данных за счёт дополнительного резервирования;
возможность отката изменений на произвольный момент времени при использовании реплики с отставанием;
снижение нагрузки на основной сервер за счёт переноса части административных задач и запросов на резервный сервер (резервное копирование, использование механизма 1С для создания копий баз данных).
Ответы на пункты из списка выше, в сочетании с анализом критериев выбора, описанных далее, позволят выбрать более подходящий вариант решения по отказоустойчивости с точки зрения затрат и ценности для бизнеса.
Имеются два варианта переключения на резервный сервер — ручное и автоматическое, основные критерии выбора приведены ниже.
Критерии для выбора решения с ручным переключением на резервный сервер
Возможно наличие только одного резервного сервера (экономия на ресурсах).
Не критично влияние человеческого фактора на время переключения.
Допустимое время простоя является достаточно длительным (сеанс пользователя может быть аварийно завершён, и пользователь не сможет быстро зайти в базу повторно).
Режим работы системы совпадает с графиком работы администраторов, сопровождающих СУБД.
Более простая настройка и администрирование, требуется знание только типового механизма репликации Postgres (меньше требований к квалификации администраторов СУБД).
Критерии для выбора решения с автоматическим переключением на резервный сервер
Время простоя в случае сбоя основного сервера должно быть минимальным, оптимально если переключение на резервный сервер будет происходить без аварийного завершения сеансов пользователей (если нет активной транзакции), либо пользователь сможет быстро зайти в базу повторно.
Нет влияния человеческого фактора.
Система работает в режиме высокой доступности и не привязано к графику работы сотрудников, сопровождающих СУБД.
Для надежной реализации требуется наличие как минимум трёх серверов, два из которых являются резервными, при этом второй сервер может быть только наблюдателем (участником кворума) и не являться полноценным сервером, на который будет выполнено переключение в случае сбоя (может обладать минимальными аппаратными ресурсами).
В зависимости от реализации настройка может быть достаточно сложной. Кроме администрирования типового механизма репликации, также необходимо администрирование компонентов отказоустойчивого кластера.
Примеры:
Система работает в режиме 24/7, финансовые потери в случае простоя очень велики. В этом случае решение по отказоустойчивости с ручным переключением не сможет закрыть потребности бизнеса в плане доступности системы, так как с учётом человеческого фактора время простоя может быть достаточно большим. При этом системы с автоматическим переключением могут восстановить работу системы за достаточно короткое время и без влияния человеческого фактора. Второй вариант будет дороже, но возможно не кардинально, за счет того, что современные решения по отказоустойчивости позволяют настраивать упрощенную конфигурацию и таким образом экономить на аппаратных ресурсах
Система предназначена для работы финансового отдела, например бухгалтерии. Основные требования к системе — это сохранность данных и минимизация потерь при сбоях. При этом не критично если система будет неработоспособна какое-то время, например 10–15 минут. Для обеспечения таких требований ручного переключения будет вполне достаточно и использование более сложных систем с автоматическим переключением может быть избыточным.
Очевидно, что в современных условиях большинству систем требуются решения с автоматическим переключением на резервный сервер. Одним из таких решений является встроенная в Postgres Pro Enterprise технология отказоустойчивого кластера BiHA (Build-in High Availability).
Отказоустойчивый кластер на основе Postgres Pro BiHA.
BiHA — это расширение Postgres Pro, которое управляется утилитой bihactl и функциями из состава расширения. В сочетании с доработками ядра, SQL интерфейсом и служебным процессом biha-worker, координирующим узлы кластера, BiHA превращает несколько узлов в кластер с физической репликацией Postgres и встроенным аварийным переключением узлов, отказоустойчивостью и автоматическим восстановлением после отказа.
Ключевые особенности:
для организации кластера нужно минимум три сервера, но третий узел можно настроить как рефери, который используется только в роли наблюдателя для обеспечения кворума, то есть он не может стать лидером;
не требуется наличие внешних компонент, для которых также нужно обеспечить отказоустойчивость и доступность;
удобное управление кластером с помощью утилиты bihactl (инициализация и добавление узлов) и запросами к функциям и представлениям расширения biha (просмотр состояний узлов, ручное переключение на мастер, установка параметров кластера);
поддержка синхронной и асинхронной репликации может быть задана для кластера в целом;
реализовано в Postgres Pro Enterprise начиная с версии 16.
Схема настройки отказоустойчивого кластера на основе BiHA
Существует несколько вариантов конфигурации узлов: три и более узлов и вариант, когда к двум узлам (мастер и реплика) добавляется ещё узел рефери.
На приведенной схеме (рис. 1) изображён вариант трёхузлового кластера BiHA для работы с сервером 1С.
Вариант, состоящий из двух серверов, в данной статье не рассматривается, так как при отказе основного сервера в такой конфигурации или в случае разрыва сети между двумя узлами для предотвращения Split Brain кластер будет доступен только для чтения, то есть станет фактически недоступным из 1С. Split Brain — часто использующийся термин, описывающий ситуацию разделения кластера, когда клиентские соединения могут записывать данные на оба сервера.
Для решения этой проблемы используется узел-рефери, который участвует в голосовании во время выборов нового мастера при отказе основного сервера, позволяет избежать потенциального разделения кластера. В зависимости от режима — referee или referee_with_wal — узел-рефери может принимать только участие в выборе нового мастера либо ещё дополнительно реплицировать данные журнала WAL, для того чтобы новый мастер получил все файлы WAL с узла-рефери (если там оказались самые последние журнальные записи перед сбоем мастера).
На приведенной схеме (рис. 1) один из узлов может быть узлом-рефери, он может обладать минимальными аппаратными ресурсами, так как он не содержит данных 1С и будет являться только «наблюдателем» за другими узлами кластера.
Ссылки на документацию:
https://postgrespro.ru/docs/enterprise/16/biha
https://postgrespro.ru/clusters/biha
Инициализация отказоустойчивого кластера
Чтобы узлы кластера BiHA могли подключаться друг к другу необходимо на каждом узле в домашней директории пользователя postgres (/var/lib/postgresql/) заполнить файл паролей .pgpass и разрешить доступ к нему только для владельца:
sudo -u postgres mcedit /var/lib/postgresql/.pgpass
:5432::biha_replication_user:<password>
sudo chmod 600 /var/lib/postgresql/.pgpassПри инициализации кластера можно создать узел мастера и узлы реплики с нуля либо преобразовать уже существующие узлы и включить их в отказоустойчивый кластер. Для инициализации кластера и добавления в него узлов используется утилита bihactl, также с её помощью можно посмотреть статус каждого узла (https://postgrespro.ru/docs/enterprise/16/bihactl).
Пример команды для инициализации существующего кластера Postgres (опция --convert):
sudo -u postgres /opt/pgpro/ent-16/bin/bihactl init --convert --biha-node-id=1 --host=192.168.50.01 --port=5432 --biha-port=5433 --nquorum=2 --pgdata=/var/lib/pgpro/ent-16/data/Описание параметров:
biha-node-id — уникальный идентификатор узла;
host, port — адрес узла;
biha_port — порт для обмена служебной информацией между узлами;
nquorum — число работающих узлов, участвующих в голосовании по выбору нового лидера;
pgdata — каталог данных кластера Postgres.
Добавление ведомых узлов в кластер
Перед добавлением узлов желательно проверить доступность мастера с ведомого узла, например:
sudo -u postgres psql -h <IPServer> -p 5432 -U biha_replication_user -d postgresЕсли подключение проходит успешно, то можно добавить узел в кластер BiHA с помощью команды bihactl add на ведомом узле:
sudo -u postgres /opt/pgpro/ent-16/bin/bihactl add --biha-node-id=2 --host=192.168.50.02 --port=5432 --biha-port=5433 --use-leader "host=192.168.50.01 port=5432 biha-port=5433" --pgdata=/var/lib/pgpro/ent-16/data/Для добавления существующего кластера можно использовать опцию --convert-standby, если вы уже настраивали репликацию с основного узла.
Таким же образом можно добавить несколько дополнительных ведомых узлов.
Для добавления узла-рефери, который не может стать лидером, но может участвовать в голосовании и таким образом предотвратить потенциальное разделение кластера, необходимо указать лишь дополнительный параметр --mode.
sudo -u postgres /opt/pgpro/ent-16/bin/bihactl add --biha-node-id=3 --host=192.168.50.03 --port=5432 --biha-port=5433 --use-leader "host=192.168.50.01 port=5432 biha-port=5433" --pgdata=/var/lib/pgpro/ent-16/data/ --mode="referee_with_wal"Параметр --mode может быть равен:
referee — узел только участвует в выборах лидера и не содержит данных
referee_with_wal — узел участвует в выборах лидера так же, как в режиме referee, и получает все файлы WAL от узла-лидера
Для основных узлов параметр --mode можно не указывать, в этом случае он имеет значение по умолчанию regular.
Администрирование
Администрирование и просмотр состояния кластера осуществляются с помощью SQL-функций и представления расширения, которые следует вызывать из базы данных biha_db:
biha.status_v — просмотр состояний узлов;
biha.config — возвращает значения параметров конфигурации кластера;
biha.nodes_v — представление, возвращает список узлов кластера;
biha.set_leader — функция ручного переключения на новый мастер;
biha.remove_node — функция удаления узла из кластера (предварительно этот узел нужно остановить).
Кроме того, расширение BiHA поддерживает дополнительные конфигурационные параметры для управления отказоустойчивым кластером, например:
biha.heartbeat_max_lost — максимальное число сообщений о контроле состояния, которые можно не получить до того, как узел будет считаться недоступным;
biha.heartbeat_send_period — частота отправки сообщений о контроле состояния в миллисекундах.
Полное описание параметров есть в документации по ссылкам ниже.
https://postgrespro.ru/docs/enterprise/16/biha#BIHA-CLUSTER-CONFIGURATION-FUNCTIONS
https://postgrespro.ru/docs/enterprise/16/biha#BIHA-VIEWS
https://postgrespro.ru/docs/enterprise/16/biha#BIHA-CONFIGURATION-PARAMETERS
Синхронный режим
BiHA также поддерживает синхронный режим репликации, для этого нужно при инициализации кластера добавить параметр --sync-standbys=<число синхронных реплик> к команде bihactl init.
При инициализации автоматически будут изменены параметры Postgres synchronous_commit и synchronous_standby_names . Репликация в BiHA кворумная, все ведомые узлы перечислены в synchronous_standby_names, при этом мастер ждет ответа, только от количества, указанного в параметре --sync-standbys.
Узел-рефери в режиме referee_with_wal тоже может участвовать в синхронной репликации, при этом, обратите внимание, если для параметра synchronous_commit установлено значение remote_apply, рефери не сможет подтверждать транзакции.
Единая точка входа для сервера 1С
В качестве единой точки входа можно использовать:
расширенную строку соединения с несколькими хостами;
возможность HAProxy выполнять в качестве проверки внешний скрипт.
Рассмотрим более подробно каждый из способов подключения.
Расширенная строка подключения
В Postgres есть возможность использовать расширенную строку подключения с помощью функции управления подключением к базе данных библиотеки libpq. Пример схемы такого подключения приведен на рис. 1.
Ссылка на описание в документации:
https://postgrespro.ru/docs/postgresql/15/libpq-connect#LIBPQ-CONNSTRING
1С поддерживает такую возможность в формате «ключ/значение», но с некоторыми нюансами, о которых будет сказано ниже.
Пример из документации по libpq:
host=localhost port=5432 dbname=mydb connect_timeout=10В строке подключения можно задать несколько узлов (host), к которым клиент будет пытаться подключиться в заданном порядке. Первый доступный узел становится выбранным для подключения, остальные узлы уже не рассматриваются. Параметры host и port в формате «ключ/значение» принимают списки значений, разделённых запятыми. В каждом определяемом параметре должно содержаться одинаковое число элементов, чтобы, например, первый элемент host соответствовал первому узлу, второй — второму узлу и так далее. Исключение составляет port — если этот параметр содержит только один элемент, он применяется ко всем узлам.
Если такой формат применить для строки подключения к узлам pgnode-01, pgnode-02, pgnode-03 со стандартным портом 5432, с необходимостью не подключаться к репликам, то строка, которая указывается в поле «Сервер баз данных», должна выглядеть так:
host=pgnode-01, pgnode-02, pgnode-03 port=5432 dbname=db1c target_session_attrs=read-writeПараметр target_session_attrs=read-write как раз позволяет выполнять подключение только к серверам, которые находятся в режиме чтения-записи, игнорируя реплики. Описание параметра из документации:
https://postgrespro.ru/docs/postgresql/15/libpq-connect#LIBPQ-CONNECT-TARGET-SESSION-ATTRS
При попытке настройки соединения 1С удалось прийти к рабочему варианту, который выглядит так:
pgnode-01, pgnode-02, pgnode-03 port=5432 target_session_attrs=read-writeТо есть из начала строки убран host= и параметр указания базы данных dbname=db1c, так как имя базы данных, как и при стандартном подключении, указывается в поле «База данных» (рис. 2).
Были проведены эксперименты с искусственным падением мастера и повышением реплики до мастера. В ходе таких переключений не только проверялась работа пользователей, но и выполнение групповых операций, например, обработкой в одной транзакции выполнялось проведение 100 документов.
Эксперименты показали, что при падении и смене мастера сеанс не получает ошибок, возникает зависание (оно связано со временем переключения узлов BiHA) и спустя короткое время пользователь может спокойно работать уже на другом сервере, не замечая каких-либо изменений. В ходе тестирования групповых операций ошибок также не возникало. Запускалось «проведение из обработки в транзакции», затем происходила смена лидера, возникала некоторая задержка в обработке документов, но в итоге операция завершалась успешно, ошибок при этом не было.
Единая точка входа через HAProxy
Кратко рассмотрим альтернативный вариант подключения к отказоустойчивому кластеру с использованием HAProxy.
Схема такого подключения представлена на рис. 3.
Пример такой настройки рассмотрен в статье 1С ИТС, её можно использовать в части настройки HAProxy, так как при использовании BiHA настройка будет очень похожа на ту, что используется в связке с Patroni описанную в статье:
https://its.1c.ru/db/metod8dev/content/5971/hdoc
Разница будет только в том, что для проверки состояния узлов нужно использовать метод проверки с помощью внешнего скрипта (external-check) вместо проверки http-статуса (http-check).
Пример настройки в haproxy.cfg:
listen postgres_lc
bind *:5432
option external-check
external-check command /var/lib/haproxy/pgcheck.sh
default-server inter 3s fastinter is fall 2 rise 2 on-marked-down shutdown-sessions
server pgnode-01 192.168.50.01:5432 maxconn 100 check
server pgnode-02 192.168.50.02:5432 maxconn 100 check
server pgnode-03 192.168.50.03:5432 maxconn 100 checkСкрипт pgcheck.sh должен возвращать «0» для разрешённых подключений и «1» для реплик, а также недоступных серверов.
При проверке узлов HAProxy опрашивает их состояния с периодичностью, заданной параметром timeout check, и если скрипт возвращает «0», то сервер считается доступным для подключения. Для реализации проверки можно использовать функцию pg_is_in_recovery(), которая возвращает «f», если кластер не является репликой.
Единая точка входа через Postgres Pro Proxima
В 17-й версии в Postgres Pro появилось собственное решение проксирования соединений на лидера — Proxima, но, пока 1С не сертифицирован под 17.2.2, опустим описание этого метода.
Использование механизма копий баз данных
Аппаратные мощности серверов, на которых размещены реплики, по большей части простаивают, и было бы оптимально перенаправлять часть запросов на резервный сервер, для того чтобы снизить нагрузку на основном сервере. У реплик Postgres есть возможность принимать запросы на чтение, и эту возможность можно использовать в сочетании с механизмом копий баз данных 1С.
Механизм копий баз данных 1С позволяет использовать в качестве копии реплику Postgres, для этого нужно выбрать внешний тип репликации 1С. При внешнем типе репликации 1С не выполняет никаких действий по созданию и обновлению таблиц в копии, так как предполагается, что эти действия выполняются внешними средствами. Особенностью реплики Postgres является то, что она доступна только для чтения, включая невозможность использования временных таблиц. Такое ограничение приводит к тому, что запросы, использующие временные таблицы, будут завершаться с ошибкой. Для снятия этого ограничения требуется создание дополнительного кластера Postgres Pro, доступного для записи данных, который будет обращаться к данным реплики через механизм внешних таблиц (https://postgrespro.ru/docs/enterprise/16/postgres-fdw).
Ниже описан пример такого решения.
Создается дополнительная служба, и инициализируется новый кластер Postgres на сервере, который является репликой или потенциально может ею стать (к примеру, pgnode-01 на схеме рис. 4). Порядок действий здесь не отличается от обычной установки Postgres, но для дополнительного экземпляра будет использоваться другой порт (5433). При необходимости можно создать нового пользователя (usr1cv8) для подключения из «1С:Предприятие» (если не планируется использовать суперпользователя postgres), у пользователя обязательно должны быть административные права:
CREATE USER usr1cv8 WITH SUPERUSER LOGIN ENCRYPTED PASSWORD 'usr1cv8';Необходимо создать пустую информационную базу (dbcopy1C) в новом кластере средствами 1С (непосредственно в PostgreSQL создавать пустую базу нельзя, т.к. 1С:Предприятие выполняет тонкие настройки, без которых 1С с базой данных работать не сможет).
Для настройки внешних таблиц нужно выполнить следующие действия:
подключиться к созданной базе данных с помощью psql:
sudo -u postgres psql -p 5433 -d dbcopy1Cудалить все существующие таблицы из базы данных:
select 'DROP TABLE ' || string_agg(tablename, ', ') || ';' from pg_tables where schemaname = 'public' \gexecсоздать в базе расширение postgres_fdw:
CREATE EXTENSION postgres_fdw;создать внешний сервер, указывая параметры для подключения к резервному серверу:
CREATE SERVER standby_server FOREIGN DATA WRAPPER postgres_fdw OPTIONS (host '<host>', dbname 'dbcopy1C', port '5432');Для строки подключения здесь также можно использовать расширенный формат, как и для подключения к основной базе данных, <host> для текущего примера будет равен:
pgnode-01, pgnode-02, pgnode-03 target_session_attrs=read-only
Внешний сервер будет пытаться подключиться к узлам, которые имеют статус read-only, то есть являются репликами, в том порядке, в котором они указаны в строке подключения.
Кроме того, при перечислении нескольких доступных реплик можно ещё в строку <host> добавить параметр hostorder=random (параметр доступен только для PostgresPro), который позволит выбирать доступную реплику не в том порядке, в котором она указана в строке подключения, а в случайном порядке, таким образом выполняя балансировку между репликами.
создать отображение для пользователей промежуточного сервера:
CREATE USER MAPPING FOR postgres SERVER standby_server OPTIONS (user 'usr1cv8', password 'usr1cv8'); CREATE USER MAPPING FOR usr1cv8 SERVER standby_server OPTIONS (user 'usr1cv8', password 'usr1cv8');выполнить импорт таблиц внешней базы:
IMPORT FOREIGN SCHEMA public FROM SERVER standby_server INTO public;Для того чтобы копия базы данных продолжила работать при выходе из строя одного из узлов, имеет смысл выполнить действия аналогичные пп.1–3 на остальных серверах (в данном примере для pgnode-02 и pgnode-03).
При этом, если не предполагается использовать случайный порядок выбора внешнего сервера (параметр hostorder=random), то имеет смысл указывать первым в списке текущий сервер, чтобы он стал приоритетным для выбора.
Это позволит избежать передачи данных между локальным и соседним экземплярами (если это разные сервера) при возвращении результата запроса и других сетевых взаимодействиях.
В настройках подключения к копии базы данных 1С необходимо указать строку соединения с этими серверами (рис. 5):
сервер баз данных: pgnode-01, pgnode-02, pgnode-03 port=5433;
база данных: dbcopy1C;
Использовать параметр target_session_attrs=read-only здесь не имеет смысла, т.к. промежуточные кластеры не являются репликами и могут принимать подключения как на чтение, так и на запись.
Для добавления копии баз данных в «1С:Предприятие» используется стандартная обработка «Управление копиями баз данных», при добавлении копии нужно указать тип репликации «Внешняя», а также тип СУБД, сервер/порт и имя базы данных.
Кроме того, необходимо в обработке выбрать все объекты конфигурации при добавлении копии, так как внешний тип репликации подразумевает, что копия включает в себя все объекты базы данных.
В случае изменения структуры метаданных информационной базы 1С необходимо обновить описание внешних таблиц в промежуточной базе данных. Для этого следует удалить внешние таблицы и импортировать схему заново:
подключиться к промежуточной базе данных с помощью psql:
sudo -u postgres psql -p 5433 -d dbcopy1Cудалить описание внешних таблиц из базы данных:
select 'DROP FOREIGN TABLE ' || string_agg(table_name, ', ') || ';' from information_schema.tables where table_type = 'FOREIGN' \gexecвыполнить повторно импорт таблиц внешней базы:
IMPORT FOREIGN SCHEMA public FROM SERVER standby_server INTO public;Если резюмировать, то данный подход позволяет нагрузить реплики запросами на чтение, например отчётами, и таким образом снизить нагрузку на основном сервере.
При этом в случае отказа одного из серверов и смене мастера перенастраивать копию баз данных не потребуется, так как копии дублируются на всех узлах и подключение выполняется к первому доступному серверу из списка, указанному в поле «Сервер баз данных».
После того как промежуточный кластер Postgres получает запрос от сервера 1С, он перенаправляет его к внешнему серверу-реплике, так как указан параметр target_session_attrs=read-only. И в зависимости от того, указан ли параметр hostorder=random, запрос перенаправляется на первую либо на случайную доступную реплику из списка.
Исполнение длительных запросов на реплике
При значении параметра max_standby_streaming_delay по умолчанию (30 секунд) выполнение длительных отчётов на копии базы данных будет периодически прерываться, и «1С:Предприятие» будет направлять такие запросы на основной сервер вместо их выполнения на копии БД. Это связано с тем, что реплика может отменять запросы, конфликтующие с очередными изменениями в WAL, которые приходят на резервный сервер, соответственно, такие запросы будут прерываться с ошибкой.
Поэтому значение параметра max_standby_streaming_delay для реплики Postgres должно быть достаточно большим (вплоть до бесконечности «-1»), для того чтобы длительный запрос не прерывался по ошибке при применении конфликтующих WAL-записей. В связи с этим, возможно, имеет смысл копию БД связывать с отдельной репликой Postgres, для того чтобы не допускать сильного отставания остальных реплик от мастера и в том числе обеспечивать высокую доступность базы данных. Для таких реплик рекомендуется устанавливать параметры biha.can_be_leader и biha.can_vote в значение false, для того чтобы отключить возможность для них стать лидером и участвовать в голосовании.
Использование механизма копий баз данных совместно с HAProxy
По аналогии с настройкой основного подключения к базе данных через HAProxy со стороны сервера 1С можно выполнить похожую настройку для механизма копий баз данных. Это может понадобиться, если есть потребность в более гибкой настройке балансировки нагрузки между репликами.
Краткое описание:
на каждом сервере создаются дополнительные кластеры Postgres и настраиваются для подключения к репликам через механизм внешних таблиц (postgres_fdw) аналогично тому, как это было рассмотрено в предыдущем примере
по аналогии с созданием единой точки входа для клиентских подключений 1С используется возможность HAProxy выполнять в качестве проверки внешний скрипт. В файл haproxy.cfg добавляется раздел listen postgres_dbcopy, который настроен таким образом, что принимает подключения через порт 5433
bind *:5433
option external-check
external-check command /var/lib/haproxy/dbcopycheck.sh
default-server inter 3s fastinter ls fall 2 rise 2 on-marked-down shutdown-sessions
server pgnode-01 192.168.50.01:5433 maxconn 100 check
server pgnode-02 192.168.50.02:5433 maxconn 100 check
server pgnode-03 192.168.50.03:5433 maxconn 100 checkвозможность подключения проверяется через внешний скрипт dbcopycheck.sh, который, в отличие от скрипта для проверки подключения к основной базе pgcheck.sh, должен возвращать «0» для разрешённых подключений (для доступных реплик) и «1», если сервер недоступен или является мастером. Аналогично для таких проверок в скрипте можно использовать функцию pg_is_in_recovery()
сервер 1С подключается к HAProxy через порт 5433. Далее HAProxy перенаправляет запрос на доступный сервер, указанный в группе параметров listen postgres_dbcopy
кроме создания единой точки входа HAProxy имеет такую полезную функцию, как балансировка нагрузки между серверами, то есть при наличии нескольких доступных реплик нагрузка будет равномерно распределяться между ними. Эта возможность поддерживается 1С и при настройках HAProxy по умолчанию, каждый новый запрос направляется на следующую доступную реплику, при этом алгоритм балансировки может быть изменён и обладает достаточно гибкой настройкой.
