Чтобы добавить узел, используйте команду bihactl node add с соответствующими параметрами.

Чтобы добавить сегмент, используйте функцию biha.add_node.

Чтобы добавить узел в определённый сегмент или переместить узел из одного сегмента в другой, используйте функцию biha.set_parent, а затем примените изменения с помощью функции biha.apply_topology.

Чтобы удалить узел или сегмент, используйте функцию biha.remove_node.

Чтобы изменить лидера вручную, используйте функцию biha.set_leader. За подробной информацией обратитесь к разделу Ручное переключение узлов.

Некоторые параметры конфигурации BiHA являются общими для всех узлов кластера. Они должны иметь одинаковое значение на всех узлах, а задавать их можно только на лидере с помощью специальных функций. Например, чтобы установить значение параметра biha.heartbeat_max_lost, используйте функцию biha.set_heartbeat_max_lost:

SELECT biha.set_heartbeat_max_lost(7);

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

Параметры конфигурации, критичные для GDBiHA-кластеров, хранятся в файле pg_biha/biha.conf и не могут быть изменены через ALTER SYSTEM. Чтобы их изменить, необходимо использовать специальные функции. За подробной информацией обратитесь к Подразделу 27.4.1.2.

Параметры BiHA, значения которых могут различаться на разных узлах кластера, можно изменять с помощью команды ALTER SYSTEM. Например, параметр biha.can_be_leader можно изменить через ALTER SYSTEM:

ALTER SYSTEM SET biha.can_be_leader = true;
SELECT pg_reload_conf();

Чтобы назначить нового лидера или главного последователя, вызовите функцию biha.set_leader с указанием идентификатора узла, который необходимо повысить. В зависимости от сегмента, в котором расположен назначенный узел (сегмент-лидер или сегмент-последователь), узел становится либо лидером, либо главным последователем этого сегмента.

Для переключения между сегментами вызовите функцию biha.set_leader с указанием идентификатора сегмента, который необходимо повысить до сегмента-лидера. После переключения главный последователь повышенного сегмента становится новым лидером, а бывший лидер становится главным последователем своего сегмента.

Состояние назначенного узла меняется на FOLLOWER_OFFERED.

Все попытки начать выборы блокируются.

Текущий лидер меняет своё состояние на LEADER_RO. При переключении главного последователя его состояние остаётся неизменным (FRONT_FOLLOWER).

FOLLOWER_OFFERED ищет наиболее актуальный источник репликации в своём сегменте и настраивает репликацию с этого источника.

Когда узел в состоянии FOLLOWER_OFFERED обнаруживает, что в кластере отсутствует лидер в состоянии LEADER_RW, и при этом обладает наибольшим количеством данных в рамках сегмента, он становится новым лидером или главным последователем.

Если процесс переключения не завершается в течение установленного параметром biha.no_wal_on_follower тайм-аута, назначенный узел возвращается в роль последователя, а текущий лидер или главный последователь сохраняет свою роль. Однако при отсутствии лидера или главного последователя происходят автоматические выборы нового лидера или главного последователя.

BIHA_CLUSTER_MANAGEMENT_ROLE — отвечает за выполнение всех функций расширения biha.

BIHA_REPLICATION_ROLE — используется при работе pg_rewind и pg_probackup.

biha_replication_user — является членом ролей BIHA_REPLICATION_ROLE и BIHA_CLUSTER_MANAGEMENT_ROLE и может совершать как клиентские подключения, так и подключения по протоколу репликации. Эта роль используется утилитой bihactl, а также при подключении узла-последователя к узлу-лидеру. Является владельцем базы данных biha_db. Пароль для роли biha_replication_user в файле паролей должен быть одинаковым на всех узлах BiHA-кластера. Пароль предлагается задать во время создания BiHA-кластера.

biha_callbacks_user — по умолчанию исполняет функции-обработчики. Этот пользователь может подключаться к базе данных, но не имеет никаких прав.

