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. Восстановление узла из состояния NODE_ERROR
27.3.8. Настройка репликации
27.3.9. Протоколирование
27.3.10. Функции-обработчики
27.3.11. Управление расширением proxima
27.3.12. Восстановление из резервной копии
27.3.13. Миграция
27.3.14. Выключение расширения biha
27.3.15. Удаление расширения biha

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

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

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

  • Чтобы удалить узел, используйте функцию 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);

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

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

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

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

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

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

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

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

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

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

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

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 и 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-кластера.

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

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

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

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

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

    Важно

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

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

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

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

    Важно

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание

  • Если узел перешел в состояние NODE_ERROR из-за других проблем, например, по причине переполнения слота репликации, после устранения первопричины можно вызвать функцию biha.reset_node_error для сброса состояния 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.8. Настройка репликации #

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

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

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

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

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

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

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

Важно

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

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

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

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

    ANY 2 (biha_node_1,biha_node_2,biha_node_3)

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

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

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

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

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

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

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

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

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

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

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

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

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

      ANY 2 MIN 0 (biha_node_1,biha_node_2,biha_node_3)

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

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

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

Расширение 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.BcpTransportWarn_log_level = WARNING
biha.BcpTransportLog_log_level = LOG
biha.BcpTransportDetails_log_level = DEBUG1
biha.BcpTransportDebug_log_level = DEBUG1
biha.BcpTransportSSLDebug_log_level = DEBUG2
biha.NodeControllerLog_log_level = LOG
biha.NodeControllerWarn_log_level = WARNING
biha.NodeControllerDetails_log_level = DEBUG1
biha.NodeControllerDebug_log_level = DEBUG1
log_min_messages = DEBUG1

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

Обработчик — это 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 передаёт информацию о потерянном лидере: ID, имя узла и номер порта узла.

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, имя узла и номер порта узла.

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.10.1. Особенности и ограничения #

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

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

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

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

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

Примечание

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

27.3.10.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.11. Управление расширением 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-кластера выполните следующую команду:

    SELECT biha.proxima_status;

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

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

Если экземпляр базы данных был восстановлен из одного из узлов кластера 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 add с параметром --convert-standby.

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

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

27.3.13. Миграция #

В зависимости от текущей версии Postgres Pro Enterprise, используйте одну из следующих процедур для обновления BiHA-кластера:

27.3.13.1. Миграция BiHA-кластера с версии 16.X на версию 17.X #

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

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

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

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

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

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

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

27.3.13.2. Миграция BiHA-кластера в состоянии LEADER_RW #

Используйте эту инструкцию для следующих вариантов миграции:

  • с версий 17.2, 17.4, 17.5 на версию 17.6

  • с версий 17.2 или 17.4 на версию 17.5

  • с версии 17.2 на версию 17.4

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

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

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

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

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

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

27.3.14. Выключение расширения 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.15. Удаление расширения 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