NODE_ERRORСостав кластера можно изменять, добавляя или удаляя узлы. Чтобы добавить узел, используйте команду bihactl add с соответствующими параметрами. Чтобы удалить узел, используйте функцию biha.remove_node. За подробным описанием процесса подготовки отказоустойчивого кластера обратитесь к Разделу 27.2.
Некоторые конфигурационные параметры должны иметь одинаковое значение на всех узлах кластера. Задавать значения таких параметров можно только с помощью специальных функций. Например, чтобы установить значение параметра biha.heartbeat_max_lost, используйте функцию biha.set_heartbeat_max_lost:
SELECT biha.set_heartbeat_max_lost(7);
Все доступные функции для настройки конфигурационных параметров кластера перечислены в Подразделе 27.4.2.1.
Параметры, значения которых могут различаться на разных узлах кластера, можно изменять с помощью команды ALTER SYSTEM. Например, параметр biha.can_vote можно изменить через ALTER SYSTEM:
ALTER SYSTEM SET biha.can_vote = true; SELECT pg_reload_conf();
Более подробную информацию о параметрах и способах их настройки см. в biha.
В дополнение к встроенным возможностям аварийного переключения узлов, отказоустойчивый кластер в Postgres Pro позволяет переключать узлы вручную. Разница между аварийным переключением и ручным переключением узлов заключается в том, что аварийное переключение выполняется автоматически при отказе узла-лидера, а ручное переключение выполняет системный администратор. Чтобы вручную переключить узел в узел-лидер, используйте функцию biha.set_leader. При выборе нового лидера происходит следующее:
Все попытки выборов блокируются и задаётся тайм-аут.
Текущий узел-лидер становится узлом-последователем.
Выбранный узел становится новым лидером.
Если процесс ручного переключения узлов не завершается в течение установленного тайм-аута, выбранный узел становится последователем и проводятся выборы нового лидера.
Можно включать или отключать SSL для служебных подключений в инициализированном BiHA-кластере с помощью параметра конфигурации biha.use_ssl.
Чтобы включить SSL, на всех узлах кластера для параметра biha.use_ssl установите значение true:
ALTER SYSTEM SET biha.use_ssl = true;
Чтобы отключить SSL, установите значение false.
Перезапустите узлы с помощью pg_ctl.
Так как включение SSL в BiHA-кластере подразумевает использование стандартного процесса начального согласования TLS, рекомендуется минимизировать время между перезапуском узлов кластера.
При инициализации отказоустойчивого кластера создаётся база данных biha_db, также в схеме biha базы данных biha_db создаётся расширение biha. Кроме того, создаются и используются следующие роли:
BIHA_CLUSTER_MANAGEMENT_ROLE — отвечает за выполнение всех функций расширения biha.
BIHA_REPLICATION_ROLE — используется при работе pg_rewind и pg_probackup.
biha_replication_user — является членом ролей BIHA_REPLICATION_ROLE и BIHA_CLUSTER_MANAGEMENT_ROLE и может совершать как клиентские подключения, так и подключения по протоколу репликации. Эта роль используется утилитой bihactl, а также при подключении узла-последователя к узлу-лидеру. Является владельцем базы данных biha_db. Пароль для роли biha_replication_user в файле паролей должен быть одинаковым на всех узлах BiHA-кластера. Пароль предлагается задать во время создания BiHA-кластера.
biha_callbacks_user — по умолчанию исполняет функции-обработчики. Этот пользователь может подключаться к базе данных, но не имеет никаких прав.
pg_monitor — предопределённая роль, которая используется для мониторинга состояния BiHA-кластера.
NODE_ERROR #Описанные ниже ошибки, возникающие в процессах biha или экземпляра сервера, могут привести к отказу узла, то есть он не сможет перезагрузиться и WAL будет повреждён:
Синхронизация, автоматически выполняемая расширением biha с использованием pg_rewind при расхождении линий времени узла.
Процесс walreceiver в случае расхождения линий времени. WAL узла-последователя может быть частично перезаписан WAL, полученным от узла-лидера.
Если узел перешел в состояние NODE_ERROR из-за других проблем, например, по причине переполнения слота репликации, после устранения первопричины можно вызвать функцию biha.reset_node_error для сброса состояния NODE_ERROR.
Когда узел переходит в состояние NODE_ERROR, восстановление WAL приостанавливается и процесс walreceiver завершается. Чтение с узлов в состоянии NODE_ERROR запрещено. Кроме того, сведения об ошибке сохраняются в файле biha.state и проверяются при перезапуске узла, поэтому узел перейдёт в то же состояние при запуске процесса biha-background-worker.
Чтобы восстановить узел из состояния NODE_ERROR, выполните следующие шаги:
Сохраните последние файлы из каталога pg_wal, так как некоторые уникальные для этого узла файлы будут перезаписаны утилитой pg_rewind.
Чтобы сохранить файлы конфигурации biha, запустите pg_rewind с параметром --biha.
Параметр --biha необходим для сохранения файлов конфигурации расширения biha. Использование pg_rewind в BiHA-кластере без указания параметра --biha может вызвать несогласованность конфигурации кластера.
При успешной синхронизации информация о состоянии NODE_ERROR удаляется из файла biha.state. Кроме того, строка подключения, указанная в параметре --source-server утилиты pg_rewind, автоматически сохраняется для параметра конфигурации primary_conninfo в файле postgresql.auto.conf. Это важно для того, чтобы узел продолжил восстанавливаться после перезапуска и достиг точки согласованности, которая представляет собой номер последней записи WAL исходного сервера на момент синхронизации.
(Необязательно) Если узел был недоступен долгое время, на восстановленном узле установите для параметра biha.flw_ro значение off, чтобы предотвратить повреждение данных и чтение неактуальных данных.
Результаты синхронизации, т.е. состояние синхронизации узлов кластера, можно проверить в поле rewind_state файла biha.state. Оно содержит значения типа enum, которые интерпретируются следующим образом:
Таблица 27.1. Состояние синхронизации
| Значение | Интерпретация |
|---|---|
0 | Синхронизация не требуется. |
1 | Сервер остановлен, параметр конфигурации biha.autorewind включён, синхронизация будет выполнена после перезапуска сервера. |
2 | Синхронизация завершилась ошибкой. |
3 | Синхронизация выполнена. |
4 | Параметр конфигурации biha.autorewind не был включён, синхронизацию необходимо выполнить вручную, как описано в Подразделе 27.3.6. |
BiHA позволяет создать кластер с синхронной репликацией на основе кворума. Чтобы настроить синхронную репликацию, используйте параметр --sync-standbys в команде bihactl init. При этом изменится параметр synchronous_standby_names, в нём будет прописан список всех узлов с ключевым словом ANY. Например, если для кластера из трёх узлов в качестве значения параметра --sync-standbys указать 2, synchronous_standby_names будет выглядеть следующим образом:
ANY 2 (biha_node_1,biha_node_2,biha_node_3)
При этом изменится параметр synchronous_standby_names, в нём будет прописан список всех узлов с ключевым словом ANY. Кроме того, используется параметр synchronous_commit со значением по умолчанию on. Обратите внимание, что для синхронной репликации нельзя выбрать определённые узлы, но можно задать количество узлов, которые должны работать синхронно, в параметре --sync-standbys. Для других узлов кластера данные будут реплицироваться асинхронно, так как потоковая репликация по умолчанию выполняется асинхронно. За подробностями обратитесь к Подразделу 26.2.8.
Ограничения синхронной репликации можно смягчить, чтобы лидер мог продолжать работу, пока часть последователей временно недоступна. Чтобы включить нестрогую синхронную репликацию, укажите минимальное количество последователей в параметре --sync-standbys-min. Если этот параметр задан, соответствующим образом также изменяется поле MIN в параметре synchronous_standby_names. Значение параметра synchronous_standby_gap остаётся неизменным и сохраняет своё значение по умолчанию, равное 0. Например, если для кластера из трёх узлов в качестве значения параметра --sync-standbys-min указать 0, synchronous_standby_names будет выглядеть следующим образом:
ANY 2 MIN 0 (biha_node_1,biha_node_2,biha_node_3)
Значение параметра --sync-standbys-min можно задать при инициализации BiHA-кластера с помощью команды bihactl init и в дальнейшем изменить с помощью функции biha.set_sync_standbys_min.
Есть несколько особенностей, которые необходимо учитывать при использовании синхронной репликации и узла-рефери. Если для параметра --mode установлено значение referee, рефери не участвует в синхронной репликации. Если установлено значение referee_with_wal, узел может синхронно получать данные. Этот режим позволяет кластеру оставаться доступным в конфигурации 2+1 с --sync-standbys=1, когда узел-последователь вышел из строя и узел-рефери начинает подтверждать транзакции для лидера. Поведение рефери зависит от значения параметра synchronous_commit. Обратите внимание, что если для этого параметра установлено значение remote_apply, рефери не подтверждает транзакции.
Расширение 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, которые перечислены в Подразделе 27.4.1.2.
Например, чтобы отображать сообщения, относящиеся к каналу управления, но без отладочной информации, укажите приведённые ниже строки в файле конфигурации postgresql.biha.conf или задайте соответствующие параметры конфигурации. В этом случае предполагается, что для log_min_messages установлено значение LOG:
biha.BcpTransportLog_log_level = LOG biha.BcpTransportWarn_log_level = LOG biha.BcpTransportDetails_log_level = LOG
Обработчик — это SQL-функция, которая уведомляет пользователей или внешние сервисы о событиях в BiHA-кластере, например о выборах нового лидера или изменении конфигурации кластера. Как пользователь, вы создаёте SQL-функцию и регистрируете её в качестве обработчика. При определённых условиях biha вызовет эту функцию.
Своевременное оповещение помогает внешним службам правильно реагировать на события в BiHA-кластере. Например, при получении информации об изменении лидера прокси-сервер перенаправит трафик на нового лидера.
Доступны следующие типы обработчиков:
Таблица 27.2. Типы обработчиков
| Имя | Описание |
|---|---|
CANDIDATE_TO_LEADER |
Вызывается на узле, выбранном в качестве нового лидера. Сигнатура: my_callback(void) RETURNS void |
LEADER_TO_FOLLOWER |
Вызывается на старом лидере, который вернулся в кластер после понижения. Сигнатура: my_callback(void) RETURNS void |
LEADER_CHANGED |
Вызывается на каждом узле при смене лидера BiHA-кластера. Сигнатура: my_callback(id integer, host text, port integer) RETURNS void В этой сигнатуре biha передаёт информацию о новом лидере: ID, имя узла и номер порта узла. |
LEADER_STATE_IS_RW |
Вызывается на лидере и других узлах, когда состояние лидера изменяется на Сигнатура: my_callback(id integer, host text, port integer) RETURNS void В этой сигнатуре biha передаёт в функцию-обработчик информацию о лидере: ID, имя узла и номер порта узла. |
TERM_CHANGED |
Вызывается на узле, когда значение его параметра Сигнатура: my_callback(old_term integer, new_term integer) RETURNS void В этой сигнатуре biha передаёт старое и новое значение параметра |
OFFERED_TO_LEADER |
Вызывается на узле, который был назначен лидером вручную, перед непосредственным переходом в статус лидера. Сигнатура: my_callback(void) RETURNS void |
NODE_ADDED |
Вызывается на каждом узле при добавлении нового узла в BiHA-кластер. Сигнатура: my_callback(id integer, host text, port integer, mode integer) RETURNS void В этой сигнатуре biha передаёт в функцию-обработчик информацию о новом узле, такую как имя узла, номер порта узла и режим работы: |
NODE_REMOVED |
Вызывается на каждом узле при удалении узла из BiHA-кластера. Сигнатура: my_callback(id integer) RETURNS void В этой сигнатуре biha передаёт в функцию-обработчик ID удалённого узла. |
При наступлении события функции-обработчики исполняются последовательно. В это время biha не может изменить своё состояние, например инициировать выборы.
Если исполнение функции-обработчика длится дольше, чем указано в biha.callbacks_timeout, biha останавливает исполнение и продолжает работать в обычном режиме.
На кластерах с асинхронной репликацией функция biha.register_callback не дожидается, пока обработчики появятся на всех узлах. Это может привести к ситуации, когда обработчики на лидере есть, а на последователе — нет, так как он отстаёт.
В норме функции-обработчики не исполняются на рефери в режиме referee. Однако, если вы зарегистрировали функции-обработчики на лидере до добавления рефери, они могут исполняться на рефери и их также нельзя с него удалить.
Не вызывайте функции biha внутри обработчика, так как это может вызвать непредвиденное поведение.
Для управления функциями-обработчиками вы можете выполнять следующие действия:
зарегистрировать один или несколько обработчиков на одно событие
просмотреть список зарегистрированных обработчиков
отменить регистрацию обработчика
Регистрация функций-обработчиков
Напишите SQL-функцию и зарегистрируйте её в качестве обработчика с помощью функции biha.register_callback.
В этом примере вы создадите несколько SQL-функций на языке PL/pgSQL и зарегистрируете их в качестве обработчиков разных типов.
Убедитесь, что лидер BiHA-кластера находится в состоянии LEADER_RW.
На лидере используйте psql для подключения к базе данных biha_db:
postgres=# \c biha_db
Создайте следующие функции-обработчики:
-- запись при смене значения term
CREATE FUNCTION log_term_changed(old_term integer, new_term integer)
RETURNS void AS $$
BEGIN
RAISE LOG 'Callback: Term changed from % to %', old_term, new_term;
END;
$$ LANGUAGE plpgsql;
-- запись при смене лидера
CREATE FUNCTION log_leader_changed(id integer, host text, port integer)
RETURNS void AS $$
BEGIN
RAISE LOG 'Callback: New leader is % %:%', id, host, port;
END;
$$ LANGUAGE plpgsql;
-- запись при понижении лидера
CREATE FUNCTION log_leader_to_follower()
RETURNS void AS $$
BEGIN
RAISE LOG 'Callback: demote';
END;
$$ LANGUAGE plpgsql;Зарегистрируйте созданные функции:
SELECT biha.register_callback('TERM_CHANGED', 'log_term_changed', 'biha_db');
SELECT biha.register_callback('LEADER_CHANGED', 'log_leader_changed', 'biha_db');
SELECT biha.register_callback('LEADER_TO_FOLLOWER', 'log_leader_to_follower', 'biha_db');Вы также можете указать пользователя, от имени которого будут исполняться функции-обработчики или определить порядок их исполнения. Подробнее читайте в описании функции biha.register_callback.
Просмотр функций-обработчиков
Зарегистрированные обработчики добавляются в таблицу biha.callbacks, которая находится в базе данных biha_db.
Для просмотра всех зарегистрированных обработчиков выполните следующую команду:
На лидере используйте psql для подключения к базе данных biha_db:
postgres=# \c biha_db
Отобразите содержимое таблицы biha.callbacks:
SELECT * FROM biha.callbacks; 1 | log_term_changed 2 | log_leader_changed 3 | log_leader_to_follower (3 rows)
Отмена регистрации функции-обработчика
Отменённый обработчик удаляется из таблицы biha.callbacks.
Убедитесь, что лидер BiHA-кластера находится в состоянии LEADER_RW.
На лидере используйте psql для подключения к базе данных biha_db:
postgres=# \c biha_db
Получите идентификатор обработчика, который вы хотите отменить, например log_leader_changed:
SELECT id FROM biha.callbacks WHERE func = 'log_leader_changed';
Возвращается идентификатор обработчика, например 2.
Отменить регистрацию обработчиков:
SELECT biha.unregister_callback(2);
Регистрация обработчика отменена.
Если экземпляр базы данных был восстановлен из одного из узлов кластера BiHA в отдельный узел и/или на момент времени (Point-in-Time Recovery, PITR), между восстановленным узлом и работающими узлами кластера BiHA не должно быть соединения. Чтобы предотвратить соединение, выполните следующие действия на восстановленном узле перед его запуском:
Удалите директиву включения include 'postgresql.biha.conf' из файла конфигурации postgresql.conf.
Убедитесь, что расширение biha отсутствует в shared_preload_libraries в файле postgresql.conf и, если применимо, в файле postgresql.auto.conf.
Если вы хотите добавить восстановленный узел в кластер, выполните следующие действия:
На восстановленном узле вручную настройте потоковую репликацию от лидера.
Синхронизируйте восстановленный узел с лидером.
Остановите восстановленный узел с помощью pg_ctl:
pg_ctl stop -D каталог_PGDATA_восстановленного узлаДобавьте восстановленный узел в кластер с помощью команды bihactl add с параметром --convert-standby.
Запустите восстановленный узел с помощью pg_ctl:
pg_ctl start -D каталог_PGDATA_восстановленного узлаВ зависимости от текущей версии Postgres Pro Enterprise, используйте одну из следующих процедур для обновления BiHA-кластера:
Для перехода с Postgres Pro Enterprise версии 16.X на версию 17.X воспользуйтесь инструкцией Миграция BiHA-кластера с версии 16.X на версию 17.X.
Для перехода с Postgres Pro Enterprise версии 17.2 на версию 17.4 воспользуйтесь инструкцией Миграция BiHA-кластера в состоянии LEADER_RW.
Чтобы обновить BiHA-кластер с версии Postgres Pro Enterprise 16.X до версии 17.X, выполните следующие шаги:
Остановите все узлы кластера с помощью команды pg_ctl.
Обновите узлы с помощью инструкции из документации pg_upgrade.
Добавьте последователей одним из следующих способов:
Если вы использовали rsync для обновления ведомых узлов, преобразуйте ведущие узлы в последователей.
Если вы не использовали rsync, добавьте последователей с нуля.
(Необязательно) Если необходимо, повторно создайте рефери.
LEADER_RW #Используйте эту инструкцию для миграции BiHA-кластера с версии 17.2 на версию 17.4.
Остановите одного из последователей с помощью команды pg_ctl.
Обновите последователя.
Запустите последователя с помощью команды pg_ctl.
Повысьте обновлённого последователя до лидера с помощью функции biha.set_leader.
Остановите, обновите и запустите остальных последователей и старого лидера.
Повысьте старого лидера с помощью функции biha.set_leader.
Вы можете временно выключить или полностью удалить расширение biha.
Выключение расширения biha
Чтобы выключить расширение:
Удалите директиву включения include 'postgresql.biha.conf' из файла конфигурации postgresql.conf.
Убедитесь, что расширение biha отсутствует в shared_preload_libraries в файле postgresql.conf и, если применимо, в файле postgresql.auto.conf.
Полное удаление расширения biha
Чтобы полностью удалить расширение, выполните следующие действия:
Выполните команду DROP EXTENSION. Её необходимо выполнить на лидере в состоянии LEADER_RW и из базы данных biha_db:
biha_db=# DROP EXTENSION biha;