F.9. biha — встроенный отказоустойчивый кластер
Пред. НаверхПриложение F. Дополнительно поставляемые модули и расширенияНачало След.

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

F.9.1. Обзор
F.9.2. Подготовка отказоустойчивого кластера
F.9.3. Администрирование
F.9.4. Справка

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

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

  • Физическая репликация.

  • Встроенное аварийное переключение узлов.

  • Выделенный узел-лидер, доступный для чтения и записи, и узлы-последователи, доступные только для чтения.

  • Синхронная и асинхронная репликация узлов.

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

  • Не требуется стороннее кластерное программное обеспечение.

F.9.1. Обзор #

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

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

  • Выполнение читающих транзакций в базе данных.

  • Подготовка отчётов.

  • Создание таблиц в оперативной памяти для пишущих транзакций.

  • Подготовка резервной копии узла-последователя.

  • Восстановление повреждённых блоков данных на узле-лидере путём получения этих блоков с узла-последователя.

  • Проверка повреждённых записей в файлах WAL.

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

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

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

  3. Сбой соединения между узлом-лидером и узлом-последователем. В этом случае лидер не может отправить, а последователь не может получить данные. Обратите внимание, что если пользователи подключены к лидеру, разрешать пишущие транзакции на последователе нельзя. Любые изменения, сделанные на последователях, нельзя будет восстановить на лидере. Чтобы избежать потери изменений, настраивайте сеть с резервными каналами. Лучше всего настроить свой канал передачи данных для каждого последователя, чтобы предупредить проблемы, связанные с единой точкой отказа.

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

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

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

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

  1. Три и более узлов. Ниже представлены возможные сценарии при отказе лидера или сбое соединения:

    • В результате аварийного переключения узлов новый лидер выбирается простым большинством голосов.

    • При сбоях соединения кластер может разделиться на несколько групп узлов. В этом случае новый лидер выбирается в группе с наибольшим числом узлов. После восстановления соединения проходят выборы между старым и новоизбранным лидером в зависимости от значения term поколения кластера. Кроме того, если значение nquorum равняется значению minnodes, старый лидер становится доступным только для чтения.

    Кроме того, узел-лидер можно задать вручную при помощи функции biha.set_leader.

  2. Два узла, из которых один лидер, а второй последователь. Ниже представлены возможные сценарии при отказе лидера или сбое соединения:

    • Последователь становится новым лидером. Сбой соединения, при котором последователь «не видит» лидера, может привести к «раздвоению» в кластере ввиду появления двух лидеров.

    • При сбое соединения ничего не происходит. В этом случае последователь не станет новым лидером.

    Кроме того, узел-лидер можно задать вручную при помощи функции biha.set_leader.

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

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

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

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

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

  1. Инициализируйте кластер и создайте узел-лидер.

    1. Выполните команду bihactl add с необходимыми параметрами, как показано ниже. На этом этапе bihactl в интерактивном режиме запрашивает пароль для роли biha_replication_user, который будет использоваться для подключения узла-последователя к узлу-лидеру на следующем этапе:

      bihactl init \
    --biha-node-id=1 \
    --host=localhost \
    --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 файл_журнала_лидера

  2. Добавьте узел-последователь.

    1. Отредактируйте файл паролей, указав в нём пароль для роли biha_replication_user. Это необходимо для подключения узла-последователя к узлу-лидеру.

    2. Выполните команду bihactl add с необходимыми параметрами.

      bihactl add \
    --biha-node-id=2 \
    --host=localhost \
    --port=5434 \
    --biha-port=5435 \
    --use-leader "host=адрес_узла_лидера port=порт_лидера biha-port=порт_biha_лидера" \
    --pgdata=каталог_PGDATA_последователя

      Узел-последователь можно также добавить с использованием «‎‎магической» строки:

      bihactl add \
    --biha-node-id=2 \
    --host=localhost \
    --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.9.2.2. Подготовка отказоустойчивого кластера из существующих узлов #

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

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

  1. Преобразуйте существующий узел в узел-лидер.

    1. Остановите узел-лидер перед его преобразованием:

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

    2. Выполните команду bihactl init с параметром --convert. На этом этапе bihactl в интерактивном режиме запрашивает пароль для роли biha_replication_user, который будет использоваться для подключения узла-последователя к узлу-лидеру на следующем этапе:

      bihactl init \
    --convert > magic-file \
    --biha-node-id=1 \
    --host=localhost \
    --port=порт_PostgresPro \
    --biha-port=5433 \
    --nquorum=2 \
    --minnodes=2 \
    --pgdata=локальный_каталог_PGDATA_лидера

      В этом случае редактируются файлы postgresql.conf и pg_hba.conf и создаётся «‎‎магическая» строка, содержащая данные для подключения узлов-последователей к узлу-лидеру на следующем этапе.

      Сохраните «‎‎магическую» строку, она может понадобиться при добавлении узла-последователя на следующем этапе:

      export MAGIC_STRING="$(cat magic-file)"

    3. Выполните следующую команду, чтобы запустить СУБД:

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

  2. Добавьте узел-последователь.

    1. Узел-последователь может быть добавлен двумя способами. Прежде чем перейти к одному из следующих шагов, отредактируйте файл паролей, указав в нём пароль для роли biha_replication_user. Это необходимо для подключения узла-последователя к узлу-лидеру:

      1. Остановите существующий узел перед преобразованием в узел-последователь:

        pg_ctl stop -D каталог_PGDATA_последователя

      2. Выполните команду bihactl add с параметром --convert-standby, чтобы преобразовать существующий узел в узел-последователь:

        bihactl add \
    --convert-standby \
    --biha-node-id=2 \
    --host=localhost \
    --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.9.3. Администрирование #

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

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

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

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

  • Все попытки выборов блокируются и задаётся тайм-аут.

  • Текущий узел-лидер становится узлом-последователем.

  • Выбранный узел становится новым лидером.

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

