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

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

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

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

Состав кластера можно изменить следующим образом:

  • Чтобы добавить узел, используйте команду bihactl node add с соответствующими параметрами.

  • Чтобы добавить сегмент, используйте функцию biha.add_node.

  • Чтобы добавить узел в определённый сегмент или переместить узел из одного сегмента в другой, используйте функцию biha.set_parent, а затем примените изменения с помощью функции biha.apply_topology.

  • Чтобы удалить узел или сегмент, используйте функцию biha.remove_node.

  • Чтобы изменить лидера вручную, используйте функцию biha.set_leader. За подробной информацией обратитесь к разделу Ручное переключение узлов.

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

Изменить параметры конфигурации кластера можно следующим образом:

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

    SELECT biha.set_heartbeat_max_lost(7);

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

  • Параметры конфигурации, критичные для GDBiHA-кластеров, хранятся в файле pg_biha/biha.conf и не могут быть изменены через ALTER SYSTEM. Чтобы их изменить, необходимо использовать специальные функции. За подробной информацией обратитесь к Подразделу 27.4.1.2.

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

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

Более подробную информацию о доступных параметрах конфигурации BiHA и способах их настройки см. в Подразделе 27.4.1.

За подробной информацией об уменьшении значений параметров конфигурации Postgres Pro обратитесь к разделу Конфигурация Postgres Pro.

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

Помимо встроенных возможностей автоматического аварийного переключения узлов, решение BiHA поддерживает ручное переключение как для стандартных BiHA-кластеров, так и для GDBiHA-кластеров.

Важно

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

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

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

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

При назначении нового лидера или главного последователя происходит следующее:

  • Состояние назначенного узла меняется на FOLLOWER_OFFERED.

  • Все попытки начать выборы блокируются.

  • Текущий лидер меняет своё состояние на LEADER_RO. При переключении главного последователя его состояние остаётся неизменным (FRONT_FOLLOWER).

  • FOLLOWER_OFFERED ищет наиболее актуальный источник репликации в своём сегменте и настраивает репликацию с этого источника.

  • Когда узел в состоянии FOLLOWER_OFFERED обнаруживает, что в кластере отсутствует лидер в состоянии LEADER_RW, и при этом обладает наибольшим количеством данных в рамках сегмента, он становится новым лидером или главным последователем.

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

27.3.4. Управление SSL для служебных подключений #

Можно включать или отключать SSL для служебных подключений в инициализированном BiHA-кластере с помощью параметра конфигурации biha.use_ssl.

  1. Подготовьте сертификат и закрытый ключ.

  2. Чтобы включить SSL, на всех узлах кластера для параметра biha.use_ssl установите значение true:

    ALTER SYSTEM SET biha.use_ssl = true;

    Чтобы отключить SSL, установите значение false.

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

    Важно

    Лидер необходимо останавливать последним, а запускать первым. Так как включение SSL в BiHA-кластере подразумевает использование стандартного процесса начального согласования TLS, рекомендуется минимизировать временной промежуток между остановкой и запуском узлов кластера.

27.3.5. Роли #

При инициализации отказоустойчивого кластера создаётся база данных biha_db, также в схеме biha базы данных biha_db создаётся расширение biha. Кроме того, создаются и используются следующие роли:

  • BIHA_CLUSTER_MANAGEMENT_ROLE — отвечает за выполнение всех функций расширения biha.

  • BIHA_REPLICATION_ROLE — используется при работе pg_rewind.

  • biha_replication_user — является членом ролей BIHA_REPLICATION_ROLE и BIHA_CLUSTER_MANAGEMENT_ROLE и может совершать как клиентские подключения, так и подключения по протоколу репликации. Эта роль используется утилитой bihactl, а также при подключении узла-последователя к узлу-лидеру. Является владельцем базы данных biha_db. Пароль для роли biha_replication_user в файле паролей должен быть одинаковым на всех узлах BiHA-кластера. Пароль предлагается задать во время создания BiHA-кластера.

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

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

27.3.6. Использование сервисного режима #

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

