Postgres Pro Enterprise : Документация: 16: F.8. biha — встроенный отказоустойчивый кластер : Компания Postgres Professional

RU
EN
RU EN

F.8. biha — встроенный отказоустойчивый кластер
Пред.	Наверх	Приложение F. Дополнительно поставляемые модули и расширения, поставляемые в `postgrespro-ent-16-contrib`	Начало	След.

F.8. biha — встроенный отказоустойчивый кластер #

F.8.1. Архитектура
F.8.2. Подготовка BiHA-кластера
F.8.3. Администрирование
F.8.4. Справка

biha — это расширение Postgres Pro, которое управляется утилитой bihactl. В сочетании с доработками ядра, SQL интерфейсом и служебным процессом biha-background-worker, координирующим узлы кластера, biha превращает Postgres Pro в BiHA-кластер — кластер с физической репликацией и встроенным аварийным переключением узлов, отказоустойчивостью и автоматическим восстановлением после отказа узлов.

По сравнению с существующими кластерными решениями — стандартным кластером PostgreSQL конструкции ведущий-ведомый и кластером, настроенным при помощи multimaster, — BiHA-кластер отличается следующими преимуществами:

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

F.8.1. Архитектура #

Благодаря встроенным возможностям отказоустойчивости Postgres Pro позволяет создавать кластер с выделенным узлом-лидером и несколькими узлами-последователями. Утилита bihactl позволяет инициализировать кластер и создавать узел-лидер, добавлять узлы-последователи, преобразовывать существующий узел в узел-лидер или узел-последователь в BiHA-кластере, а также проверять статус узлов кластера. Лидер доступен для чтения и записи, в то время как последователи доступны только для чтения и реплицируют данные с лидера в синхронном или асинхронном режиме.

Физическая потоковая репликация, реализованная в biha, обеспечивает отказоустойчивость, защищая от отказов серверов и системы хранения данных. При физической репликации файлы WAL узла-лидера синхронно или асинхронно отправляются на узел-последователь и применяются на нём. При синхронной репликации для каждой фиксации транзакции пользователь ожидает подтверждения от узла-последователя. Узел-последователь кластера biha может использоваться для выполнения следующих задач:

Выполнение читающих транзакций в базе данных.
Подготовка отчётов.
Создание таблиц в оперативной памяти для пишущих транзакций.
Подготовка резервной копии узла-последователя.
Восстановление повреждённых блоков данных на узле-лидере путём получения этих блоков с узла-последователя.
Проверка повреждённых записей в файлах WAL.

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

Отказ узла-лидера. В этом случае статус узла-последователя повышается, и он становится новым лидером кластера. Повышение выполняется либо вручную с помощью функции biha.set_leader, либо автоматически с помощью выборов.
Отказ узла-последователя. Если последователь настроен как асинхронный, отказ никак не отразится на лидере. Если для последователя используется синхронная репликация, отказ приведёт к остановке транзакции на лидере, так как он перестанет получать подтверждение транзакций от последователя и транзакция не сможет завершиться. Подробное описание того, как настроить синхронную репликацию в BiHA-кластере, находится в Подразделе F.8.3.6.
Сбой соединения между узлом-лидером и узлом-последователем. В этом случае лидер не может отправить, а последователь не может получить данные. Обратите внимание, что если пользователи подключены к лидеру, разрешать пишущие транзакции на последователе нельзя. Любые изменения, сделанные на последователях, нельзя будет восстановить на лидере. Чтобы избежать потери изменений, настраивайте сеть с резервными каналами. Лучше всего настроить свой канал передачи данных для каждого последователя, чтобы предупредить проблемы, связанные с единой точкой отказа.

В аварийной ситуации, например отказе операционной системы или оборудования, можно переустановить Postgres Pro и удалить расширение biha из shared_preload_libraries, чтобы вернуться к работе в максимально короткие сроки.

F.8.1.1. Варианты конфигурации кластера #

Существует несколько вариантов конфигурации кластера.

Три и более узлов, один из которых является лидером, а остальные — последователями.
Ниже представлены возможные сценарии при отказе лидера или сбое сетевого подключения:
- При отказе текущего лидера новый лидер избирается автоматически. Чтобы стать лидером, последователь должен получить максимальное количество голосов. Количество голосов должно быть больше или равно значению, заданному в параметре biha.nquorum.
- При сбоях сетевого соединения внутри кластера BiHA кластер может разделиться на несколько групп узлов. В этом случае новый лидер избирается во всех группах, в которых количество узлов больше или равно значению biha.nquorum. После восстановления соединения лидер кластера выбирается между старым и новоизбранным лидером в зависимости от значения term. Узел с наибольшим значением term становится новым лидером. Рекомендуется установить значение biha.minnodes равным значению biha.nquorum.
Кластер из двух узлов, состоящий из лидера и последователя.
Примечание
Не рекомендуется использовать кластер из двух узлов, поскольку такая конфигурация может вызвать проблемы разделения кластера. Чтобы их избежать, добавьте узел-рефери.
Ниже представлены возможные сценарии при отказе лидера или сбоях сети:
- При отказе лидера узел-последователь автоматически становится новым лидером, если для параметра конфигурации biha.nquorum установлено значение 1.
- Если между лидером и последователем происходят сетевые сбои, и для обоих параметров конфигурации biha.nquorum и biha.minnodes установлено значение 1, кластер может разделиться на двух лидеров, доступных для чтения и записи. Подобных проблем позволяет избежать узел-рефери.
Конфигурация с одним узлом-лидером. Этот вариант возможно использовать, пока не будут настроены последователи. Логично, что узел нельзя заменить при сбое ввиду отсутствия последователей, которые могут стать лидером.
Кластер с тремя узлами, состоящий из лидера, последователя и рефери. Узел-рефери используется для голосования при выборе нового лидера, но сам не может стать лидером. При возникновении сбоев кластер с рефери ведёт себя как кластер с тремя узлами (лидером и двумя последователями). Чтобы подробнее узнать о рефери, обратитесь к Подразделу F.8.1.3.

Примечание

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

F.8.1.2. Выборы #

Выборы — это процесс определения лидера, который проводят последователи при отказе текущего лидера. В результате выборов лидером кластера становится последователь с наибольшим числом записей в WAL. Чтобы узел мог быть избран лидером, для параметров biha.can_be_leader и biha.can_vote этого узла должно быть установлено значение true.

Выборы проводятся с учётом кворума кластера, то есть минимального количества узлов, участвующих в голосовании. Значение кворума задаётся в параметре biha.nquorum при инициализации кластера командой bihactl init. Узлы, для которых в параметре biha.can_vote установлено значение false, исключаются из голосования и игнорируются в nquorum.

Чтобы начались выборы, последователи должны не получить максимальное количество сообщений о контроле состояния, заданное функцией biha.set_heartbeat_max_lost. На этом этапе один из последователей выдвигает себя в качестве кандидата в лидеры (CANDIDATE), и начинаются выборы. Если в этом случае лидер не получает заданное количество сообщений о контроле состояния от последователя, состояние последователя меняется на UNKNOWN для лидера. В синхронном кластере можно задать приоритет узлов с помощью параметра biha.node_priority. Если в кластере только два узла и вы хотите избежать возможных проблем разделения кластера во время выборов, создайте узел-рефери, который участвует в голосовании так же, как последователи. За подробностями обратитесь к Подразделу F.8.1.3.

Например, в случае отказа одного узла-последователя в кластере из трёх узлов, где значение nquorum=2, узел-лидер продолжит работать. При отказе лидера в таком кластере два оставшихся последователя начнут выборы. После избрания нового лидера значение поколения кластера term увеличивается на единицу для всех узлов, то есть для нового лидера и оставшихся последователей term=2, а для старого лидера останется равным term=1. Когда старый лидер возвращается в кластер, происходит его понижение, то есть старый лидер становится последователем.

