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. Восстановление из резервной копии
- 27.3.12. Миграция
- 27.3.13. Выключение расширения biha
- 27.3.14. Удаление расширения biha
- 27.3.2. Изменение конфигурационных параметров
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.
Чтобы включить SSL, на всех узлах кластера для параметра biha.use_ssl установите значение
true
:ALTER SYSTEM SET biha.use_ssl = true;
Чтобы отключить SSL, установите значение
false
.Остановите и запустите узлы с помощью 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
: текущее состояние выполнения процедуры выравнивания WALwaltrim_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
, выполните следующие шаги:
Сохраните последние файлы из каталога
pg_wal
, так как некоторые уникальные для этого узла файлы будут перезаписаны утилитой pg_rewind.Чтобы сохранить файлы конфигурации 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 исходного сервера на момент синхронизации.(Необязательно) Если узел был недоступен долгое время, на восстановленном узле установите для параметра 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, старый лидер немедленно перезапускается, и функция-обработчик Сигнатура: 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 | Вызывается на лидере и других узлах, когда состояние лидера изменяется на Сигнатура: 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 передаёт в функцию-обработчик информацию о новом узле, такую как имя узла, номер порта узла и режим работы: |
NODE_REMOVED | Вызывается на каждом узле при удалении узла из BiHA-кластера. Сигнатура: my_callback(id integer) RETURNS void В этой сигнатуре biha передаёт в функцию-обработчик ID удалённого узла. |
OFFERED_TO_LEADER | Вызывается на узле, который был назначен лидером вручную, перед непосредственным переходом в статус лидера. Сигнатура: my_callback() RETURNS void |
STATUS_CHANGED | Вызывается на каждом узле при изменении значений в полях представления biha.status_v (кроме ПримечаниеНе рекомендуется выполнять другие обработчики во время использования Сигнатура: my_callback() RETURNS void |
TERM_CHANGED | Вызывается на узле, когда значение его параметра Сигнатура: my_callback(old_term integer, new_term integer) RETURNS void В этой сигнатуре biha передаёт старое и новое значение параметра |
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 и зарегистрируете их в качестве обработчиков разных типов.
Убедитесь, что лидер BiHA-кластера находится в состоянии
LEADER_RW
.На лидере используйте
psql
для подключения к базе данныхbiha_db
:postgres=# \c biha_db
Создайте следующие функции-обработчики:
-- запись при смене значения term CREATE FUNCTION log_term_changed(old_term integer, new_term integer) RETURNS void AS $$ BEGIN RAISE LOG 'Callback: Term changed from % to %', old_term, new_term; END; $$ LANGUAGE plpgsql; -- запись при смене лидера CREATE FUNCTION log_leader_changed(id integer, host text, port integer) RETURNS void AS $$ BEGIN RAISE LOG 'Callback: New leader is % %:%', id, host, port; END; $$ LANGUAGE plpgsql; -- запись при понижении лидера CREATE FUNCTION log_leader_to_follower() RETURNS void AS $$ BEGIN RAISE LOG 'Callback: demote'; END; $$ LANGUAGE plpgsql;
Зарегистрируйте созданные функции:
SELECT biha.register_callback('TERM_CHANGED', 'log_term_changed', 'biha_db'); SELECT biha.register_callback('LEADER_CHANGED', 'log_leader_changed', 'biha_db'); SELECT biha.register_callback('LEADER_TO_FOLLOWER', 'log_leader_to_follower', 'biha_db');
Вы также можете указать пользователя, от имени которого будут исполняться функции-обработчики или определить порядок их исполнения. Подробнее читайте в описании функции biha.register_callback.
Просмотр функций-обработчиков
Зарегистрированные обработчики добавляются в таблицу biha.callbacks
, которая находится в базе данных biha_db
.
Для просмотра всех зарегистрированных обработчиков выполните следующую команду:
На лидере используйте
psql
для подключения к базе данныхbiha_db
:postgres=# \c biha_db
Отобразите содержимое таблицы
biha.callbacks
:SELECT * FROM biha.callbacks; 1 | log_term_changed 2 | log_leader_changed 3 | log_leader_to_follower (3 rows)
Отмена регистрации функции-обработчика
Отменённый обработчик удаляется из таблицы biha.callbacks
.
Убедитесь, что лидер BiHA-кластера находится в состоянии
LEADER_RW
.На лидере используйте
psql
для подключения к базе данныхbiha_db
:postgres=# \c biha_db
Получите идентификатор обработчика, который вы хотите отменить, например
log_leader_changed
:SELECT id FROM biha.callbacks WHERE func = 'log_leader_changed';
Возвращается идентификатор обработчика, например
2
.Отменить регистрацию обработчиков:
SELECT biha.unregister_callback(2);
Регистрация обработчика отменена.
27.3.11. Восстановление из резервной копии #
Если экземпляр базы данных был восстановлен из одного из узлов кластера BiHA в отдельный узел и/или на момент времени (Point-in-Time Recovery, PITR), между восстановленным узлом и работающими узлами кластера BiHA не должно быть соединения. Чтобы предотвратить соединение, выполните следующие действия на восстановленном узле перед его запуском:
Удалите директиву включения
include 'postgresql.biha.conf'
из файла конфигурации postgresql.conf.Убедитесь, что расширение biha отсутствует в shared_preload_libraries в файле postgresql.conf и, если применимо, в файле postgresql.auto.conf.
Если вы хотите добавить восстановленный узел в кластер, выполните следующие действия:
На восстановленном узле вручную настройте потоковую репликацию от лидера.
Синхронизируйте восстановленный узел с лидером.
Остановите восстановленный узел с помощью pg_ctl:
pg_ctl stop -D
каталог_PGDATA_восстановленного узла
Добавьте восстановленный узел в кластер с помощью команды
bihactl
add с параметром --convert-standby.Запустите восстановленный узел с помощью pg_ctl:
pg_ctl start -D
каталог_PGDATA_восстановленного узла
27.3.12. Миграция #
В зависимости от текущей и целевой версии Postgres Pro Enterprise, можно обновить BiHA-кластер в состоянии LEADER_RO
, или LEADER_RW
.
За дополнительными сведениями обратитесь к следующим разделам.
27.3.12.1. Миграция BiHA-кластера в состоянии LEADER_RW
#
Используйте эту инструкцию для следующих вариантов миграции:
с версий 16.4, 16.6, 16.8 или 16.9 на версию 16.10
с версий 16.4, 16.6 или 16.8 на версию 16.9
с версий 16.4 или 16.6 на версию 16.8
с версии 16.4 на версию 16.6
с версий 16.1 или 16.2 на версию 16.3
Выполните следующие шаги:
Остановите одного из последователей с помощью команды
pg_ctl
.Обновите последователя.
Запустите последователя с помощью команды
pg_ctl
.Повысьте обновлённого последователя до лидера с помощью функции biha.set_leader.
Остановите, обновите и запустите остальных последователей и старого лидера.
Повысьте старого лидера с помощью функции biha.set_leader.
Важно
Обратите внимание, что если узел с версией Postgres Pro Enterprise 16.1 переходит в состояние NODE_ERROR
, узлы с более новыми версиями могут некорректно определять состояние такого узла, например как REFEREE
. В этом случае рекомендуется остановить узел, обновить его версию, синхронизировать его с помощью pg_rewind и вновь запустить.
27.3.12.2. Миграция BiHA-кластера в состоянии LEADER_RO
#
Используйте эту инструкцию для перехода с версий 16.1, 16.2 или 16.3 на версии 16.4, 16.6, 16.8, 16.9 или 16.10.
С помощью функции biha.set_nquorum_and_minnodes установите для параметров
nquorum
иminnodes
значения больше, чем количество узлов в кластере.Например, если кластер состоит из 3 узлов, установите для вышеуказанных параметров значение
4
. Это необходимо, чтобы избежать неожиданных выборов лидера и изменить состояние лидера сLEADER_RW
наLEADER_RO
.Дождитесь, пока последователи нагонят лидера, и убедитесь, что столбец
replay_lag
в представлении pg_stat_replication содержитNULL
.Остановите одного из последователей с помощью команды
pg_ctl
.Обновите последователя.
Запустите последователя с помощью команды
pg_ctl
.Повысьте обновлённого последователя до лидера с помощью функции biha.set_leader.
Остановите, обновите и запустите остальных последователей и старого лидера.
Повысьте старого лидера с помощью функции biha.set_leader.
С помощью функции biha.set_nquorum_and_minnodes установите для параметров
nquorum
иminnodes
те значения, которые были установлены до начала обновления Postgres Pro Enterprise.
Важно
Обратите внимание, что если узел с версией Postgres Pro Enterprise 16.1 переходит в состояние NODE_ERROR
, узлы с более новыми версиями могут некорректно определять состояние такого узла, например как REFEREE
. В этом случае рекомендуется остановить узел, обновить его версию, синхронизировать его с помощью pg_rewind и вновь запустить.
27.3.13. Выключение расширения biha #
Можно временно выключить расширение biha в кластере. Процедуры выключения различаются в зависимости от роли узла.
Выключение biha на последователе
Важно
При выключении расширения biha на последователе физическая репликация прекращается.
На лидере в состоянии
LEADER_RW
вызовите функцию biha.remove_node, чтобы исключить из кластера узел, на котором необходимо выключить biha:SELECT biha.remove_node(
идентификатор_узла
);На последователе выполните следующие действия:
Удалите директиву включения
include 'postgresql.biha.conf'
из файла конфигурации postgresql.conf.Удалите расширение biha из shared_preload_libraries в файле postgresql.conf и, если применимо, в файле postgresql.auto.conf.
Остановите и запустите последователя с помощью pg_ctl.
Выключение biha на лидере
Удалите директиву включения
include 'postgresql.biha.conf'
из файла конфигурации postgresql.conf.Удалите расширение biha из shared_preload_libraries в файле postgresql.conf и, если применимо, в файле postgresql.auto.conf.
Остановите и запустите узел-лидер с помощью pg_ctl.
27.3.14. Удаление расширения biha #
Можно полностью удалить расширение biha и навсегда отключить функциональность BiHA в кластере.
В зависимости от роли узла отключите расширение biha, воспользовавшись соответствующей инструкцией.
Выполните команду
DROP EXTENSION
. Её необходимо выполнить на лидере в состоянииLEADER_RW
и из базы данныхbiha_db
:biha_db=# DROP EXTENSION biha;
Удалите все файлы из каталога
pg_biha
на всех узлах.