Когда BiHA находится в сервисном режиме:

  • последователи продолжают получать WAL

  • выборы отменяются и ни один узел не может выставить себя кандидатом

  • лидера можно переключить вручную

Сервисным режимом можно управлять, вызвав функцию biha.service_mode на лидере.

С помощью функции biha.service_mode можно выполнить следующие действия:

  • Включить сервисный режим, установив для параметра enable функции biha.service_mode значение true:

    SELECT biha.service_mode(true);

  • Отключить сервисный режим, установив для параметра enable функции biha.service_mode значение false:

    SELECT biha.service_mode(false);

  • При отключении сервисного режима BiHA проверяет, были ли параметры, изменённые в сервисном режиме, применены на всех узлах кластера. Если найдены неприменённые параметры, сервисный режим не отключается, а функция возвращает ошибки с перечислением всех неприменённых параметров. Например:

    biha _db=# SELECT biha.service_mode (false);
ERROR: [BiHA] Config changes
HINT: Some parameters have been changed but not applied:
Node 3: max_connections
To force exit service mode, use: "select * from biha.service_mode(false, true)"

    При необходимости можно отключить сервисный режим, игнорируя ошибки, установив для параметра force функции biha.service_mode значение true:

    SELECT biha.service_mode(false, true);

27.3.7. Автоматическая синхронизация кластера после аварийного переключения #

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

Управлять автоматической синхронизацией в BiHA-кластере можно следующим образом:

  • Включите автоматическую синхронизацию (automatic rewind), установив для параметра конфигурации biha.autorewind значение true. Автоматическая синхронизация выполняется, если она может успешно завершиться, то есть если предварительный запуск инструмента pg_rewind с параметром --dry-run прошёл успешно.

    При неудачной автоматической синхронизации узел переходит в состояние NODE_ERROR. В этом случае фактическое состояние синхронизации узла можно найти в файле biha.state, как описано в Подразделе 27.3.7.1.

    Важно

    В результате синхронизации могут быть утеряны некоторые записи WAL узла.

  • Чтобы избежать запуска pg_rewind в тех случаях, когда расхождение WAL вызвано только лишними записями сообщений о контроле состояния, можно воспользоваться возможностью выравнивания WAL, которая управляется с помощью параметра конфигурации biha.autowaltrim. Когда алгоритм выравнивания WAL включён, он находит последнюю общую точку в журналах WAL отклонившегося узла и нового лидера, проверяет, что все последующие записи содержат только сообщения о контроле состояния, и автоматически удаляет эти лишние записи с отклонившегося узла, чтобы он мог продолжить репликацию. Это удобно в случае, когда произошло разделение кластера (split-brain) и бывший лидер возвращается в кластер в качестве последователя, но не может начать репликацию из-за того, что в его WAL содержатся записи сообщений о контроле состояния, сгенерированные, когда он ещё был лидером.

    Если процедура выравнивания WAL завершается неудачно, состояние узла изменяется на NODE_ERROR.

    Параметры выравнивания WAL можно посмотреть в файле biha.state. За подробной информацией обратитесь к Подразделу 27.3.7.2.

    Важно

    Если в процессе выравнивания WAL происходит отказ кластера и WAL изменяется некорректно, это может привести к потере записей WAL.

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

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

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

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

27.3.7.2. Мониторинг параметров выравнивания WAL #

Параметры выравнивания WAL узлов кластера можно проверить в следующих полях файла biha.state:

  • waltrim_state: текущее состояние выполнения процедуры выравнивания WAL

  • waltrim_common_tli: линия времени последней общей точки

  • waltrim_start_lsn: начало диапазона рассинхронизации WAL, вызванной лишними сообщениями о контроле состояния

  • waltrim_end_lsn: конец диапазона рассинхронизации WAL, вызванной лишними сообщениями о контроле состояния

27.3.8. Восстановление узла из состояния 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, выполните следующие шаги:

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

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

    pg_rewind --biha --target-pgdata=путь_к_каталогу_PGDATA_узла_в_NODE_ERROR --source-server='user=biha_replication_user host=адрес_лидера port=порт_лидера dbname=postgres'

    Важно

    Параметр --biha необходим для сохранения файлов конфигурации расширения biha. Использование 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.9. Механизм защиты от зависания #