После избрания нового лидера последователи начинают получать файлы WAL уже от него. Обратите внимание, что при выборе нового лидера старый лидер понижается и становится недоступным для пишущих транзакций, чтобы избежать проблем разделения кластера (split brain). Вы можете вручную повысить старого лидера, используя функцию biha.set_leader. Механизмы кворума и поколения реализованы в biha на базе алгоритма консенсуса Raft.

F.8.1.3. Узел-рефери в BiHA-кластере #

В отказоустойчивом кластере можно создать узел-рефери, который будет участвовать в выборах узла-лидера и помогает избежать потенциального разделения кластера, состоящего только из лидера и последователя. В этом случае после создания рефери установите значение 2 для обоих параметров конфигурации biha.nquorum и biha.minnodes.

При создании рефери на него копируются только база данных biha_db и системные таблицы. База данных postgres и пользовательские данные не копируются.

Расширение biha поддерживает два режима работы рефери:

Режим referee. В этом режиме узел принимает участие только в выборах лидера, но не в репликации данных. Кроме того, для рефери не создаются слоты репликации ни на лидере, ни на последователях.
Режим referee_with_wal. В этом режиме узел участвует не только в выборах лидера таким же образом, как и в режиме referee, но и в репликации данных, и получает весь WAL с узла-лидера. Если на момент начала выборов больше всего записей WAL среди узлов кластера накопится на узле-рефери, то есть у рефери будет наибольший LSN, узел-последователь будет пытаться получить недостающие файлы WAL с рефери. Этот процесс важен для того, чтобы узел-рефери не перешел в состояние NODE_ERROR, что возможно при расхождении WAL. Для referee_with_wal, apply lag равен NULL и apply ptr невозможно изменить, так как рефери не применяет данные пользователя.

Вне зависимости от установленного режима работы узла-рефери, он отправляет и получает сообщения о контроле состояния по каналу управления, в том числе с использованием SSL, участвует в выборах так же, как и узлы-последователи, поддерживает функции мониторинга кластера и должен учитываться, когда задаётся значение параметра biha.minnodes. Обратите внимание, что рефери — это конечное состояние узла: его нельзя сделать лидером при помощи функции biha.set_leader, и он не может стать узлом-последователем. Если по какой-либо причине последователь «не видит» лидера, но его видит рефери, рефери не позволит последователю стать лидером. Если лидер с более высоким значением поколения term подключится к рефери, рефери понизит статус лидера с более низким значением term до последователя.

F.8.2. Подготовка BiHA-кластера #

Подготовка BiHA-кластера выполняется при помощи утилиты bihactl. Есть несколько сценариев использования утилиты:

Прежде чем начать подготовку BiHA-кластера, внимательно изучите Подраздел F.8.2.1.

F.8.2.1. Предварительные требования и особенности #

Прежде чем начать подготовку BiHA-кластера, прочитайте следующую информацию и выполните необходимые действия:

Обеспечьте сетевую связность между всеми узлами вашего будущего BiHA-кластера.
Если необходима изоляция сети, при которой управляющий канал и передача WAL работают в одной сети, а клиентские сеансы с базой данных — в другой, настройте BiHA-кластер следующим образом:
- Используйте имена узлов, которые разрешаются в IP-адреса сети для управляющего канала и WAL.
- Добавьте IP-адрес для клиентских соединений в параметр конфигурации listen_addresses.
Чтобы избежать проблем с biha-background-worker, связанных с настройкой времени на узлах кластера, настройте синхронизацию времени на всех узлах.
Пароль для роли biha_replication_user в файле паролей должен быть одинаковым на всех узлах кластера BiHA. Это необходимо для обеспечения связи между лидером и последователями. Пароль можно указать одним из следующих способов:
- Безопасный и рекомендуемый способ — добавить отдельную строку для каждого узла:
```
echo 'имя_узла:порт:biha_db:biha_replication_user:пароль' >> ~/.pgpass

echo 'имя_узла:порт:replication:biha_replication_user:пароль' >> ~/.pgpass
```
- Простой способ — добавить одну строку для всех узлов:
```
echo '*:*:*:biha_replication_user:пароль' >> ~/.pgpass
```
Во время работы biha создаёт следующие служебные файлы в каталоге данных:
- standby.signal — файл, при наличии которого узел запускается в режиме резервного сервера. Файл необходим для того, чтобы сделать расширение biha доступным только для чтения при запуске Postgres Pro. Файл удаляется с лидера, когда он переходит в состояние LEADER_RW.
- файлы biha.state и biha.conf — в каталоге pg_biha, необходимые для сохранения внутреннего состояния и конфигурации расширения biha.
Во время работы biha использует собственный механизм, чтобы динамически изменять конфигурацию Postgres Pro. Некоторые параметры Postgres Pro управляются расширением biha и изменить их с помощью ALTER SYSTEM невозможно, так как они критичны для работы biha. К таким параметрам относятся:
Эти параметры хранятся в файле pg_biha/biha.conf, а также в разделяемой памяти процесса biha. Когда эти параметры изменяются, biha отправляет сигнал SIGHUP, чтобы проинформировать другие процессы об изменениях. Если в это время изменить какие-либо другие параметры и не перечитать конфигурацию, изменённые параметры могут быть перечитаны неожиданно.
Postgres Pro ведёт себя вышеописанным образом, только когда расширение biha загружено и настроено, т.е. когда библиотека указана в переменной shared_preload_libraries и установлены необходимые параметры biha.*. В других случаях Postgres Pro работает, как обычно.
При инициализации BiHA-кластера расширение biha изменяет конфигурацию Postgres Pro в postgresql.conf и pg_hba.conf. Изменения сначала вносятся в служебные файлы biha postgresql.biha.conf и pg_hba.biha.conf, а затем обрабатываются сервером после указания следующих директив включения в postgresql.conf и pg_hba.conf соответственно:
```
include 'postgresql.biha.conf'
include "pg_hba.biha.conf"
```
В некоторых операционных системах управление сеансами пользователей может осуществляется менеджером служб systemd. В этом случае, если сервер запущен с использованием pg_ctl и управляется удалённо, имейте в виду, что при завершении SSH-сеанса все фоновые процессы, инициированные в нём, будут также завершены демоном systemd. Чтобы избежать такого поведения, выполните одно из следующих действий:
- Воспользуйтесь файлом службы postgrespro-ent-16 менеджера systemd для запуска сервера СУБД на узле кластера.
- Измените конфигурацию службы управления сеансами пользователей systemd-logind в файле /etc/systemd/logind.conf, а именно установите значение no для параметра KillUserProcesses.

F.8.2.2. Подготовка BiHA-кластера с нуля #

Чтобы подготовить BiHA-кластер с нуля, выполните следующие действия.

Предварительные требования

На всех узлах будущего кластера установите пакет postgrespro-ent-16-contrib. Не создавайте экземпляры баз данных.
Убедитесь, что вы выполняете команду bihactl от имени пользователя, который будет запускать сервер Postgres Pro Enterprise.
Например, если вы запускаете сервер как пользователь postgres, команда bihactl должна также выполняться пользователем postgres.
Если вы планируете использовать pg_probackup с biha, установите пакет pg-probackup-ent-16.

Инициализация кластера

Используйте команду bihactl init, чтобы инициализировать кластер и создать узел-лидер.

Выполните команду bihactl init с необходимыми параметрами:
```
bihactl init \
     --biha-node-id=1 \
     --host=узел_1 \
     --port=порт_узла \
     --biha-port=порт_biha \
     --nquorum=количество_узлов \
     --pgdata=локальный_каталог_PGDATA_лидера
```
Запускается утилита initdb, редактируются файлы postgresql.conf и pg_hba.conf.
При инициализации BiHA-кластера генерируется «магическая» строка. Об использовании «магической» строки читайте в Подразделе F.8.2.6.

Запустите СУБД:

pg_ctl start -D локальный_каталог_PGDATA_лидера -l файл_журнала_лидера

Проверьте статус узла в представлении biha.status_v:
```
SELECT * FROM biha.status_v;
```

Добавление узла-последователя

