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. Подготовка отказоустойчивого кластера
F.8.3. Администрирование
F.8.4. Справка

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

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

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

F.8.1. Обзор #

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

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

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

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

Отказ узла-лидера. В этом случае статус узла-последователя повышается, и он становится новым лидером кластера. Это может произойти либо автоматически посредством выборов, либо это можно сделать вручную при помощи функции biha.set_leader. При выборах лидером кластера становится узел-последователь с наибольшим числом записей в WAL. Выборы проводятся с учётом значения кворума кластера, то есть минимального числа узлов, участвующих в голосовании. Значение кворума задаётся при инициализации кластера командой bihactl init в параметре nquorum. Например, в случае отказа одного узла-последователя в кластере из трёх узлов, где nquorum=2, узел-лидер продолжит работать. При отказе лидера в таком кластере два оставшихся последователя начнут выборы. После избрания нового лидера значение поколения кластера term увеличивается на единицу для всех узлов, то есть для нового лидера и оставшихся последователей значение будет term=2, а для старого лидера оно останется как term=1. Поэтому при возвращении старого лидера в кластер он станет последователем. После избрания нового лидера последователи начинают получать файлы WAL от этого узла. Обратите внимание, что старый лидер не может быть открыт для пишущих транзакций после избрания нового лидера, чтобы избежать проблем разделения кластера. После восстановления старого лидера следует либо пересоздать кластер с этим лидером, либо синхронизировать его с новым лидером при помощи pg_rewind. Механизмы кворума и поколения реализованы в biha на базе алгоритма консенсуса Raft.
Отказ узла-последователя. Если последователь настроен как асинхронный, отказ никак не отразится на лидере. Если для последователя используется синхронная репликация, отказ приведёт к остановке транзакции на лидере, так как он перестанет получать подтверждение транзакций от последователя и транзакция не сможет завершиться. Подробное описание того, как настроить синхронную репликацию в кластере biha, находится в Подразделе F.8.3.7.
Сбой соединения между узлом-лидером и узлом-последователем. В этом случае лидер не может отправить, а последователь не может получить данные. Обратите внимание, что если пользователи подключены к лидеру, разрешать пишущие транзакции на последователе нельзя. Любые изменения, сделанные на последователях, нельзя будет восстановить на лидере. Чтобы избежать потери изменений, настраивайте сеть с резервными каналами. Лучше всего настроить свой канал передачи данных для каждого последователя, чтобы предупредить проблемы, связанные с единой точкой отказа.

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

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

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

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

Три и более узлов. Ниже представлены возможные сценарии при отказе лидера или сбое соединения:
- В результате аварийного переключения узлов новый лидер выбирается простым большинством голосов.
- При сбоях соединения кластер может разделиться на несколько групп узлов. В этом случае новый лидер выбирается в группе с наибольшим числом узлов. После восстановления соединения проходят выборы между старым и новоизбранным лидером в зависимости от значения term поколения кластера. Кроме того, если значение nquorum равняется значению minnodes, старый лидер становится доступным только для чтения.
Кроме того, узел-лидер можно задать вручную при помощи функции biha.set_leader.
Два узла, из которых один лидер, а второй последователь. Ниже представлены возможные сценарии при отказе лидера или сбое соединения:
- Последователь становится новым лидером. Когда последователь «не видит» лидера из-за сбоя соединения и оба параметра конфигурации biha.nquorum и biha.minnodes имеют значение 1, кластер может разделиться из-за наличия двух лидеров, доступных для чтения и записи. Если для biha.minnodes установлено значение 2, лидер становится доступен только для чтения. Подобных проблем позволяет избежать узел-рефери.
- При сбое соединения ничего не происходит. В этом случае последователь не станет новым лидером.
Кроме того, узел-лидер можно задать вручную при помощи функции biha.set_leader.
Один узел-лидер. Вариант, который может использоваться пока не будут настроены последователи. Логично, что узел нельзя заменить при сбое ввиду отсутствия последователей, которые могут стать лидером.
Два обычных узла и один рефери — узел, который голосует во время выборов нового лидера в отказоустойчивом кластере 2+1. За дополнительной информацией об узле-рефери обратитесь к Подразделу F.8.3.3.