BiHA предоставляет специальный защитный механизм, который помогает предотвратить зависание узлов и проблему разделения кластера (split-brain). Механизм работает следующим образом:

  • Если процесс biha не отвечает, когда достигнуто значение biha.watchdog_timeout, узел прекращает принимать запросы и его состояние временно изменяется на NODE_ERROR.

    Примечание

    Запросы от ролей pg_monitor и $BIHA_USER не блокируются.

  • Следующее сообщение в журнале информирует о проблеме: «The request cannot be processed because the BiHA extension is not responding» (Невозможно обработать запрос, так как расширение BiHA не отвечает).

  • В зависимости от того, как быстро восстановится процесс biha, происходит следующее:

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

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

Важно

Если лидер зависает, а другие узлы избирают нового лидера, необходимо восстановить бывшего лидера из состояния NODE_ERROR.

27.3.10. Настройка репликации #

По умолчанию BiHA-кластеры асинхронны. Однако BiHA позволяет создать кластер с кворумной синхронной репликацией.

Кворумная синхронная репликация включается с помощью параметра synchronous_standby_names, где задаётся список имён синхронных резервных узлов и количество синхронных узлов (кворум), ответа от которых должны ожидать транзакции, с методом ANY. За подробной информацией обратитесь к разделу Несколько синхронных резервных серверов. Параметр synchronous_commit используется со значением по умолчанию on.

За подробной информацией обратитесь к следующим разделам:

27.3.10.1. Синхронная репликация и рефери #

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

27.3.10.2. Включение кворумной синхронной репликации #

Включить кворумную синхронную репликацию можно как при инициализации BiHA-кластера, так и позднее в уже существующем BiHA-кластере.

Важно

Включение кворумной синхронной репликации в BiHA-кластере необратимо. После включения кворумной синхронной репликации сделать BiHA-кластер вновь асинхронным невозможно. Однако можно исключить определённые узлы из списка синхронных резервных узлов с помощью функции biha.remove_from_ssn. Исключённый узел будет работать асинхронно.

Включить кворумную синхронную репликацию можно следующим образом:

  • При создании BiHA-кластера с нуля или преобразовании существующего кластера включите кворумную синхронную репликацию с помощью параметра --sync-standbys команды bihactl cluster init.

    Например, если для кластера из трёх узлов в качестве значения параметра --sync-standbys указать 1, synchronous_standby_names будет выглядеть следующим образом:

    ANY 1 (biha_node_1,biha_node_2,biha_node_3)

  • Чтобы включить кворумную синхронную репликацию в существующем BiHA-кластере, используйте функцию biha.set_sync_standbys.

27.3.10.3. Управление репликацией #

Управлять репликацией в BiHA-кластере можно следующим образом:

  • Для просмотра текущего значения параметра synchronous_standby_names используйте функцию biha.get_ssn.

  • Чтобы изменить кворум синхронных резервных узлов, т.е. значение, заданное для метода ANY в параметре synchronous_standby_names, используйте функцию biha.set_sync_standbys. Как правило, это требуется сделать после того, как вы изменили состав BiHA-кластера, добавив узлы с помощью команды bihactl node add или удалив узлы с помощью функции biha.remove_node.

  • Чтобы добавить определённый узел в список синхронных резервных узлов, используйте функцию biha.add_to_ssn.

  • Чтобы добавить несколько узлов в качестве списка синхронных резервных узлов, используйте функцию biha.set_ssn.

  • Чтобы исключить определённый узел из списка синхронных резервных узлов, используйте функцию biha.remove_from_ssn. Исключённый узел будет работать асинхронно.

27.3.10.4. Смягчение ограничений кворумной синхронной репликации #

Ограничения кворумной синхронной репликации можно смягчить, чтобы лидер мог продолжать работу, пока часть синхронных резервных узлов временно недоступна. Чтобы включить нестрогую кворумную синхронную репликацию, укажите значение в поле MIN параметра synchronous_standby_names, задающее минимальное количество синхронных резервных узлов, которые должны быть доступны, чтобы лидер продолжил работу. Параметр synchronous_standby_gap остаётся неизменным и сохраняет своё значение по умолчанию, равное 0.