Убедитесь, что узел-лидер находится в состоянии LEADER_RO или LEADER_RW.
Убедитесь, что пароль роли biha_replication_user в файле паролей совпадает с паролем этой роли на узле-лидере.
Выполните команду bihactl add с необходимыми параметрами:
```
bihactl add \
    --biha-node-id=2 \
    --host=узел_2 \
    --port=порт_узла \
    --biha-port=порт_biha \
    --use-leader "host=узел_лидер port=порт_лидера biha-port=порт_лидера_biha" \
    --pgdata=каталог_PGDATA_последователя
```
Создаётся резервная копия узла-лидера при помощи pg_basebackup или pg_probackup в зависимости от значения, переданного в параметре --backup-method. Также редактируются файлы postgresql.conf и pg_hba.conf.
Примечание
При выполнении этого процесса все файлы копируются с лидера на новый узел. Чем больше размер базы данных, тем дольше времени требуется для добавления последователя.
Также можно добавить данные для подключения к узлу-лидеру с помощью «магической» строки. За дополнительной информацией об использовании «магической» строки обратитесь к Подразделу F.8.2.6.

Запустите СУБД:

pg_ctl start -D каталог_PGDATA_последователя -l файл_журнала_последователя

Проверьте статус узла в представлении biha.status_v:
```
SELECT * FROM biha.status_v;
```

F.8.2.3. Преобразование существующего кластера с потоковой репликацией в BiHA-кластер #

Преобразуйте существующий Postgres Pro Enterprise 16 кластер с потоковой репликацией и настроенным экземпляром базы данных в BiHA-кластер. В результате ведущий узел кластера станет лидером, а ведомые — последователями.

Предварительные требования

Если текущий кластер синхронный, то есть у него задано значение параметра synchronous_standby_names (например, synchronous_standby_names=walreceiver), выполните следующие шаги перед конвертацией в BiHA-кластер:

Сбросьте параметр synchronous_standby_names:
```
ALTER SYSTEM RESET synchronous_standby_names;
```
Из файла postgresql.conf и всех его директив включения, вручную удалите значения synchronous_standby_names.

Преобразование ведущего узла в узел-лидер

Остановите существующий ведущий узел:
```
pg_ctl stop -D каталог_PGDATA_ведущего_узла
```
Выполните команду bihactl init с параметром --convert:
```
bihactl init --convert \
    --biha-node-id=1 \
    --host=узел_1 \
    --port=порт_PostgresPro \
    --biha-port=порт_biha \
    --nquorum=количество_узлов \
    --pgdata=локальный_каталог_PGDATA_лидера
```
Во время преобразования кластера генерируется «магическая» строка. За дополнительной информацией об использовании «магической» строки обратитесь к Подразделу F.8.2.6.

Запустите СУБД:

pg_ctl start -D локальный_каталог_PGDATA_лидера -l файл_журнала_лидера

Проверьте статус узла в представлении biha.status_v:
```
SELECT * FROM biha.status_v;
```

Преобразование ведомого узла в узел-последователь

Убедитесь, что пароль роли biha_replication_user в файле паролей совпадает с паролем этой роли на узле-лидере.

Остановите ведомый узел:

pg_ctl stop -D каталог_PGDATA_ведомого_узла

Выполните команду bihactl add с параметром --convert-standby:
```
bihactl add --convert-standby \
  --biha-node-id=2 \
  --host=узел_2 \
  --port=порт_PostgresPro \
  --biha-port=5435 \
  --use-leader "host=адрес_узла_лидера port=порт_лидера biha-port=порт_лидера_biha" \
  --pgdata=каталог_PGDATA_последователя
```
При преобразовании существующего ведомого узла в узел-последователь biha создаёт файлы каталог_PGDATA_последователя/pg_biha/biha.conf и каталог_PGDATA_последователя/pg_biha/biha.state, необходимые для подключения узла к кластеру, и редактирует файлы postgresql.conf и pg_hba.conf.
Также можно добавить данные для подключения к узлу-лидеру с помощью «магической» строки. За дополнительной информацией об использовании «магической» строки обратитесь к Подразделу F.8.2.6.

Запустите СУБД:

pg_ctl start -D каталог_PGDATA_последователя -l файл_журнала_последователя

Проверьте статус узла в представлении biha.status_v:
```
SELECT * FROM biha.status_v;
```

F.8.2.4. Подготовка BiHA-кластера из существующего сервера баз данных #

Если существующий сервер Postgres Pro Enterprise 16 с настроенной базой данных состоит только из одного узла, вы можете преобразовать его в узел-лидер, а затем добавить остальные узлы в BiHA-кластер с помощью команды bihactladd.

Преобразование существующего узла в узел-лидер

Остановите узел:

pg_ctl stop -D каталог_PGDATA_лидера

Выполните команду bihactl init с параметром --convert:
```
bihactl init --convert \
    --biha-node-id=1 \
    --host=узел_1 \
    --port=порт_PostgresPro \
    --biha-port=порт_biha \
    --nquorum=количество_узлов \
    --pgdata=локальный_каталог_PGDATA_лидера
```
Редактируются файлы postgresql.conf и pg_hba.conf.
Во время преобразования узла генерируется «магическая» строка. За дополнительной информацией об использовании «магической» строки обратитесь к Подразделу F.8.2.6.

Запустите СУБД:

pg_ctl start -D локальный_каталог_PGDATA_лидера -l файл_журнала_лидера

Проверьте статус узла в представлении biha.status_v:
```
SELECT * FROM biha.status_v;
```

Добавление узла-последователя

Убедитесь, что узел-лидер находится в состоянии LEADER_RO или LEADER_RW.
Убедитесь, что пароль роли biha_replication_user в файле паролей совпадает с паролем этой роли на узле-лидере.
Выполните команду bihactl add с необходимыми параметрами:
```
 bihactl add \
     --biha-node-id=2 \
     --host=узел_2 \
     --port=порт_узла \
     --biha-port=порт_biha \
     --use-leader "host=адрес_узла_лидера port=порт_лидера biha-port=порт_biha_лидера" \
     --pgdata=каталог_PGDATA_последователя
 
```
Создаётся резервная копия узла-лидера при помощи pg_basebackup или pg_probackup в зависимости от значения, переданного в параметре --backup-method. Также редактируются файлы postgresql.conf и pg_hba.conf.
Также можно добавить данные для подключения к узлу-лидеру с помощью «магической» строки. За дополнительной информацией об использовании «магической» строки обратитесь к Подразделу F.8.2.6.

Запустите СУБД:

pg_ctl start -D каталог_PGDATA_последователя -l файл_журнала_последователя

Проверьте статус узла в представлении biha.status_v:
```
SELECT * FROM biha.status_v;
```

F.8.2.5. Подготовка узла-рефери в BiHA-кластере #

Узел-рефери участвует в выборах и помогает разрешить проблемы разделения кластера.

Примечание

При добавлении в кластер узла-рефери можно использовать только pg_basebackup.
На узел-рефери копируются только база данных biha_db и системные таблицы. База данных postgres и пользовательские данные не копируются.

Чтобы подготовить узел-рефери:

Выполните команду bihactl add с соответствующим значением параметра --mode:

bihactl add \
      --biha-node-id=3 \
      --host=узел_3 \
      --port=порт_узла \
      --biha-port=порт_biha \
      --use-leader "host=адрес_узла_лидера port=порт_лидера biha-port=порт_лидера_biha" \
      --pgdata=каталог_PGDATA_рефери \
      --mode=referee

или

bihactl add \
      --biha-node-id=3 \
      --host=узел_3 \
      --port=порт_узла \
      --biha-port=порт_biha \
      --use-leader "host=адрес_узла_лидера port=порт_лидера biha-port=порт_лидера_biha" \
      --pgdata=каталог_PGDATA_рефери \
      --mode=referee_with_wal

Запустите экземпляр Postgres Pro с настроенным узлом-рефери:
```
pg_ctl start -D каталог_PGDATA_рефери
```
Проверьте статус узла в представлении biha.status_v:
```
SELECT * FROM biha.status_v;
```

