27.3. Администрирование
Пред. НаверхГлава 27. Встроенная отказоустойчивость (BiHA)Начало След.

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

27.3.1. Изменение состава кластера
27.3.2. Изменение конфигурационных параметров
27.3.3. Ручное переключение узлов
27.3.4. Роли
27.3.5. Восстановление узла из состояния NODE_ERROR
27.3.6. Мониторинг результатов синхронизации
27.3.7. Настройка синхронной и асинхронной репликации
27.3.8. Протоколирование
27.3.9. Функции-обработчики
27.3.10. Восстановление из резервной копии
27.3.11. Миграция
27.3.12. Удаление расширения biha

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

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

27.3.2. Изменение конфигурационных параметров #

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

SELECT biha.set_heartbeat_max_lost(7);

Все доступные функции для настройки конфигурационных параметров кластера перечислены в Подразделе 27.4.2.2.4.

Параметры, значения которых могут различаться на разных узлах кластера, можно изменять с помощью команды ALTER SYSTEM. Например, параметр biha.can_vote можно изменить через ALTER SYSTEM:

ALTER SYSTEM SET biha.can_vote = true;
SELECT pg_reload_conf();

Более подробную информацию о параметрах и способах их настройки см. в biha.

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

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

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

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

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

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

27.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.

  • biha_callbacks_user — по умолчанию исполняет функции-обработчики. Этот пользователь может подключаться к базе данных, но не имеет никаких прав. При необходимости права можно предоставить с помощью команды GRANT.

  • pg_monitor — предопределённая роль, которая используется для мониторинга состояния отказоустойчивого кластера.

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

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

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

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

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

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

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

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

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

  3. (Необязательно) Если узел был недоступен долгое время, на восстановленном узле установите для параметра biha.flw_ro значение off, чтобы предотвратить повреждение данных и чтение неактуальных данных.

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

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

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

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

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

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

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

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

27.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, которые перечислены в Подразделе 27.4.2.1.2.

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

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

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

Обработчик — это 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

Вызывается на лидере и других узлах, когда состояние лидера изменяется на LEADER_RW.

Сигнатура:

my_callback(id integer, host text, port integer) RETURNS void

В этой сигнатуре biha передаёт в функцию-обработчик информацию о лидере: ID, имя узла и номер порта узла.

TERM_CHANGED

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

Сигнатура:

my_callback(old_term integer, new_term integer) RETURNS void

В этой сигнатуре biha передаёт старое и новое значение параметра term.

OFFERED_TO_LEADER

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

Сигнатура:

my_callback(void) RETURNS void
NODE_ADDED

Вызывается на каждом узле при добавлении нового узла в BiHA-кластер.

Сигнатура:

my_callback(id integer, host text, port integer, mode integer) RETURNS void

В этой сигнатуре biha передаёт в функцию-обработчик информацию о новом узле, такую как имя узла, номер порта узла и режим работы: regular, referee или referee_with_wal. Подробнее читайте в Подразделе 27.1.3.

NODE_REMOVED

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

Сигнатура:

my_callback(id integer) RETURNS void

В этой сигнатуре biha передаёт в функцию-обработчик ID удалённого узла.


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

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

  • Если исполнение функции-обработчика длится дольше, чем указано в biha.callbacks_timeout, biha останавливает исполнение и продолжает работать в обычном режиме.

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

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

Примечание

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

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

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

  • зарегистрировать один или несколько обработчиков на одно событие

  • просмотреть список зарегистрированных обработчиков

  • отменить регистрацию обработчика

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

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

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

  1. Убедитесь, что лидер BiHA-кластера находится в состоянии LEADER_RW.

  2. На лидере используйте psql для подключения к базе данных biha_db:

    postgres=# \c biha_db

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

    -- запись при смене значения 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;

  4. Зарегистрируйте созданные функции:

    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.

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

  1. На лидере используйте psql для подключения к базе данных biha_db:

    postgres=# \c biha_db

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

    SELECT * FROM biha.callbacks;

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

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

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

  1. Убедитесь, что лидер BiHA-кластера находится в состоянии LEADER_RW.

  2. На лидере используйте psql для подключения к базе данных biha_db:

    postgres=# \c biha_db

  3. Получите идентификатор обработчика, который вы хотите отменить, например log_leader_changed:

    SELECT id FROM biha.callbacks WHERE func = 'log_leader_changed';

    Возвращается идентификатор обработчика, например 2.

  4. Отменить регистрацию обработчиков:

    SELECT biha.unregister_callback(2);

    Регистрация обработчика отменена.

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

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

  1. Удалите директиву включения include 'postgresql.biha.conf' из файла конфигурации postgresql.conf.

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

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

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

  2. Синхронизируйте восстановленный узел с лидером.

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

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

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

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

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

27.3.11. Миграция #

27.3.11.1. Миграция BiHA-кластера на версию 17.2 #

Чтобы обновить BiHA-кластер с версии Postgres Pro Enterprise 16.X до версии 17.2, выполните следующие шаги:

  1. Полностью удалите biha.

  2. Остановите все узлы кластера с помощью команды pg_ctl.

  3. Обновите узлы с помощью инструкции из документации pg_upgrade.

  4. Преобразуйте ведущий узел в лидера.

  5. Добавьте последователей одним из следующих способов:

  6. (Необязательно) Если необходимо, повторно создайте рефери.

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

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

Выключение расширения biha

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

  1. Удалите директиву включения include 'postgresql.biha.conf' из файла конфигурации postgresql.conf.

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

Полное удаление расширения biha

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

  1. Выключите biha.

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

    biha_db=# DROP EXTENSION biha;
Пред. Наверх След.
27.2. Подготовка BiHA-кластера Начало 27.4. Справка