Управлять нестрогой кворумной синхронной репликацией в BiHA-кластере с кворумной синхронной репликацией можно следующим образом:

  • Чтобы включить нестрогую кворумную синхронную репликацию при инициализации кластера с помощью команды bihactl cluster init, укажите параметр --sync-standbys-min.

    Например, если для кластера из трёх узлов в качестве значения параметра--sync-standbys-min указать 0, synchronous_standby_names будет выглядеть следующим образом:

      ANY 1 MIN 0 (biha_node_1,biha_node_2,biha_node_3)

  • Чтобы включить нестрогую кворумную синхронную репликацию в существующем кластере или изменить минимальное число кворумных синхронных резервных узлов, используйте функцию biha.set_sync_standbys_min.

  • Чтобы отключить нестрогую кворумную синхронную репликацию, с помощью функции biha.set_sync_standbys_min установите значение -1 в качестве минимального числа синхронных резервных узлов.

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

Каскадную репликацию можно настроить при инициализации кластера BiHA или GDBiHA с нуля с помощью утилиты bihactl. Затем можно изменить параметры каскадной репликации следующим образом:

  • Чтобы ограничить максимальное число подключений репликации к определённому узлу с других узлов в кластере BiHA или GDBiHA, укажите значение параметра конфигурации biha.max_replicas с помощью функции biha.set_max_replicas.

    Например, в трёхузловом кластере, состоящем из двух последователей (F1 и F2) и лидера, для параметра biha.max_replicas лидера укажите значение 1. В этом случае, если последователь F1 первым начнёт репликацию, он будет реплицировать данные с лидера. Последователь F2 установит каскадную репликацию с последователя F1 (при условии, что значение параметра biha.preferred_roles последователя F2 содержит F), так как лимит подключений лидера исчерпан.

  • Чтобы установить приоритетность узла при выборе источника репликации, укажите значение параметра конфигурации biha.priority с помощью функции biha.set_priority.

    Например, в трёхузловом кластере, состоящем из двух последователей (F1 и F2) и лидера, установите для параметра biha.priority последователя F1 значение 10000, а для последователя F2 — 20000. Если оба последователя одновременно начнут поиск источника репликации, последователь F1 первым подключится к лидеру.

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

    Например, если для параметра biha.preferred_roles последователя F1 установлено значение FL, этот последователь сначала выберет в качестве источника репликации другого последователя. Если попытка подключения окажется неуспешной, последователь F1 подключится к лидеру.

  • Обратите внимание, что параметр конфигурации biha.no_wal_on_follower влияет на репликацию в каскадном BiHA-кластере. Если узел не получает WAL в течение времени, заданного в biha.no_wal_on_follower, он начинает искать новый источник репликации в соответствии с конфигурацией biha.preferred_roles.

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

BiHA записывает в журнал сообщения от своих компонентов:

  • Управляющий канал BiHA: управляющий канал используется для обмена служебной информацией между узлами, в журнале отмечен как BCP.

  • Node Controller: основной компонент расширения biha, ответственный за логику работы узла, в журнале отмечен как NC.

  • Postgres Controller: компонент biha, необходимый для управления и мониторинга компонентов Postgres Pro, таких как настройка репликации, параметры конфигурации, процессы walsender и walreceiver и т.д. Postgres Controller доводит Postgres Pro до состояния, необходимого для работы BiHA. В журнале Postgres Controller помечен как PGC.

  • Config Controller: конфигурационный модуль, который управляет конфигурацией узла (параметры GUC и biha.conf) и синхронизирует её на узлах кластера. В журнале Config Controller помечен как BC.

Можно определить типы сообщений, которые будут вноситься в журнал, установив соответствующий уровень протоколирования. BiHA поддерживает как стандартные уровни важности сообщений Postgres Pro, так и уровни протоколирования самого расширения.