F.8.2.6. Использование «‎‎магической» строки (необязательно) #

«Магическая» строка — это специальная строка, которая автоматически генерируется при инициализации BiHA-кластера. «Магическая» строка используется в скриптах подготовки BiHA-кластера. Строка содержит данные, необходимые для подключения узлов-последователей к узлу-лидеру.

Вы можете использовать «магическую» строку, чтобы при добавлении узлов-последователей не вводить данные для подключения к узлу-лидеру вручную.

Далее приведён пример использования «магической» строки:

При инициализации кластера перенаправьте вывод bihactl в файл:

bihactl init \
   --biha-node-id=1 \
   --host=узел_1 \
   --port=порт_узла \
   --biha-port=порт_biha \
   --nquorum=количество_узлов \
   --pgdata=локальный_каталог_PGDATA_лидера > /tmp/magic-file

При добавлении узла-последователя выполните следующие действия:
1. Установите переменную окружения:
```
export MAGIC_STRING="$(cat /tmp/magic-file)"
```
2. Добавьте параметр --magic-string в bihactl add:
```
bihactl add \
    --biha-node-id=2 \
    --host=узел_2 \
    --port=порт_узла \
    --biha-port=порт_biha \
    --magic-string=$MAGIC_STRING \
    --pgdata=каталог_PGDATA_последователя
```
Узел-последователь будет использовать закодированные данные из «магической» строки для подключения к узлу-лидеру.

F.8.3. Администрирование #

F.8.3.1. Изменение состава кластера #

Состав кластера можно изменять, добавляя или удаляя узлы. Чтобы добавить узел, используйте команду bihactl add с соответствующими параметрами. Чтобы удалить узел, используйте функцию biha.remove_node. За подробным описанием процесса подготовки отказоустойчивого кластера обратитесь к Подразделу F.8.2.

F.8.3.2. Ручное переключение узлов #

В дополнение к встроенным возможностям аварийного переключения узлов, отказоустойчивый кластер в Postgres Pro позволяет переключать узлы вручную. Разница между аварийным переключением и ручным переключением узлов заключается в том, что аварийное переключение выполняется автоматически при отказе узла-лидера, а ручное переключение выполняет системный администратор. Чтобы вручную переключить узел в узел-лидер, используйте функцию biha.set_leader. При выборе нового лидера происходит следующее:

Все попытки выборов блокируются и задаётся тайм-аут.
Текущий узел-лидер становится узлом-последователем.
Выбранный узел становится новым лидером.
Если процесс ручного переключения узлов не завершается в течение установленного тайм-аута, выбранный узел становится последователем и проводятся выборы нового лидера.

F.8.3.3. Роли #

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

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

В процессе инициализации кластера также создаются слоты репликации с именем в формате biha_node_идентификатор. Управление слотами репликации выполняется автоматически без необходимости изменять или удалять их вручную.

F.8.3.4. Восстановление узла из состояния `NODE_ERROR` #

Описанные ниже ошибки, возникающие в процессах biha или экземпляра сервера, могут привести к отказу узла, то есть он не сможет перезагрузиться и WAL будет повреждён:

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

Когда узел переходит в состояние NODE_ERROR, восстановление WAL приостанавливается и процесс walreceiver завершается. Чтение с узлов в состоянии NODE_ERROR запрещено. Кроме того, сведения об ошибке сохраняются в файле biha.state и проверяются при перезапуске узла, поэтому узел перейдёт в то же состояние при запуске процесса biha-background-worker.

Чтобы восстановить узел из состояния NODE_ERROR, выполните следующие шаги:

Сохраните последние файлы из каталога pg_wal; некоторые уникальные для этого узла файлы будут перезаписаны утилитой pg_rewind.
Запустите pg_rewind с параметром --biha, чтобы сохранить конфигурационные файлы biha. При успешной синхронизации информация о состоянии NODE_ERROR удаляется из файла biha.state. Кроме того, строка подключения, указанная в параметре --source-server утилиты pg_rewind, автоматически сохраняется для параметра конфигурации primary_conninfo в файле postgresql.auto.conf. Это важно для того, чтобы узел продолжил восстанавливаться после перезапуска и достиг точки согласованности, которая представляет собой номер последней записи WAL исходного сервера на момент синхронизации.
(Необязательно) Если узел был недоступен долгое время, установите для параметра biha.flw_ro восстановленного узла значение off, чтобы предотвратить повреждение данных и чтение неактуальных данных.

F.8.3.5. Мониторинг результатов синхронизации #

Результаты синхронизации, т.е. состояние синхронизации узлов кластера, можно проверить в поле rewind_state файла biha.state. Оно содержит значения типа enum, которые интерпретируются следующим образом:

Таблица F.6. Состояние синхронизации

Значение	Интерпретация
`0`	Синхронизация не требуется.
`1`	Сервер остановлен, параметр конфигурации biha.autorewind включён, синхронизация будет выполнена после перезапуска сервера.
`2`	Синхронизация завершилась ошибкой.
`3`	Синхронизация выполнена.
`4`	Параметр конфигурации biha.autorewind не был включён, синхронизацию необходимо выполнить вручную, как описано в Подразделе F.8.3.4.

F.8.3.6. Настройка синхронной и асинхронной репликации #

Возможности встроенной отказоустойчивости в Postgres Pro позволяют создавать кластер с синхронной репликацией. Чтобы настроить синхронную репликацию, добавьте параметр --sync-standbys к команде bihactl init. При этом изменится параметр synchronous_standby_names, в нём будет прописан список всех узлов-последователей с ключевым словом ANY. Кроме того, используется параметр synchronous_commit со значением по умолчанию on. Обратите внимание, что для синхронной репликации нельзя выбрать определённые узлы, но можно задать количество узлов, которые должны работать синхронно, в параметре --sync-standbys. Для других узлов кластера данные будут реплицироваться асинхронно, так как потоковая репликация по умолчанию выполняется асинхронно. За подробностями обратитесь к Подразделу 26.2.8.

Ограничения синхронной репликации можно смягчить, чтобы лидер мог продолжать работу, пока часть последователей временно недоступна. Чтобы включить нестрогую синхронную репликацию, укажите минимальное количество последователей в параметре --sync-standbys-min. Если этот параметр задан, соответствующим образом также изменяется поле MIN в параметре synchronous_standby_names. Значение параметра synchronous_standby_gap остаётся неизменным и сохраняет своё значение по умолчанию, равное 0. Параметр --sync-standbys-min можно задать при инициализации BiHA-кластера командой bihactl init, а затем изменить его при необходимости с помощью функции biha.set_sync_standbys_min.

Есть несколько особенностей, которые необходимо учитывать при использовании синхронной репликации и узла-рефери. Если для параметра --mode установлено значение referee, рефери не участвует в синхронной репликации. Если установлено значение referee_with_wal, узел может синхронно получать данные. Этот режим позволяет кластеру оставаться доступным в конфигурации 2+1 с --sync-standbys=1, когда узел-последователь вышел из строя и узел-рефери начинает подтверждать транзакции для лидера. Поведение рефери зависит от значения параметра synchronous_commit. Обратите внимание, что если для этого параметра установлено значение remote_apply, рефери не подтверждает транзакции.

F.8.3.7. Протоколирование #

Расширение biha регистрирует сообщения, отправляемые его компонентами, то есть каналом управления и контроллером узла. Канал управления используется для обмена служебной информацией между узлами и в журнале помечается как BCP. Контроллер узла — это основной компонент biha, который отвечает за логику работы узла и помечается в журнале как NC. Можно определить типы сообщений, которые будут вноситься в журнал, установив соответствующий уровень ведения журнала. Расширение biha поддерживает как стандартные уровни важности сообщений Postgres Pro, так и уровни протоколирования самого расширения.

Уровни важности сообщений Postgres Pro используются расширением biha в следующих случаях:

Один из процессов biha завершается ошибкой (уровни ERROR и FATAL).
Один из компонентов biha не входит ни в один уровень протоколирования расширения.
Сообщения должны регистрироваться, когда протоколирование для компонентов отключено. Например, сообщения уровня LOG, отправляемые каналом управления, которые отображаются только при успешной инициализации компонента.

Уровни протоколирования biha соответствуют уровням важности сообщений Postgres Pro. Если в журнале должны появляться сообщения необходимого уровня, установленное для этого уровня значение должно соответствовать значению в log_min_messages. Уровни протоколирования расширения можно настроить, отредактировав файл postgresql.biha.conf напрямую или установив параметры конфигурации biha, которые перечислены в Подразделе F.8.4.1.2.

Например, чтобы отображать сообщения, относящиеся к каналу управления, но без отладочной информации, укажите приведённые ниже строки в файле конфигурации postgresql.biha.conf или задайте соответствующие параметры конфигурации. В этом случае предполагается, что для log_min_messages установлено значение LOG:

biha.BcpTransportLog_log_level = LOG
biha.BcpTransportWarn_log_level = LOG
biha.BcpTransportDetails_log_level = LOG

F.8.3.8. Функции-обработчики #

Обработчик — это SQL-функция, которая уведомляет пользователей или внешние сервисы о событиях в BiHA-кластере, например о выборах нового лидера или изменении конфигурации кластера. Как пользователь, вы создаёте SQL-функцию и регистрируете её в качестве обработчика. При определённых условиях biha вызовет эту функцию.

Своевременное оповещение помогает внешним службам правильно реагировать на события в BiHA-кластере. Например, при получении информации об изменении лидера прокси-сервер перенаправит трафик на нового лидера.

Доступны следующие типы обработчиков:

Таблица F.7. Типы обработчиков

Имя	Описание
`CANDIDATE_TO_LEADER`	Вызывается на узле, выбранном в качестве нового лидера. Сигнатура: my_callback(void) RETURNS void
`LEADER_TO_FOLLOWER`	Вызывается на старом лидере, который вернулся в кластер после понижения. Сигнатура: my_callback(void) RETURNS void
`LEADER_CHANGED`	Вызывается на каждом узле при смене лидера BiHA-кластера. Сигнатура: my_callback(conninfo text) RETURNS void В этой сигнатуре biha передаёт строку подключения новому лидеру.
`TERM_CHANGED`	Вызывается на узле при увеличении значения `term`. Сигнатура: my_callback(void) RETURNS void
`OFFERED_TO_LEADER`	Вызывается на узле, который был назначен лидером вручную, перед непосредственным переходом в статус лидера. Сигнатура: my_callback(void) RETURNS void

F.8.3.8.1. Особенности и ограничения #

При наступлении события функции-обработчики исполняются последовательно. В это время biha не может изменить своё состояние, например инициировать выборы.
Если исполнение функции-обработчика длится дольше, чем указано в biha.callbacks_timeout, biha останавливает исполнение и продолжает работать в обычном режиме.
На кластерах с асинхронной репликацией функция biha.register_callback не дожидается, пока обработчики появятся на всех узлах. Это может привести к ситуации, когда обработчики на лидере есть, а на последователе — нет, так как он отстаёт.

Примечание

Не вызывайте функции biha внутри обработчика, так как это может вызвать непредвиденное поведение.

F.8.3.8.2. Управление функциями-обработчиками #

Для управления функциями-обработчиками вы можете выполнять следующие действия:

зарегистрировать один или несколько обработчиков на одно событие
просмотреть список зарегистрированных обработчиков
отменить регистрацию обработчика

Регистрация функций-обработчиков

Напишите SQL-функцию и зарегистрируйте её в качестве обработчика с помощью функции biha.register_callback.

В этом примере вы создадите несколько SQL-функций на языке PL/pgSQL и зарегистрируете их в качестве обработчиков разных типов.

Убедитесь, что лидер BiHA-кластера находится в состоянии LEADER_RW.
На лидере используйте psql для подключения к базе данных biha_db:
```
postgres=# \c biha_db
```

Создайте следующие функции-обработчики:

-- запись при смене значения term
CREATE FUNCTION log_term_changed()
RETURNS void AS $$
BEGIN
    RAISE LOG 'Callback: Term changed';
END;
$$ LANGUAGE plpgsql;

-- запись при смене лидера
CREATE FUNCTION log_leader_changed(conninfo text)
RETURNS void AS $$
BEGIN
    RAISE LOG 'Callback: New leader connection string %', conninfo;
END;
$$ LANGUAGE plpgsql;

-- запись при переходе узла из лидера в последователя после переключения
CREATE FUNCTION log_leader_to_follower()
RETURNS void AS $$
BEGIN
    RAISE LOG 'Callback: demote';
END;
$$ LANGUAGE plpgsql;

Зарегистрируйте созданные функции:
```
SELECT biha.register_callback('TERM_CHANGED', 'log_term_changed', 'biha_db');

SELECT biha.register_callback('LEADER_CHANGED', 'log_leader_changed', 'biha_db');

SELECT biha.register_callback('LEADER_TO_FOLLOWER', 'log_leader_to_follower', 'biha_db');
```
Вы также можете указать пользователя, от имени которого будут исполняться функции-обработчики или определить порядок их исполнения. Подробнее читайте в описании функции biha.register_callback.

Просмотр функций-обработчиков

Зарегистрированные обработчики добавляются в таблицу biha.callbacks, которая находится в базе данных biha_db.

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

На лидере используйте psql для подключения к базе данных biha_db:
```
postgres=# \c biha_db
```

Отобразите содержимое таблицы biha.callbacks:

SELECT * FROM biha.callbacks;

1 | log_term_changed
2 | log_leader_changed
3 | log_leader_to_follower
(3 rows)

Отмена регистрации функции-обработчика

Отменённый обработчик удаляется из таблицы biha.callbacks.

Убедитесь, что лидер BiHA-кластера находится в состоянии LEADER_RW.
На лидере используйте psql для подключения к базе данных biha_db:
```
postgres=# \c biha_db
```
Получите идентификатор обработчика, который вы хотите отменить, например log_leader_changed:
```
SELECT id FROM biha.callbacks WHERE func = 'log_leader_changed';
```
Возвращается идентификатор обработчика, например 2.
Отменить регистрацию обработчиков:
```
SELECT biha.unregister_callback(2);
```
Регистрация обработчика отменена.

F.8.3.9. Восстановление из резервной копии #

Если экземпляр базы данных был восстановлен из одного из узлов кластера BiHA в отдельный узел и/или на момент времени (Point-in-Time Recovery, PITR), между восстановленным узлом и работающими узлами кластера BiHA не должно быть соединения. Чтобы предотвратить соединение, выполните следующие действия на восстановленном узле перед его запуском:

Удалите директиву включения include 'postgresql.biha.conf' из файла конфигурации postgresql.conf.
Убедитесь, что расширение biha отсутствует в shared_preload_libraries конфигурационного файла postgresql.conf.

Если вы хотите добавить восстановленный узел в кластер, выполните следующие действия:

На восстановленном узле вручную настройте потоковую репликацию от лидера.
Синхронизируйте восстановленный узел с лидером.

Остановите восстановленный узел:

pg_ctl stop -D каталог_PGDATA_восстановленного узла

Добавьте восстановленный узел в кластер с помощью команды bihactl add с параметром --convert-standby.

Запустите восстановленный узел:

pg_ctl start -D каталог_PGDATA_восстановленного узла

F.8.3.10. Миграция #

В зависимости от текущей и целевой версии Postgres Pro Enterprise, можно обновить BiHA-кластер в состоянии LEADER_RO или LEADER_RW.

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

F.8.3.10.1. Миграция BiHA-кластера на версию 16.6 #

Процесс миграции на версию 16.6 зависит от текущей версии Postgres Pro Enterprise:

чтобы обновиться с версии 16.4 на версию 16.6, используйте инструкцию, описанную в Подразделе F.8.3.10.4
чтобы обновиться с версии 16.3 и ниже на версию 16.6, используйте инструкцию, описанную в Подразделе F.8.3.10.5