pg_monitor — предопределённая роль, которая используется для мониторинга состояния BiHA-кластера.

последователи продолжают получать WAL

выборы отменяются и ни один узел не может выставить себя кандидатом

лидера можно переключить вручную

Включить сервисный режим, установив для параметра enable функции biha.service_mode значение true:

SELECT biha.service_mode(true);

Отключить сервисный режим, установив для параметра enable функции biha.service_mode значение false:

SELECT biha.service_mode(false);

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

biha _db=# SELECT biha.service_mode (false);
ERROR: [BiHA] Config changes
HINT: Some parameters have been changed but not applied:
Node 3: max_connections
To force exit service mode, use: "select * from biha.service_mode(false, true)"

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

SELECT biha.service_mode(false, true);

Включите автоматическую синхронизацию (automatic rewind), установив для параметра конфигурации biha.autorewind значение true. Автоматическая синхронизация выполняется, если она может успешно завершиться, то есть если предварительный запуск инструмента pg_rewind с параметром --dry-run прошёл успешно.

При неудачной автоматической синхронизации узел переходит в состояние NODE_ERROR. В этом случае фактическое состояние синхронизации узла можно найти в файле biha.state, как описано в Подразделе 27.3.7.1.

Чтобы избежать запуска pg_rewind в тех случаях, когда расхождение WAL вызвано только лишними записями сообщений о контроле состояния, можно воспользоваться возможностью выравнивания WAL, которая управляется с помощью параметра конфигурации biha.autowaltrim. Когда алгоритм выравнивания WAL включён, он находит последнюю общую точку в журналах WAL отклонившегося узла и нового лидера, проверяет, что все последующие записи содержат только сообщения о контроле состояния, и автоматически удаляет эти лишние записи с отклонившегося узла, чтобы он мог продолжить репликацию. Это удобно в случае, когда произошло разделение кластера (split-brain) и бывший лидер возвращается в кластер в качестве последователя, но не может начать репликацию из-за того, что в его WAL содержатся записи сообщений о контроле состояния, сгенерированные, когда он ещё был лидером.

Если процедура выравнивания WAL завершается неудачно, состояние узла изменяется на NODE_ERROR.

Параметры выравнивания WAL можно посмотреть в файле biha.state. За подробной информацией обратитесь к Подразделу 27.3.7.2.

Синхронизация, автоматически выполняемая расширением biha с использованием pg_rewind при расхождении линий времени узла.

Процесс walreceiver в случае расхождения линий времени. WAL узла-последователя может быть частично перезаписан WAL, полученным от узла-лидера.

Если процесс biha не отвечает, когда достигнуто значение biha.watchdog_timeout, узел прекращает принимать запросы и его состояние временно изменяется на NODE_ERROR.

Следующее сообщение в журнале информирует о проблеме: «The request cannot be processed because the BiHA extension is not responding» (Невозможно обработать запрос, так как расширение BiHA не отвечает).

В зависимости от того, как быстро восстановится процесс biha, происходит следующее:

Синхронная репликация и рефери

Включение кворумной синхронной репликации

Управление репликацией

Смягчение ограничений кворумной синхронной репликации

Настройка каскадной репликации

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

Node Controller: основной компонент расширения biha, ответственный за логику работы узла, в журнале отмечен как NC.

Postgres Controller: компонент biha, необходимый для управления и мониторинга компонентов Postgres Pro, таких как настройка репликации, параметры конфигурации, процессы walsender и walreceiver и т.д. Postgres Controller доводит Postgres Pro до состояния, необходимого для работы BiHA. В журнале Postgres Controller помечен как PGC.

Config Controller: конфигурационный модуль, который управляет конфигурацией узла (параметры GUC и biha.conf) и синхронизирует её на узлах кластера. В журнале Config Controller помечен как BC.

Когда один из процессов biha завершается ошибкой (уровни ERROR и FATAL).

Когда вызывается функция ядра, которая принимает уровень протоколирования в качестве своего аргумента.