F.8.2. Подготовка отказоустойчивого кластера #

Подготовка кластера biha выполняется при помощи утилиты bihactl несколькими способами:

Добавление узла-лидера и узлов-последователей с нуля.
Преобразование существующего узла в узел-лидер и добавление узлов-последователей.
Преобразование существующих узлов в узел-лидер и узлы-последователи.

При инициализации отказоустойчивого кластера расширение 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"

Примечание

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

Во время инициализации кластера расширение biha конфигурирует Postgres Pro и создаёт свои служебные файлы внутри каталога данных кластера. Во время работы кластера конфигурация Postgres Pro и служебные файлы редактируются динамически. Для этого используется стандартный механизм ALTER SYSTEM, который редактирует файл postgresql.auto.conf и перечитывает конфигурацию подобно вызову SQL-функции pg_reload_conf(). В этом случае изменяются два параметра, primary_conninfo и primary_slot_name, которые необходимы для автоматического управления репликацией в отказоустойчивом кластере. Если изменить другие параметры и не перечитать конфигурацию, эти изменённые параметры могут быть неожиданно перечитаны.

В некоторых операционных системах управление сеансами пользователей может осуществляется менеджером служб systemd. В этом случае, если сервер запущен с использованием pg_ctl и управляется удалённо, имейте в виду, что при завершении SSH-сеанса все фоновые процессы, инициированные в нём, будут также завершены демоном systemd. Чтобы избежать такого поведения:

Воспользуйтесь файлом службы postgrespro-ent-16 менеджера systemd для запуска сервера СУБД на узле кластера, либо
Измените конфигурацию службы управления сеансами пользователей systemd-logind в файле /etc/systemd/logind.conf, а именно установите значение no для параметра KillUserProcesses.

F.8.2.1. Подготовка отказоустойчивого кластера с нуля #

Чтобы подготовить встроенный отказоустойчивый кластер с нуля, необходимо сначала установить Postgres Pro на всех узлах кластера, в частности пакеты postgrespro-ent-16-contrib и pg-probackup-ent-16 для использования pg_probackup с расширением biha. После установки Postgres Pro выполните следующие команды, чтобы подготовить кластер: bihactl init и bihactl add. Кластер конфигурируется автоматически при выполнении вышеуказанных команд, но необходимо указать некоторые связанные с кластером параметры. Обратите внимание, что для подключения узла-последователя к узлу-лидеру необходимо, чтобы в файле паролей был указан пароль.

Для подготовки кластера выполните следующие шаги:

Инициализируйте кластер и создайте узел-лидер.
1. Выполните команду bihactl init с необходимыми параметрами, как показано ниже. На этом этапе bihactl в интерактивном режиме запрашивает пароль для роли biha_replication_user, который будет использоваться для подключения узла-последователя к узлу-лидеру на следующем этапе:
```
bihactl init \
    --biha-node-id=1 \
    --host=узел_1 \
    --port=5432 \
    --biha-port=5433 \
    --nquorum=2 \
    --minnodes=2 \
    --pgdata=локальный_каталог_PGDATA_лидера > /tmp/magic-file
```
  В этом случае запускается утилита initdb, редактируются файлы postgresql.conf и pg_hba.conf, а также создаётся специальная строка, которая называется «‎‎магической» и содержит данные для подключения узлов-последователей к узлу-лидеру на следующем этапе.
  Сохраните «‎‎магическую» строку, она может понадобиться при добавлении узла-последователя на следующем этапе:
```
export MAGIC_STRING="$(cat /tmp/magic-file)"
```
2. Выполните следующую команду, чтобы запустить СУБД:
```
pg_ctl start -D локальный_каталог_PGDATA_лидера -l файл_журнала_лидера
```
Добавьте узел-последователь.
1. Отредактируйте файл паролей, указав в нём пароль для роли biha_replication_user. Это необходимо для подключения узла-последователя к узлу-лидеру.
2. Выполните команду bihactl add с необходимыми параметрами.
```
bihactl add \
    --biha-node-id=2 \
    --host=узел_2 \
    --port=5434 \
    --biha-port=5435 \
    --use-leader "host=адрес_узла_лидера port=порт_лидера biha-port=порт_biha_лидера" \
    --pgdata=каталог_PGDATA_последователя
```
  Узел-последователь можно также добавить с использованием «‎‎магической» строки:
```
bihactl add \
    --biha-node-id=2 \
    --host=узел_2 \
    --port=5434 \
    --biha-port=5435 \
    --magic-string=магическая_строка \
    --pgdata=каталог_PGDATA_последователя
```
  В этом случае создаётся резервная копия узла-лидера при помощи pg_basebackup или pg_probackup в зависимости от значения, переданного в параметре --backup-method. Также редактируются файлы postgresql.conf и pg_hba.conf.
3. Выполните следующую команду, чтобы запустить СУБД:
```
pg_ctl start -D каталог_PGDATA_последователя -l файл_журнала_последователя
```

F.8.2.2. Подготовка отказоустойчивого кластера из существующих узлов #

Чтобы подготовить встроенный отказоустойчивый кластер из существующих узлов, выполните следующие команды: bihactl init с параметром --convert и bihactl add, если есть только ведущий узел и нужно сделать его лидером и добавить новые узлы с нуля, или bihactl init с параметром --convert и bihactl add с параметром --convert-standby, если нужно преобразовать ведущий узел в узел-лидер, а ведомые — в узлы-последователи кластера. Кластер конфигурируется автоматически при выполнении вышеуказанных команд, но необходимо указать некоторые связанные с кластером параметры. Обратите внимание, что для подключения узла-последователя к узлу-лидеру необходимо, чтобы в файле паролей был указан пароль.

Для подготовки кластера выполните следующие шаги:

Преобразуйте существующий узел в узел-лидер.
1. Остановите существующий узел перед преобразованием в узел-лидер:
```
pg_ctl stop -D каталог_PGDATA_лидера
```
2. Выполните команду bihactl init с параметром --convert. На этом этапе bihactl в интерактивном режиме запрашивает пароль для роли biha_replication_user, который будет использоваться для подключения узла-последователя к узлу-лидеру на следующем этапе:
```
bihactl init --convert \
    --biha-node-id=1 \
    --host=узел_1 \
    --port=порт_PostgresPro \
    --biha-port=5433 \
    --nquorum=2 \
    --minnodes=2 \
    --pgdata=локальный_каталог_PGDATA_лидера > magic-file
```
  В этом случае редактируются файлы postgresql.conf и pg_hba.conf и создаётся «‎‎магическая» строка, содержащая данные для подключения узлов-последователей к узлу-лидеру на следующем этапе.
  Сохраните «‎‎магическую» строку, она может понадобиться при добавлении узла-последователя на следующем этапе:
```
export MAGIC_STRING="$(cat magic-file)"
```
3. Выполните следующую команду, чтобы запустить СУБД:
```
pg_ctl start -D локальный_каталог_PGDATA_лидера -l файл_журнала_лидера
```
Добавьте узел-последователь.
1. Узел-последователь может быть добавлен двумя способами. Прежде чем перейти к одному из следующих шагов, отредактируйте файл паролей, указав в нём пароль для роли biha_replication_user. Это необходимо для подключения узла-последователя к узлу-лидеру:
  1. Остановите существующий узел перед преобразованием в узел-последователь:
    pg_ctl stop -D каталог_PGDATA_последователя
  2. Выполните команду 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_последователя
  3. Выполните команду bihactl add с дополнительными параметрами, чтобы добавить новый узел-последователь с нуля.
  При преобразовании существующего узла в узел-последователь biha создаёт файлы каталог_PGDATA_последователя/pg_biha/biha.conf и каталог_PGDATA_последователя/pg_biha/biha.state, необходимые для подключения узла к кластеру, и редактирует файлы postgresql.conf и pg_hba.conf.