F.8.3.10.2. Миграция BiHA-кластера на версию 16.4 #

Чтобы обновить BiHA-кластер с версии Postgres Pro Enterprise 16.3 и ниже до версии 16.4, используйте инструкцию, описанную в Подразделе F.8.3.10.5.

F.8.3.10.3. Миграция BiHA-кластера на версию 16.3 #

Чтобы обновить BiHA-кластер с версий Postgres Pro Enterprise 16.1 и 16.2 до 16.3, используйте инструкцию, описанную в Подразделе F.8.3.10.4.

F.8.3.10.4. Миграция BiHA-кластера в состоянии `LEADER_RW` #

Используйте эту инструкцию для следующих вариантов миграции:

с версии 16.4 на версию 16.6
с версий 16.1 и 16.2 на версию 16.3

Выполните следующие шаги:

Остановите одного из последователей с помощью команды pg_ctl.
Обновите последователя.
Запустите последователя с помощью команды pg_ctl.
Повысьте обновлённого последователя до лидера с помощью функции biha.set_leader.
Остановите, обновите и запустите остальных последователей и старого лидера.
Повысьте старого лидера с помощью функции biha.set_leader.

Важно

Обратите внимание, что если узел с версией Postgres Pro Enterprise 16.1 переходит в состояние NODE_ERROR, узлы с более новыми версиями могут некорректно определять состояние такого узла, например как REFEREE. В этом случае рекомендуется остановить узел, обновить его версию, синхронизировать его с помощью pg_rewind и вновь запустить.

F.8.3.10.5. Миграция BiHA-кластера в состоянии `LEADER_RO` #

Используйте эту инструкцию для следующих вариантов миграции:

с версий 16.1, 16.2 и 16.3 на версию 16.6
с версий 16.1, 16.2 и 16.3 на версию 16.4

С помощью функции biha.set_nquorum_and_minnodes установите для параметров nquorum и minnodes значения больше, чем количество узлов в кластере.
Например, если кластер состоит из 3 узлов, установите для вышеуказанных параметров значение 4. Это необходимо, чтобы избежать неожиданных выборов лидера и изменить состояние лидера с LEADER_RW на LEADER_RO.
Дождитесь, пока последователи нагонят лидера, и убедитесь, что столбец replay_lag в представлении pg_stat_replication содержит NULL.
Остановите одного из последователей с помощью команды pg_ctl.
Обновите последователя.
Запустите последователя с помощью команды pg_ctl.
Повысьте обновлённого последователя до лидера с помощью функции biha.set_leader.
Остановите, обновите и запустите остальных последователей и старого лидера.
Повысьте старого лидера с помощью функции biha.set_leader.
С помощью функции biha.set_nquorum_and_minnodes установите для параметров nquorum и minnodes те значения, которые были установлены до начала обновления Postgres Pro Enterprise.

Важно

F.8.3.11. Удаление расширения biha #

Вы можете временно выключить или навсегда удалить расширение biha.

Чтобы выключить расширение biha:

Удалите директиву включения include 'postgresql.biha.conf' из файла конфигурации postgresql.conf.
Убедитесь, что расширение biha отсутствует в shared_preload_libraries конфигурационного файла postgresql.conf.

Чтобы навсегда удалить расширение, дополнительно выполните следующие действия:

Выполните команду DROP EXTENSION. Её необходимо выполнить на лидере в состоянии LEADER_RW и из базы данных biha_db:
```
biha_db=# DROP EXTENSION biha;
```

F.8.4. Справка #

F.8.4.1. Параметры конфигурации #

Расширение biha поддерживает несколько конфигурационных параметров, специфичных для BiHA-кластера. Помимо этого, biha использует следующие параметры Postgres Pro:

Параметры, которые автоматически задаются при запуске BiHA-кластера: listen_addresses, порт, shared_preload_libraries, wal_keep_size.
Параметры, которые biha использует со значениями по умолчанию: hot_standby, max_replication_slots, max_slot_wal_keep_size, max_wal_senders, wal_level.
Параметры, которые изменяются и управляются только расширением biha: primary_conninfo, primary_slot_name, synchronous_standby_names.
Когда расширение biha загружено и настроено, эти параметры нельзя изменить с помощью ALTER SYSTEM. Подробнее читайте в Подразделе F.8.2.1.

F.8.4.1.1. Конфигурирование кластера #

Важно

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

biha.autorewind (boolean) #

Необязательный параметр, который управляет политикой автоматической синхронизации для узла, в отношению которого должен быть выполнен pg_rewind. Например, для старого лидера при его синхронизации с новым лидером. При значении по умолчанию — false — автоматическая синхронизация не выполняется. Если установлено значение true, автоматическая синхронизация выполняется после ошибки, которая обычно приводит к переходу узла в состояние NODE_ERROR. Автоматическая синхронизация выполняется, если она может успешно завершиться, то есть предварительный запуск pg_rewind с параметром --dry-run прошёл успешно. При неудачной автоматической синхронизации узел переходит в состояние NODE_ERROR. В этом случае фактическое состояние синхронизации узла можно найти в файле biha.state, как описано в Подразделе F.8.3.5. Обратите внимание, что синхронизация может привести к потере некоторых записей WAL узла.

biha.callbacks_timeout (integer) #

Задаёт время исполнения всех функций-обработчиков для одного события в миллисекундах. Значение по умолчанию — 10000 (10 секунд). Минимальное значение — 1000 (1 секунда).

Значение параметра biha.callbacks_timeout может различаться для разных узлов. Изменение параметра на лидере не изменяет его на последователях.

biha.can_be_leader (boolean) #

Определяет возможность узла стать лидером. Значение по умолчанию — true. Если задано значение false, узел не может предлагать себя в качестве кандидата на выборах лидера.

Самый большой объём WAL может быть на том узле, который не может стать лидером. В этой ситуации при необходимости выборов другие узлы, которые могут предлагать себя в качестве кандидатов в лидеры, попытаются получить недостающие данные с этого узла. В случае успеха один из этих узлов станет лидером. Если данные получить не удалось, на узле, который не может стать лидером, запустится процесс автоматической синхронизации. Если параметр biha.autorewind не включён, состояние этого узла изменится на NODE_ERROR.

biha.can_vote (boolean) #

Определяет возможность узла голосовать. Значение по умолчанию — true. Если задать значение false, узел не сможет принимать участие в голосовании, а также не сможет предлагать себя в качестве кандидата в лидеры.

biha.flw_ro (boolean) #

Определяет доступность последователя для операций на чтение. Если задано значение off, чтение с этого последователя запрещено. Значение по умолчанию — on.

biha.heartbeat_max_lost (integer) #

Указывает максимальное число сообщений о контроле состояния, которые можно не получить до того, как узел будет считаться недоступным. Этот параметр может задаваться функцией biha.set_heartbeat_max_lost. Значение по умолчанию — 10.

biha.heartbeat_send_period (integer) #

Указывает частоту отправки сообщений о контроле состояния в миллисекундах. Этот параметр может задаваться функцией biha.set_heartbeat_send_period. Значение по умолчанию — 1000.

biha.host (text) #

Указывает адрес узла кластера. Этот параметр уникален для каждого узла. Для первого узла он задаётся при инициализации кластера, для остальных узлов — при добавлении к кластеру. Этот параметр не рекомендуется изменять.

biha.id (integer) #

Указывает идентификатор узла отказоустойчивого кластера. Этот параметр уникален для каждого узла. Для первого узла он задаётся при инициализации кластера, для остальных узлов — при добавлении к кластеру. Этот параметр не рекомендуется изменять.

biha.minnodes (integer) #

Указывает минимальное число работающих узлов, при котором лидер будет открыт для пишущих транзакций. Этот параметр может быть задан с помощью функции biha.set_minnodes. Если не задать параметр --minnodes в команде bihactl init, значение biha.minnodes будет равно значению biha.nquorum.