Уровни важности сообщений Postgres Pro используются расширением biha в следующих случаях:

  • Когда один из процессов biha завершается ошибкой (уровни ERROR и FATAL).

  • Когда вызывается функция ядра, которая принимает уровень протоколирования в качестве своего аргумента.

Уровни протоколирования biha соответствуют уровням важности сообщений Postgres Pro. Если в журнале должны появляться сообщения необходимого уровня, установленное для этого уровня значение должно соответствовать значению в log_min_messages. Уровни протоколирования расширения можно настроить, указав соответствующие параметры конфигурации в файле postgresql.biha.conf.

Рекомендуемая конфигурация уровней протоколирования выглядит следующим образом:

biha.BcpTransportWarn_log_level = WARNING
biha.BcpTransportLog_log_level = LOG
biha.BcpTransportDetails_log_level = DEBUG1
biha.BcpTransportDebug_log_level = DEBUG1
biha.NodeControllerLog_log_level = LOG
biha.NodeControllerWarn_log_level = WARNING
biha.NodeControllerDetails_log_level = DEBUG1
biha.NodeControllerDebug_log_level = DEBUG1

Примечание

Такая конфигурация отображает сообщения только для уровней протоколирования biha.BcpTransportLog_log_level, biha.BcpTransportWarn_log_level, biha.NodeControllerLog_log_level и biha.NodeControllerWarn_log_level. Чтобы просматривать подробные и отладочные сообщения журнала, для параметра log_min_messages задайте значение DEBUG1.

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

Обработчик — это SQL-функция, которая уведомляет пользователей или внешние сервисы о событиях в BiHA-кластере, например о выборах нового лидера или изменении конфигурации кластера. Как пользователь, вы создаёте SQL-функцию и регистрируете её в качестве обработчика. При определённых условиях biha вызовет эту функцию.

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

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

Таблица 27.2. Типы обработчиков

ИмяОписание
CANDIDATE_TO_LEADER

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

Сигнатура:

my_callback() RETURNS void
LEADER_CHANGE_STARTED

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

Функция-обработчик активируется, когда число узлов достигает значения biha.nquorum и становится возможным провести выборы.

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

Важно

Когда вы устанавливаете нового лидера с помощью функции biha.set_leader, старый лидер немедленно перезапускается, и функция-обработчик LEADER_CHANGE_STARTED на нём может не выполниться. В этом случае функция-обработчик сохраняется как отложенная и затем выполняется на старом лидере после его перезапуска. Если время перезапуска превышает тайм-аут сообщений о контроле состояния, выполнение функции-обработчика отменяется. Значение тайм-аута сообщений о контроле состояния рассчитывается как biha.heartbeat_max_lost * biha.heartbeat_send_period.

Сигнатура:

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

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

LEADER_CHANGED

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

Сигнатура:

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

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

LEADER_STATE_IS_RW

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

Сигнатура:

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

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

LEADER_TO_FOLLOWER

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

Сигнатура:

my_callback() RETURNS void
NODE_ADDED

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

Сигнатура:

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

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

NODE_REMOVED

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

Сигнатура:

my_callback(id integer) RETURNS void

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

OFFERED_TO_LEADER

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

Сигнатура:

my_callback() RETURNS void
STATUS_CHANGED

Вызывается на каждом узле при изменении значений в полях представления biha.status_v (кроме since_last_hb).

Примечание

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

Сигнатура:

my_callback() RETURNS void
TERM_CHANGED

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

Сигнатура:

my_callback(old_term integer, new_term integer) RETURNS void

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


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

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

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

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

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

  • Не рекомендуется вызывать функции BiHA во время выполнения обработчика, так как другие обработчики в очереди могут не выполниться.

Примечание

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

27.3.12.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.13. Управление расширением proxima #

Вы можете включать или отключать расширение proxima в существующем BiHA-кластере, а также проверять его текущий статус.

Включение и отключение расширения proxima

  1. На лидере вызовите одну из следующих функций из базы данных biha_db:

    • Чтобы включить расширение proxima, вызовите функцию biha.enable_proxima:

      SELECT biha.enable_proxima();

    • Чтобы отключить расширение proxima, вызовите функцию biha.disable_proxima:

      SELECT biha.disable_proxima();

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

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