F.9.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.9.3.4. Восстановление узла в состоянии NODE_ERROR #

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

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

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

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

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

  1. Сохраните последние файлы из каталога pg_wal; некоторые уникальные для этого узла файлы будут перезаписаны утилитой pg_rewind.

  2. Запустите pg_rewind с параметром --biha, чтобы сохранить конфигурационные файлы biha.

  3. Запустите узел и вызовите функцию biha.reset_node_error.

  4. Вызовите функцию pg_wal_replay_resume, чтобы возобновить восстановление, если оно было приостановлено.

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

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

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

Расширение 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.9.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.9.4. Справка #

F.9.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.9.4.1.1. Автоматическая синхронизация #
biha.autorewind #

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

F.9.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_leader.

biha.no_wal_on_follower #

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

biha.nquorum #

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

biha.port #

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

F.9.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.9.4.2. Функции #

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

psql biha_db -c "select biha.set_leader(2)"
F.9.4.2.1. Генерирование «‎‎магической» строки #
biha.get_magic_string () returns string #

Генерирует «‎‎магическую» строку для узла кластера.

F.9.4.2.2. Удаление узла кластера #
biha.remove_node (id integer) returns boolean #

Удаляет узел из кластера.

F.9.4.2.3. Установка лидера вручную #
biha.set_leader (id integer) returns boolean #

Устанавливает узел-лидер вручную.

F.9.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.9.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.9.4.2.6. Состояние NODE_ERROR #
biha.error_details () returns setof record #

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

biha.reset_node_error () returns void #

Восстанавливает узел, находящийся в состоянии NODE_ERROR. Подробное описание процесса восстановления узла в этом состоянии содержится в Подразделе F.9.3.4.

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

F.9.4.3.1. biha.nodes_v #

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

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

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

F.9.4.3.2. biha.status_v #

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

Таблица F.13. Представление 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.8. basic_archive — пример модуля архивирования WAL Начало F.10. bloom — индексный метод доступа, основанный на фильтрах Блума