F.8. biha — встроенный отказоустойчивый кластер #
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
. Например, в случае отказа одного узла-последователя в кластере из трёх узлов, где
, узел-лидер продолжит работать. При отказе лидера в таком кластере два оставшихся последователя начнут выборы. После избрания нового лидера значение поколения кластера term увеличивается на единицу для всех узлов, то есть для нового лидера и оставшихся последователей значение будетnquorum
=2
, а для старого лидера оно останется какterm
=2
. Поэтому при возвращении старого лидера в кластер он станет последователем. После избрания нового лидера последователи начинают получать файлы WAL от этого узла. Обратите внимание, что старый лидер не может быть открыт для пишущих транзакций после избрания нового лидера, чтобы избежать проблем разделения кластера. После восстановления старого лидера следует либо пересоздать кластер с этим лидером, либо синхронизировать его с новым лидером при помощи pg_rewind. Механизмы кворума и поколения реализованы в biha на базе алгоритма консенсуса Raft.term
=1Отказ узла-последователя. Если последователь настроен как асинхронный, отказ никак не отразится на лидере. Если для последователя используется синхронная репликация, отказ приведёт к остановке транзакции на лидере, так как он перестанет получать подтверждение транзакций от последователя и транзакция не сможет завершиться. Подробное описание того, как настроить синхронную репликацию в кластере 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. Кластер конфигурируется автоматически при выполнении вышеуказанных команд, но необходимо указать некоторые связанные с кластером параметры. Обратите внимание, что для подключения узла-последователя к узлу-лидеру необходимо, чтобы в файле паролей был указан пароль.
Для подготовки кластера выполните следующие шаги:
Инициализируйте кластер и создайте узел-лидер.
Выполните команду
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)"
Выполните следующую команду, чтобы запустить СУБД:
pg_ctl start -D
локальный_каталог_PGDATA_лидера
-lфайл_журнала_лидера
Добавьте узел-последователь.
Отредактируйте файл паролей, указав в нём пароль для роли
biha_replication_user
. Это необходимо для подключения узла-последователя к узлу-лидеру.Выполните команду
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.Выполните следующую команду, чтобы запустить СУБД:
pg_ctl start -D
каталог_PGDATA_последователя
-lфайл_журнала_последователя
F.8.2.2. Подготовка отказоустойчивого кластера из существующих узлов #
Чтобы подготовить встроенный отказоустойчивый кластер из существующих узлов, выполните следующие команды: bihactl
init с параметром --convert
и bihactl
add, если есть только ведущий узел и нужно сделать его лидером и добавить новые узлы с нуля, или bihactl
init с параметром --convert
и bihactl
add с параметром --convert-standby
, если нужно преобразовать ведущий узел в узел-лидер, а ведомые — в узлы-последователи кластера. Кластер конфигурируется автоматически при выполнении вышеуказанных команд, но необходимо указать некоторые связанные с кластером параметры. Обратите внимание, что для подключения узла-последователя к узлу-лидеру необходимо, чтобы в файле паролей был указан пароль.
Для подготовки кластера выполните следующие шаги:
Преобразуйте существующий узел в узел-лидер.
Остановите существующий узел перед преобразованием в узел-лидер:
pg_ctl stop -D
каталог_PGDATA_лидера
Выполните команду
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)"
Выполните следующую команду, чтобы запустить СУБД:
pg_ctl start -D
локальный_каталог_PGDATA_лидера
-lфайл_журнала_лидера
Добавьте узел-последователь.
Узел-последователь может быть добавлен двумя способами. Прежде чем перейти к одному из следующих шагов, отредактируйте файл паролей, указав в нём пароль для роли
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_последователя
Выполните команду
bihactl
add с дополнительными параметрами, чтобы добавить новый узел-последователь с нуля.
При преобразовании существующего узла в узел-последователь biha создаёт файлы
икаталог_PGDATA_последователя
/pg_biha/biha.conf
, необходимые для подключения узла к кластеру, и редактирует файлы postgresql.conf и pg_hba.conf.каталог_PGDATA_последователя
/pg_biha/biha.stateВыполните следующую команду, чтобы запустить СУБД:
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, port, 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 | Время, прошедшее с момента получения последнего сообщения о контроле состояния. |