Проверка статуса расширения proxima

  • На любом узле BiHA-кластера выполните следующую команду:

    SHOW biha.proxima_status;

    В результате отобразится текущий статус расширения proxima на этом узле. За подробной информацией о возможных статусах обратитесь к описанию параметра biha.proxima_status.

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

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

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

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

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

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

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

  3. Остановите восстановленный узел с помощью pg_ctl:

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

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

  5. Запустите восстановленный узел с помощью pg_ctl:

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

27.3.15. Обновление и миграция #

В зависимости от вашей текущей версии Postgres Pro Enterprise обратитесь к одному из следующих разделов:

27.3.15.1. Миграция на версию 18.X #

BiHA поддерживает следующие варианты миграции BiHA-кластера на основную версию:

27.3.15.1.1. Миграция BiHA-кластера на версию 18.X с помощью pg_upgrade #

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

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

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

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

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

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

  6. (Необязательно) Чтобы добавить рефери:

    1. На бывшем узле-рефери удалите каталог PGDATA.

    2. Создайте рефери с нуля.

27.3.15.1.2. Миграция BiHA-кластера на версию 18.X с минимальным простоем #

Используйте эту инструкцию для миграции BiHA-кластера с Postgres Pro Enterprise версии 17.X на версию 18.X, если временную остановку работы базы данных необходимо свести к минимуму.

Для ясности в этой инструкции текущий BiHA-кластер, миграцию которого вы выполняете, называется «старый кластер», а обновлённый BiHA-кластер — «новый кластер».

Этот метод миграции обеспечивается специальными командами утилиты bihactl, разработанными для автоматизации шагов по миграции. Во время миграции вы создадите лидера нового кластера на отдельном сервере и затем переместите последователей из старого кластера в новый. Это позволит старому кластеру продолжить работу и оставаться отказоустойчивым на протяжении всего процесса миграции, в то время как новый кластер с версией Postgres Pro Enterprise 18.X получит все обновления по логической репликации и возьмёт на себя нагрузку только после завершения миграции и настройки отказоустойчивости.

Важно

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

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

  • Все операции по миграции необходимо выполнять от имени пользователя postgres.

Процедура миграции состоит из следующих шагов:

Предварительные требования

  1. Убедитесь, что выполнены все условия, перечисленные в разделе Предварительные требования и особенности.

  2. Подготовьте отдельный дополнительный сервер, который будет использоваться для развёртывания лидера нового кластера с версией Postgres Pro Enterprise 18.X. Операционная система и исполняемые файлы Postgres Pro Enterprise, установленные на дополнительном сервере, должны быть такими же, как и на узлах старого кластера.

  3. Убедитесь, что базы данных старого кластера доступны с подготовленного дополнительного сервера. Если доступа нет, обеспечьте его в файле pg_hba.biha.conf лидера старого кластера.

  4. На всех узлах старого кластера и дополнительном сервере установите Postgres Pro Enterprise версии 18.X.

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

    • Для параметра wal_level задайте значение logical.

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

    • Учитывайте все ограничения логической репликации на протяжении всего процесса миграции.

    • Ограничьте операции DCL и DDL на время всего процесса миграции. На старом лидере во время миграции разрешены только операции DML, т.е. непосредственно изменение данных.

    • Убедитесь, что во всех обновляемых таблицах присутствуют первичные ключи.

    • Обеспечьте минимальную нагрузку на лидера старого кластера.

Подготовка нового лидера

Лидер нового кластера создаётся на дополнительном сервере, который вы подготовили заранее.

При создании нового лидера команда bihactl upgrade start выполняет следующие действия:

  • Создаёт последователя с Postgres Pro Enterprise версии 17.X.

  • Удаляет последователя из старого кластера, оставляя его в качестве физической реплики с Postgres Pro Enterprise версии 17.X.

  • Конвертирует физическую реплику в логическую.

  • Обновляет логическую реплику до Postgres Pro Enterprise версии 18.X.

  • Преобразовывает логическую реплику с Postgres Pro Enterprise версии 18.X в лидера нового кластера.