2. Выполните следующую команду, чтобы запустить СУБД:
```
pg_ctl start -D каталог_PGDATA_последователя -l файл_журнала_последователя
```

F.8.2.3. Управление узлом-рефери в отказоустойчивом кластере #

Если кластер состоит из двух узлов, то есть узла-лидера и одного узла-последователя, можно настроить отказоустойчивый кластер 2+1, добавив узел-рефери. Для этого выполните следующие шаги:

Выполните команду bihactl add с соответствующим значением параметра --mode:
```
bihactl add --mode=referee
```
или
```
bihactl add --mode=referee_with_wal
```
Обратите внимание, что при добавлении в кластер узла-рефери можно использовать только pg_basebackup.
Запустите экземпляр Postgres Pro с настроенным узлом-рефери:
```
pg_ctl start -D каталог_PGDATA_рефери
```

Чтобы удалить узел-рефери из кластера, выполните следующие шаги:

Остановите экземпляр Postgres Pro с настроенным узлом-рефери:
```
pg_ctl stop -D каталог_PGDATA_рефери
```
Вызовите функцию biha.remove_node на узле-лидере с нужным ID:
```
SELECT biha.remove_node(id_рефери)
```

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 2+1 #

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

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

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

F.8.3.4. Роли #

При инициализации отказоустойчивого кластера создаётся база данных 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.5. Восстановление узла в состоянии `NODE_ERROR` #

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

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

Когда узел переходит в состояние NODE_ERROR, восстановление WAL приостанавливается и процесс walreceiver завершается. Кроме того, сведения об ошибке сохраняются в файле 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 исходного сервера на момент синхронизации.

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

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

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

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

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

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

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

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

Расширение 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.3.

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

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

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

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

Расширение biha предоставляет несколько описанных ниже параметров конфигурации, специфичных для встроенного отказоустойчивого кластера. Кроме того, используются некоторые конфигурационные параметры Postgres Pro: listen_addresses, порт, shared_preload_libraries и wal_keep_size, которые задаются автоматически при подготовке кластера, а также hot_standby, max_replication_slots, max_slot_wal_keep_size, max_wal_senders и wal_level, которые используются со значениями по умолчанию.

F.8.4.1.1. Автоматическая синхронизация #

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

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

Важно

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

biha.heartbeat_max_lost #: Указывает максимальное число сообщений о контроле состояния, которые можно не получить до того, как потребуется действие. Этот параметр может задаваться функцией biha.set_heartbeat_max_lost. Значение по умолчанию — 10.
biha.heartbeat_send_period #: Указывает частоту отправки сообщений о контроле состояния в миллисекундах. Этот параметр может задаваться функцией biha.set_heartbeat_send_period. Значение по умолчанию — 1000.
biha.host #: Указывает адрес узла отказоустойчивого кластера. Этот параметр уникален для каждого узла. Для первого узла он задаётся при инициализации кластера, для остальных узлов — при добавлении к кластеру. Этот параметр не рекомендуется изменять.
biha.id #: Указывает идентификатор узла отказоустойчивого кластера. Этот параметр уникален для каждого узла. Для первого узла он задаётся при инициализации кластера, для остальных узлов — при добавлении к кластеру. Этот параметр не рекомендуется изменять.
biha.minnodes #: Указывает минимальное число работающих узлов, при котором узел-лидер будет открыт для пишущих транзакций. Этот параметр может быть задан с помощью функции biha.set_nquorum_and_minnodes.
biha.no_wal_on_follower #: Указывает тайм-аут, в течение которого последователи могут ожидать получения WAL от лидера (в миллисекундах). Этот параметр может задаваться функцией biha.set_no_wal_on_follower. Значение по умолчанию — 20000.
biha.nquorum #: Указывает число узлов, которое необходимо при выборе узла-лидера кластера. Этот параметр может быть задан с помощью функции biha.set_nquorum_and_minnodes.
biha.port #: Указывает порт, используемый для обмена служебной информацией между узлами. Этот параметр необходим, чтобы установить соединение с кластером. Этот параметр не рекомендуется изменять.

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

