О механизме auto-failover
Содержание раздела
Система обладает встроенным механизмом auto-failover, автоматически переключающим ADP-датасорсы в случае сбоя. Это исключает необходимость использования внешних оркестраторов, таких как HAProxy, Patroni или etcd, что снижает сложность архитектуры и повышает ее отказоустойчивость.
Если механизм auto-failover настроен и включен, после ввода датасорсов обратно в строй система восстановит данные, включит датасорсы и начнет снова вовлекать их в исполнении запросов.
Механизм auto-failover доступен только для ADP-датасорсов.
Во всех ADP-датасорсах должен быть установлен модуль postgres_fdw. Иначе восстановление данных механизмом auto-failover будет невозможно.
Возможности auto-failover
Механизм auto-failover:
- периодически проверяет физическую доступность датасорсов;
- отключает датасорсы, ставшие недоступными, и перенаправляет запросы в оставшиеся датасорсы;
- восстанавливает и включает сбойные датасорсы, снова ставшие доступными.
На схеме ниже показан порядок работы auto-failover с восстановлением одного сбойного датасорса.
Автоматические отключение, восстановление и включение сбойного датасорса
Определение физической доступности датасорсов
Ноды кластера периодически проверяют физическую доступность датасорсов, выносят свои вердикты и сообщают их лидеру кластера. Проверки и сообщение вердиктов выполняются с интервалом AUTOFAILOVER_CHECK_PERIOD_MS (по умолчанию — 10 секунд), чтобы избежать ложных срабатываний из-за мигания сети.
Лидер кластера выносит вердикт кластера о состоянии каждого датасорса по мнению большинства нод. Если состояние изменилось, лидер в зависимости от изменения отключает датасорс или восстанавливает и включает его.
Состояние датасорсов можно проверить запросом GET_HEALTH_STATE. Вердикты нод возвращаются в столбце vote, вердикты кластера — в столбце state.
Вердикты отдельных нод
Каждая нода, включая лидера, периодически определяет состояние датасорсов:
- включенный датасорс считается физически доступным, пока количество его неуспешных ответов подряд меньше
AUTOFAILOVER_FAILS_LIMIT(по умолчанию — меньше 3); - отключенный датасорс считается физически недоступным, пока количество его успешных ответов подряд меньше
AUTOFAILOVER_HEALING_CONFIRM(по умолчанию — меньше 3).
Неуспешным ответом датасорса считается ответ с кодом ошибки или отсутствие ответа, успешным — ответ с успешным кодом.
Запрос GET_HEALTH_STATE возвращает вердикты нод в столбце vote.
Вердикт кластера
Лидер периодически определяет итоговое состояние датасорсов по мнению кластера:
- включенный датасорс считается физически доступным (
healthy), пока большинство нод, включая лидера, считает его таким; - отключенный датасорс считается физически недоступным (
not healthy), пока большинство нод, включая лидера, считает его таким.
При отсутствии кворума нод сохраняется последний вердикт кластера.
Запрос GET_HEALTH_STATE возвращает вердикты кластера в столбце state.
Отключение недоступных датасорсов
Если большинство нод решило, что включенный датасорс недоступен, лидер отключает его для логических БД окружения и перестает вовлекать в исполнения запросов к данным.
Перенаправление запросов во включенные датасорсы
Запросы к данным
Запросы на чтение, запись и проверку* данных распределяются по включенным датасорсам. Отключенные датасорсы пропускаются, даже если они физически доступны.
Для записи данных требуется достаточное количество включенных датасорсов, для чтения и проверки данных — только один, подходящий для исполнения запроса.
* Запросы проверки данных — это CHECK_DATA, CHECK_SUM и CHECK_SUM_SNAPSHOT.
Синхронизация материализованных представлений
Синхронизация материализованных представлений сохраняет изменения только во включенные датасорсы-приемники. Отключенные датасорсы пропускаются, даже если физически доступны.
Синхронизация считается успешной, если изменения текущего цикла сохранены в достаточное количество датасорсов-приемников. В противном случае система отменяет изменения и приостанавливает синхронизацию до восстановления и включения недостающих датасорсов.
Если отключен датасорс-источник, синхронизация зависящих от него представлений приостанавливается до его восстановления и включения.
Достаточное количество датасорсов для записи данных
Запись данных считается успешной, если данные удалось сохранить в количество включенных датасорсов, указанное в таблице ниже. Это относится к загрузке и обновлению данных в обычных логических таблицах, а также синхронизации материализованных представлений.
| Датасорсы сущности | Условие успешной записи данных |
|---|---|
| Включают ADP | Запись в минимум ADP-датасорсов из: * AUTOFAILOVER_MIN_SYNC_REPLICAS (по умолчанию — 1), * количество ADP-датасорсов сущности |
| Не включают ADP | Запись в один датасорс любого типа |
Пример 1:
- датасорсы сущности:
adp,adp2,adp3; - значение
AUTOFAILOVER_MIN_SYNC_REPLICAS: 1; - достаточные датасорсы для записи: любой из [
adp,adp2,adp3].
Пример 2:
- датасорсы сущности:
adp,adb; - значение
AUTOFAILOVER_MIN_SYNC_REPLICAS: 2; - достаточные датасорсы для записи:
adp.
Пример 3:
- датасорсы сущности:
adb,adb2; - значение
AUTOFAILOVER_MIN_SYNC_REPLICAS: 2; - достаточные датасорсы для записи: любой из [
adb,adb2].
Параметр AUTOFAILOVER_MIN_SYNC_REPLICAS не применяется к партиционированным таблицам и партициям: для записи в них достаточно одного включенного ADP-датасорса.
Повторные попытки записи данных в случае ошибки
Ошибки записи в достаточное количество включенных датасорсов не приводят к немедленному завершению операции с ошибкой.
Система повторяет попытки записи в течение AUTOFAILOVER_FAILED_RETRY_TIMEOUT_MS. Если за это время данные удалось записать в достаточное количество датасорсов, операция записи завершается успешно; иначе — операция завершается с ошибкой.
Переповторы выполняются при обновлении и потоковой загрузке данных в логические таблицы, а также при синхронизации материализованных представлений. При ошибках загрузки данных из Kafka переповторы не делаются — система сразу возвращает ошибку.
При переповторах значения rowsAffected и rowsAdded могут быть некорректными.
DDL-запросы
Запрос на создание прокси-таблицы (CREATE PROXY TABLE, CREATE TABLE) по возможности размещает таблицу во включенном датасорсе. Прокси-таблица размещается в отключенном датасорсе, только если он единственный в DATASOURCE_TYPE запроса или хранилище и при этом физически доступен.
Остальные DDL-запросы, а также TRUNCATE ACTUAL, TRUNCATE HISTORY и ERASE DELTA исполняются во всех физически доступных целевых датасорсах независимо от их статуса. Если какой-то из датасорсов физически недоступен, возвращается ошибка.
Восстановление и включение датасорсов, ставших доступными
Когда большинство нод решает, что отключенный датасорс стал доступен, лидер восстанавливает в нем пропущенные данные, включает его и вовлекает в обработку запросов к данным. При ошибках восстановления лидер повторяет попытки через интервал AUTOFAILOVER_EXEC_PERIOD_MS (по умолчанию — через 2 секунды).
Восстановление датасорса успешно завершается, если выполнены условия:
- открытые дельты всех логических БД окружения закрыты или откачены;
- выполняемые операции завершены;
- сбойные операции отменены;
- данные успешно восстановлены.
Выполняемая операция — операция в статусе 0, сбойная — в статусе 2. Подробнее о статусах см. в разделе Операция записи.
Если все датасорсы были затронуты сбоем и отключены, их автоматическое восстановление возможно при физической доступности последнего отключенного ADP-датасорса, даже если некоторые другие датасорсы остаются недоступными.
Физическая схема (не восстанавливается)
Физическая схема данных не восстанавливается, даже она расходится с логической схемой. О способах восстановления физической схемы см. в разделе Ввод сбойных датасорсов в строй.
Восстанавливаемые данные
Механизм auto-failover восстанавливает данные, которые успели записаться в другие датасорсы за время простоя сбойных датасорсов.
Восстанавливаются данные следующих сущностей:
Данные прокси-таблиц не восстанавливаются.
Датасорсы-источники
Данные каждой сущности восстанавливаются из подходящего датасорса-источника. Источником служит ADP-датасорс, содержащий данные сущности:
- один из включенных датасорсов — если такие есть;
- последний отключенный датасорс — если все датасорсы отключены.
Последний отключенный датасорс определяется по наибольшему значению last_version_before_disable. Если таких несколько, из них выбирается один по ADP_AUTOFAILOVER_PRIORITY или произвольно.
Размещение данных сущности задается при ее создании с помощью ключевого слова DATASOURCE_TYPE или позже с помощью запроса ALTER TABLE ADD DATASOURCE.
Открытые дельты и незавершенные операции
Восстановление данных запускается независимо от наличия открытых дельт и выполняемых операций записи, но завершается только после их закрытия и завершения.
Система восстанавливает данные закрытых дельт и завершенных операций, затем ждет закрытия открытых дельт и завершения выполняемых операций в течение RECOVER_LOOP_TIMEOUT_MS. Логические БД, не требующие ожидания, восстанавливаются параллельно.
Система завершает откат дельт, который не смог завершиться из-за сбоя, и откатывает сбойные операции. Откат считается успешным при удалении данных изо всех включенных датасорсов (если такие есть) или последнего отключенного ADP-датасорса (иначе).
Выполняемая операция — операция в статусе 0, сбойная — в статусе 2. Подробнее о статусах см. в разделе Операция записи.
Ограничения
- Механизм auto-failover доступен только для ADP-датасорсов.
- Источниками данных при восстановлении могут быть только другие ADP-датасорсы.
- Восстановление данных возможно только при наличии в датасорсах модуля postgres_fdw.
- Для завершения восстановления дельты во всех логических БД окружения должны быть закрыты, а выполняемые операции записи — завершены.
- Данные прокси-таблиц не восстанавливаются.
- Физическая схема не восстанавливается.
- Сбойные DDL-операции не отменяются и не завершаются автоматически.