Устанавливая это значение, принимайте во внимания возможный риск разделения кластера. Рекомендуется использовать следующую формулу: (общее количество узлов + 1)/2. Например, если в кластере 3 узла, значение minnodes должно быть 2.

Если на узле для параметра biha.can_vote установлено значение false, такой узел игнорируется.

biha.no_wal_on_follower (integer) #

Указывает тайм-аут продвижения слота репликации в миллисекундах. Этот параметр может задаваться функцией biha.set_no_wal_on_follower. Значение по умолчанию — 20000.

При достижении тайм-аута на последователе лидер замечает, что последователь не получает WAL. Если при этом превышается значение biha.heartbeat_max_lost *biha.heartbeat_send_period, лидер станет считать последователя недоступным.

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

biha.node_priority (integer) #

Устанавливает приоритет узла в синхронном кластере в секундах. Значение определяет тайм-аут, по достижении которого узел предложит себя в качестве кандидата на выборах. Нулевое значение означает самый высокий приоритет. Значение по умолчанию — -1, что означает, что параметр игнорируется.

Кластер считается синхронным, если все его узлы синхронны, то есть все узлы кластера перечислены в параметре synchronous_standby_names. В асинхронных кластерах параметр игнорируется.

biha.nquorum (integer) #

Указывает число узлов, которые должны проголосовать за нового лидера при отказе текущего лидера. Этот параметр можно задать с помощью функции biha.set_nquorum.

Если на узле для параметра biha.can_vote установлено значение false, такой узел игнорируется.

biha.port (integer) #

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

biha.sync_standbys_min (integer) #

Задаёт минимальное количество синхронных последователей, которые должны быть доступны, чтобы лидер продолжал работу. Параметр можно задать с помощью функции biha.set_sync_standbys_min. Значение должно быть ниже, чем --sync-standbys, и не может быть отрицательным. Значение по умолчанию — -1, что означает, что параметр игнорируется. Если параметр не задан, BiHA-кластер работает в соответствии с ограничениями синхронной репликации по умолчанию, то есть лидер будет оставаться недоступным для операций на запись, пока все последователи не догонят его текущее состояние.

Примечание

И параметр biha.sync_standbys_min, и функция biha.set_sync_standbys_min будут работать, только если при инициализации BiHA-кластера командой bihactl init был задан параметр --sync-standbys-min.

F.8.4.1.2. Уровни протоколирования biha #

biha.BihaLog_log_level (enum) #: Задаёт уровень протоколирования для предоставления общей информации о работе компонентов biha. Значение по умолчанию — LOG.
biha.BcpTransportDebug_log_level (enum) #: Задаёт уровень протоколирования для предоставления отладочной информации о работе канала управления. Значение по умолчанию — DEBUG4.
biha.BcpTransportDetails_log_level (enum) #: Задаёт уровень протоколирования для предоставления подробной информации о работе канала управления. Значение по умолчанию — DEBUG4.
biha.BcpTransportLog_log_level (enum) #: Задаёт уровень протоколирования для предоставления общей информации о работе канала управления. Значение по умолчанию — DEBUG4.
biha.BcpTransportWarn_log_level (enum) #: Задаёт уровень протоколирования для вывода предупреждений о возможных проблемах в канале управления. Значение по умолчанию — DEBUG4.
biha.NodeControllerDebug_log_level (enum) #: Задаёт уровень протоколирования для предоставления отладочной информации о работе контроллера узла. Значение по умолчанию — DEBUG4.
biha.NodeControllerDetails_log_level (enum) #: Задаёт уровень протоколирования для предоставления подробной информации о работе контроллера узла. Значение по умолчанию — DEBUG4.
biha.NodeControllerLog_log_level (enum) #: Задаёт уровень протоколирования для предоставления общей информации о работе контроллера узла. Значение по умолчанию — DEBUG4.
biha.NodeControllerWarn_log_level (enum) #: Задаёт уровень протоколирования для вывода предупреждений о возможных проблемах в контроллере узла. Значение по умолчанию — DEBUG4.

F.8.4.2. Функции #

Все перечисленные ниже функции следует вызывать из базы данных biha_db, например:

psql biha_db -c "select biha.set_leader(2)"

F.8.4.2.1. Генерирование «‎‎магической» строки #

biha.get_magic_string () returns string #: Генерирует «‎‎магическую» строку для узла кластера.

F.8.4.2.2. Удаление узла кластера #

biha.remove_node (id integer) returns boolean #: Удаляет узел из кластера. Перед удалением узел необходимо остановить. Данную функцию можно вызвать только на узле-лидере.

F.8.4.2.3. Установка лидера вручную #

biha.set_leader (id integer) returns boolean #: Устанавливает лидера вручную. Рекомендуется вызывать эту функцию на том узле, который вы собираетесь сделать лидером.
Примечание
Не рекомендуется вызывать функцию biha.set_leader на текущем лидере. Если вызвать функцию на текущем лидере в состоянии LEADER_RW, в случае успешного запроса на переключение может случиться так, что результат запроса не успеет отправиться клиенту до начала перезагрузки текущего лидера для понижения.

F.8.4.2.4. Конфигурирование кластера #

biha.config () returns setof record #: Возвращает значения конфигурации кластера: id, term, nquorum, minnodes, heartbeat_send_period, heartbeat_max_lost, no_wal_on_follower, sync_standbys_min, priority, can_be_leader, can_vote.
biha.set_heartbeat_max_lost (integer) returns boolean #: Задаёт значение параметра biha.heartbeat_max_lost. Эту функцию можно вызвать только с лидера, при этом она изменяет параметр на всех узлах. Чтобы изменения вступили в силу, перезапуск кластера не требуется.
biha.set_heartbeat_send_period (integer) returns boolean #: Задаёт значение параметра biha.heartbeat_send_period в миллисекундах. Эту функцию можно вызвать только с лидера, при этом она изменяет параметр на всех узлах. Чтобы изменения вступили в силу, перезапуск кластера не требуется.
biha.set_no_wal_on_follower (integer) returns boolean #: Задаёт значение параметра biha.no_wal_on_follower в миллисекундах. Эту функцию можно вызвать только с лидера, при этом она изменяет параметр на всех узлах. Чтобы изменения вступили в силу, перезапуск кластера не требуется.
biha.set_minnodes (integer) returns boolean #: Задаёт значение параметра biha.minnodes в миллисекундах. Эту функцию можно вызвать только с лидера, при этом она изменяет параметр на всех узлах. Чтобы изменения вступили в силу, перезапуск кластера не требуется.
biha.set_nquorum (integer) returns boolean #: Задаёт значение параметра biha.nquorum. Эту функцию можно вызвать только с лидера, при этом она изменяет параметр на всех узлах. Чтобы изменения вступили в силу, перезапуск кластера не требуется.
biha.set_nquorum_and_minnodes (integer, integer) returns boolean #: Задаёт значения параметров biha.nquorum и biha.minnodes. Эту функцию можно вызвать только с лидера, при этом она изменяет параметры на всех узлах. Чтобы изменения вступили в силу, перезапуск кластера не требуется.
biha.set_sync_standbys_min (integer) returns boolean #: Задаёт значение параметра biha.sync_standbys_min и, если необходимо, соответствующим образом изменяет поле MIN параметра synchronous_standby_names. Эту функцию можно вызвать только с лидера, при этом она изменяет параметр на всех узлах. Чтобы изменения вступили в силу, перезапуск кластера не требуется.
Примечание
И параметр biha.sync_standbys_min, и функция biha.set_sync_standbys_min будут работать, если при инициализации BiHA-кластера командой bihactl init был задан параметр --sync-standbys-min.

F.8.4.2.5. Мониторинг кластера #

biha.nodes () returns setof record #: Определяет представление biha.nodes_v, подробно описанное в biha.nodes_v.
biha.status () returns setof record #: Определяет представление biha.status_v, подробно описанное в biha.status_v. Если узел не отвечает при попытке показать представление, попробуйте выполнить тот же запрос на любом другом узле, чтобы узнать фактическое состояние узлов кластера.