biha.BihaLog_log_level #: Задаёт уровень протоколирования для предоставления общей информации о работе компонентов biha. Значение по умолчанию — LOG.
biha.BcpTransportDebug_log_level #: Задаёт уровень протоколирования для предоставления отладочной информации о работе канала управления. Значение по умолчанию — DEBUG4.
biha.BcpTransportDetails_log_level #: Задаёт уровень протоколирования для предоставления подробной информации о работе канала управления. Значение по умолчанию — DEBUG4.
biha.BcpTransportLog_log_level #: Задаёт уровень протоколирования для предоставления общей информации о работе канала управления. Значение по умолчанию — DEBUG4.
biha.BcpTransportWarn_log_level #: Задаёт уровень протоколирования для вывода предупреждений о возможных проблемах в канале управления. Значение по умолчанию — DEBUG4.
biha.NodeControllerDebug_log_level #: Задаёт уровень протоколирования для предоставления отладочной информации о работе контроллера узла. Значение по умолчанию — DEBUG4.
biha.NodeControllerDetails_log_level #: Задаёт уровень протоколирования для предоставления подробной информации о работе контроллера узла. Значение по умолчанию — DEBUG4.
biha.NodeControllerLog_log_level #: Задаёт уровень протоколирования для предоставления общей информации о работе контроллера узла. Значение по умолчанию — DEBUG4.
biha.NodeControllerWarn_log_level #: Задаёт уровень протоколирования для вывода предупреждений о возможных проблемах в контроллере узла. Значение по умолчанию — 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 #: Устанавливает узел-лидер вручную.

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

biha.config () returns setof record #: Возвращает значения конфигурации кластера: id, term, nquorum, minnodes, heartbeat_send_period, heartbeat_max_lost, no_wal_on_follower.
biha.set_heartbeat_max_lost (integer) returns boolean #: Указывает максимальное число сообщений о контроле состояния, которые можно не получить до того, как потребуется действие. Эту функцию можно вызвать только c узла-лидера, при этом она изменяет параметры на всех узлах. Чтобы изменения вступили в силу, нет необходимости перезапускать узел кластера.
biha.set_heartbeat_send_period (integer) returns boolean #: Задаёт частоту отправки сообщений о контроле состояния в миллисекундах. Эту функцию можно вызвать только с узла-лидера, при этом она изменяет параметры на всех узлах. Чтобы изменения вступили в силу, нет необходимости перезапускать узел кластера.
biha.set_no_wal_on_follower (integer) returns boolean #: Указывает тайм-аут, в течение которого последователи могут ожидать получения WAL от лидера, в миллисекундах. Эту функцию можно вызвать только с узла-лидера, при этом она изменяет параметры на всех узлах. Чтобы изменения вступили в силу, нет необходимости перезапускать узел кластера.
biha.set_nquorum_and_minnodes (integer, integer) returns boolean #: Задаёт значения nquorum и minnodes для кластера. Эту функцию можно вызвать только с узла-лидера, при этом она изменяет параметры на всех узлах. Чтобы изменения вступили в силу, нет необходимости перезапускать узел кластера.

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.3. Представления #

F.8.4.3.1. `biha.nodes_v` #

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

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

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

F.8.4.3.2. `biha.status_v` #

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

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

Имя столбца	Описание
`id`	Идентификатор узла.
`leader_id`	Идентификатор узла-лидера.
`term`	Поколение узла. Используется при голосовании по выбору нового узла-лидера.
`online`	Показывает подключён ли узел к сети.
`state`	Состояние узла. В этом столбце могут отображаться одно из следующих значений: `CANDIDATE`, `CSTATE_FORMING`, `FOLLOWER`, `FOLLOWER_OFFERED`, `FOLLOWER_VOTING`, `LEADER_RO`, `LEADER_RW`, `NODE_ERROR`, `NODE_ERROR_VOTING`, `STARTUP` или `UNKNOWN`.
`last_known_state`	Последнее известное состояние узла.
`since_last_hb`	Время, прошедшее с момента получения последнего сообщения о контроле состояния.

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

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

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

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

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