Примечание

После выполнения команды bihactl upgrade start новый лидер будет недоступен для любых подключений, кроме внутренних подключений через сокет Unix, до завершения миграции с помощью команды bihactl upgrade finish.

Чтобы подготовить нового лидера:

  1. На лидере старого кластера получите «магическую» строку:

    SELECT biha.get_magic_string();

  2. На подготовленном дополнительном сервере выполните команду bihactl upgrade start:

    bihactl upgrade start \
        --magic-string=магическая_строка_старого_лидера \
        --new-leader-biha-port=порт_biha_нового_лидера \
        --new-leader-host=хост_нового_лидера \
        --new-leader-port=порт_нового_лидера \
        --old-bin=/путь/к/исполняемым/файлам/версии_17 \
        --old-pgdata=каталог_PGDATA_версии_17 \
        --new-pgdata=каталог_PGDATA_версии_18 \
        --username=postgres

    Каталоги PGDATA_версии_17 и PGDATA_версии_18 должны быть пусты.

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

    Подсказка

    Также в выводе команды присутствует «магическая» строка нового лидера. Можно скопировать её и сохранить для использования на следующих этапах миграции.

  3. Запустите нового лидера с помощью pg_ctl:

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

  4. Убедитесь, что новый лидер находится в состоянии LEADER_RW, с помощью представления biha.status_v:

    SELECT * FROM biha.status_v;

  5. На новом лидере проверьте подписки с помощью каталога pg_subscription:

    SELECT subname, subpublications FROM pg_subscription;

  6. На старом лидере выполните следующие действия:

    • Проверьте слоты репликации с помощью представления pg_replication_slots:

      SELECT slot_name, slot_type FROM pg_replication_slots;

    • Проверьте публикации с помощью каталога pg_publication:

      SELECT * FROM pg_publication;

    • Убедитесь, что нет отставания:

      /путь/к/исполняемым/файлам/версии_17/psql biha_db -qtAXc "SELECT sum(pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn)) AS lag_bytes FROM pg_replication_slots where slot_type = 'logical';"

Перемещение последователя

Извлеките одного из последователей из старого кластера и добавьте его в новый кластер. Повторите эту процедуру для перемещения нескольких последователей из старого кластера в новый, чтобы обеспечить отказоустойчивость нового кластера после миграции.

Важно

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

  • При перемещении последователя его параметры конфигурации Postgres Pro копируются с нового лидера. Поэтому, если на последователе были заданы какие-либо специфичные для него параметры конфигурации Postgres Pro, необходимо вновь задать их вручную после перемещения.

Чтобы переместить последователя:

  1. Чтобы обеспечить работоспособность старого кластера после удаления последователя, уменьшите значения параметров minnodes, sync_standbys и sync_standbys_min с помощью функций biha.set_minnodes, biha.set_sync_standbys и biha.set_sync_standbys_min соответственно.

    Значения параметров конфигурации minnodes, sync_standbys и sync_standbys_min всегда должны быть ниже, чем общее количества узлов кластера. Текущие значения можно проверить с помощью функции biha.config.

  2. (Необязательно) Если вы не сохранили «магическую» строку на предыдущем шаге, получите её на лидере нового кластера:

    SELECT biha.get_magic_string();

  3. На последователе, который вы хотите переместить, выполните команду bihactl upgrade move:

    bihactl upgrade move \
  --new-magic-string=магическая_строка_нового_лидера \
  --old-bin=/путь/к/исполняемым/файлами/версии_17 \
  --new-pgdata=каталог_PGDATA_версии_18 \
  --old-pgdata=каталог_PGDATA_версии_17

    Переменная каталог_PGDATA_версии_17 — это каталог PGDATA работающего старого последователя. каталог_PGDATA_версии_18 предназначен для обновлённого нового последователя и должен быть пустым.

  4. Запустите перемещённого последователя с помощью pg_ctl:

    pg_ctl start -D каталог_PGDATA_перемещённого_последователя -l файл_журнала_перемещённого_последователя

  5. Проверьте статус нового кластера с помощью команды bihactl cluster status.