F.8.4.2.6. Состояние `NODE_ERROR` #

biha.error_details () returns setof record #: Возвращает описание причины, по которой узел перешёл в состояние NODE_ERROR. Возвращаемая запись содержит тип ошибки, подробную информацию о ней, место возникновения с указанием begin_lsn, end_lsn и идентификаторов текущей и следующей линии времени, а также replay_lsn.

F.8.4.2.7. Управление функциями-обработчиками #

biha.register_callback (type text, func text, database text, executor text, priority integer) returns integer #

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

Примечание

Со стороны biha нет проверки наличия функции func в базе данных database. Если указанная функция не существует, исполнение обработчика завершится ошибкой.

Пример использования biha.register_callback см. в Регистрация функций-обработчиков.

Таблица F.8. Определения переменных

Имя	Тип	Описание
`type`	text	Тип обработчика. Подробнее о доступных типах обработчиков читайте в Типы обработчиков.
`func`	text	Название SQL-функции, которую расширение biha исполняет при наступлении события `type`. Функция должна находиться в базе данных `database`, иначе она не будет исполнена.
`database`	text	База данных, в которой исполняется функция `func`.
`executor`	text	Пользователь, от имени которого исполняется функция `func`. Это необязательный параметр. Значение по умолчанию — `biha_replication_user`.
`priority`	integer	Чем ниже значение, тем раньше исполнится обработчик. Это необязательный параметр. Значение по умолчанию — `0`.

biha.unregister_callback(callback_id) #

Удаляет обработчик. Функцию можно вызвать только на лидере в состоянии LEADER_RW. Пример использования функции biha.unregister_callback см. в разделе Отмена регистрации функции-обработчика.

F.8.4.3. Представления #

F.8.4.3.1. `biha.nodes_v` #

В этом представлении показывается состояние подключения узлов в кластере. Для узла, на котором выполняется запрос для представления, следующие столбцы содержат NULL: state, since_conn_start, conn_count.

Таблица F.9. Представление biha.nodes_v

Имя столбца	Описание
`id`	Идентификатор узла.
`host`	Адрес узла.
`port`	Порт узла.
`state`	Состояние подключения узла. В этом столбце может отображаться одно из следующих значений: `ACTIVE`, `CONNECTING`, `IDLE` или `INIT`.
`since_conn_start`	Время, прошедшее с момента подключения узла к сети.
`conn_count`	Сколько раз узел подключался к сети с момента запуска кластера.

F.8.4.3.2. `biha.status_v` #

В этом представлении показывается состояние узлов в кластере.

Таблица F.10. Представление biha.status_v

Имя столбца	Описание
`id`	Идентификатор узла.
`leader_id`	Идентификатор узла-лидера.
`term`	Поколение узла. Используется при голосовании по выбору нового узла-лидера.
`online`	Показывает подключён ли узел к сети.
`state`	Состояние узла. В этом столбце может отображаться одно из следующих значений: `PRESTARTUP` — начальное состояние узла при запуске BiHA-кластера. Узел отправляет сообщения о контроле состояния и запускает pg_rewind, если это было запланировано. В других случаях узел переходит в состояние `STARTUP`. `STARTUP` — узел ожидает, пока процесс запуска Postgres Pro достигнет точки согласованности. `CSTATE_FORMING` — узел получает и отправляет сообщения о контроле состояния, чтобы определить, в какое состояние он должен перейти. `LEADER_RO` — узел является лидером, доступным только для операций чтения. `LEADER_RW` — узел является лидером, доступным для операций на чтение и запись. `FOLLOWER` — узел является последователем, т.е. репликой лидера. Если biha.can_be_leader и biha.can_vote имеют значение `true`, последователь может быть избран новым лидером. `FOLLOWER_OFFERED` — узел был вручную назначен новым лидером с помощью функции biha.set_leader. `CANDIDATE` — узел предложил себя в качестве кандидата на выборах нового лидера. `REFEREE` — узел является рефери кластера. Это единое состояние для режимов `referee` и `referee_with_wal`. `NODE_ERROR` — узел в нерабочем состоянии из-за ошибки. Когда узел в состоянии `NODE_ERROR`, чтение с этого узла запрещено. Чтобы получить больше информации об ошибке, используйте функцию biha.error_details. Чтобы восстановить дефектный узел, см. Подраздел F.8.3.4. `UNKNOWN` — узел недоступен для текущего узла.
`last_known_state`	Последнее известное состояние узла.
`since_last_hb`	Время, прошедшее с момента получения последнего сообщения о контроле состояния.

Пред.	Наверх	След.
F.7. basic_archive — пример модуля архивирования WAL	Начало	F.9. bloom — индексный метод доступа, основанный на фильтрах Блума

Вход в личный кабинет

Восстановление пароля

Подтверждение аккаунта

Изменение пароля

F.8. biha — встроенный отказоустойчивый кластер #

F.8.1. Архитектура #

F.8.1.1. Варианты конфигурации кластера #

Примечание

Примечание

F.8.1.2. Выборы #

F.8.1.3. Узел-рефери в BiHA-кластере #

F.8.2. Подготовка BiHA-кластера #

F.8.2.1. Предварительные требования и особенности #

F.8.2.2. Подготовка BiHA-кластера с нуля #

Примечание

F.8.2.3. Преобразование существующего кластера с потоковой репликацией в BiHA-кластер #

F.8.2.4. Подготовка BiHA-кластера из существующего сервера баз данных #

F.8.2.5. Подготовка узла-рефери в BiHA-кластере #

Примечание

F.8.2.6. Использование «‎‎магической» строки (необязательно) #

F.8.3. Администрирование #

F.8.3.1. Изменение состава кластера #

F.8.3.2. Ручное переключение узлов #

F.8.3.3. Роли #

F.8.3.4. Восстановление узла из состояния NODE_ERROR #

F.8.3.5. Мониторинг результатов синхронизации #

F.8.3.6. Настройка синхронной и асинхронной репликации #

F.8.3.7. Протоколирование #

F.8.3.8. Функции-обработчики #

F.8.3.8.1. Особенности и ограничения #

Примечание

F.8.3.8.2. Управление функциями-обработчиками #

F.8.3.9. Восстановление из резервной копии #

F.8.3.10. Миграция #

F.8.3.10.1. Миграция BiHA-кластера на версию 16.6 #

F.8.3.10.2. Миграция BiHA-кластера на версию 16.4 #

F.8.3.10.3. Миграция BiHA-кластера на версию 16.3 #

F.8.3.10.4. Миграция BiHA-кластера в состоянии LEADER_RW #

Важно

F.8.3.10.5. Миграция BiHA-кластера в состоянии LEADER_RO #

Важно

F.8.3.11. Удаление расширения biha #

F.8.4. Справка #

F.8.4.1. Параметры конфигурации #

F.8.4.1.1. Конфигурирование кластера #

Важно

Примечание

F.8.4.1.2. Уровни протоколирования biha #

F.8.4.2. Функции #

F.8.4.2.1. Генерирование «‎‎магической» строки #

F.8.4.2.2. Удаление узла кластера #

F.8.4.2.3. Установка лидера вручную #

Примечание

F.8.4.2.4. Конфигурирование кластера #

Примечание

F.8.4.2.5. Мониторинг кластера #

F.8.4.2.6. Состояние NODE_ERROR #

F.8.4.2.7. Управление функциями-обработчиками #

Примечание

F.8.4.3. Представления #

F.8.4.3.1. biha.nodes_v #

F.8.4.3.2. biha.status_v #

F.8.3.4. Восстановление узла из состояния `NODE_ERROR` #

F.8.3.10.4. Миграция BiHA-кластера в состоянии `LEADER_RW` #

F.8.3.10.5. Миграция BiHA-кластера в состоянии `LEADER_RO` #

F.8.4.2.6. Состояние `NODE_ERROR` #

F.8.4.3.1. `biha.nodes_v` #

F.8.4.3.2. `biha.status_v` #