Завершение миграции

Важно

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

  1. Отключите нагрузку на старом лидере и дождитесь, когда новый лидер завершит получение данных по логической репликации.

  2. Чтобы убедиться, что данные получены в полном объёме, на старом лидере выполните следующую команду:

    /путь/к/исполняемым/файлам/версии_17/psql biha_db -qtAXc "SELECT sum(pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn)) AS lag_bytes FROM pg_replication_slots where slot_type = 'logical';"

    В выводе должно отображаться значение 0 для lag_bytes.

  3. Но новом лидере выполните команду bihactl upgrade finish:

    bihactl upgrade finish \
  --new-magic-string=магическая_строка_нового_лидера \
  --username=postgres

    Выполнение команды приводит к следующим результатам:

    • Состояние старого лидера изменяется на LEADER_RO.

    • Новый лидер выходит из сервисного режима и становится доступным для транзакций на запись.

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

    • Параметры minnodes, sync_standbys и sync_standbys_min возвращаются к изначальным значениям, заданным на старом лидере до начала миграции.

  4. На старом лидере обновите значения последовательностей для всех баз данных с помощью следующей команды:

    /путь/к/исполняемым/файлам/версии_17/psql biha_db -qtAXc "SELECT 'SELECT setval(' || quote_literal(sequencename) || ', ' || last_value || ', true);' FROM pg_sequences;"

  5. Скопируйте вывод команды, выполненной на предыдущем шаге, и выполните его на новом лидере.

  6. Перенастройте подключения приложений и клиентов на новый кластер.

  7. На новом кластере возобновите нагрузку, которая была отключена на старом лидере в начале этой процедуры.

27.3.15.2. Обновление BiHA-кластера с версии 18.1 на версию 18.3 #

Используйте эту инструкцию для обновления с Postgres Pro Enterprise версии 18.1 на версию 18.3.

  1. Остановите одного из последователей с помощью команды pg_ctl.

  2. Обновите последователя.

  3. Запустите последователя с помощью команды pg_ctl.

  4. Повысьте обновлённого последователя до лидера с помощью функции biha.set_leader.

  5. Остановите, обновите и запустите остальных последователей и старого лидера.

  6. Повысьте старого лидера с помощью функции biha.set_leader.

  7. На лидере обновите расширение с помощью следующей команды:

    ALTER EXTENSION biha UPDATE;

    Важно

    Не поддерживается обновление версии расширения biha на рефери в режиме referee. Удалите рефери с помощью функции biha.remove_node, удалите его каталог PGDATA, а затем создайте новый узел-рефери с нуля.

    За подробной информацией об изменениях версий расширений обратитесь к замечаниям к выпускам.

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

Можно временно выключить расширение biha в кластере. Процедуры выключения различаются в зависимости от роли узла.

Выключение biha на последователе

Важно

При выключении расширения biha на последователе физическая репликация прекращается.

  1. На лидере в состоянии LEADER_RW вызовите функцию biha.remove_node, чтобы исключить из кластера узел, на котором необходимо выключить biha:

    SELECT biha.remove_node(идентификатор_узла);

  2. На последователе выполните следующие действия:

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

    2. Удалите расширение biha из shared_preload_libraries в файле postgresql.conf и, если применимо, в файле postgresql.auto.conf.

    3. Остановите и запустите последователя с помощью pg_ctl.

Выключение biha на лидере

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

  2. Удалите расширение biha из shared_preload_libraries в файле postgresql.conf и, если применимо, в файле postgresql.auto.conf.

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

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

Можно полностью удалить расширение biha и навсегда отключить функциональность BiHA в кластере.

  1. В зависимости от роли узла отключите расширение biha, воспользовавшись соответствующей инструкцией.

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

    biha_db=# DROP EXTENSION biha;

  3. Удалите все файлы из каталога pg_biha на всех узлах.

Пред. Наверх След.
27.2. Подготовка BiHA-кластера Начало 27.4. Справка по расширению biha