О механизме auto-failover

Содержание раздела

Возможности auto-failover
Определение физической доступности датасорсов
1. Вердикты отдельных нод
2. Вердикт кластера
Отключение недоступных датасорсов
Перенаправление запросов во включенные датасорсы
Восстановление и включение датасорсов, ставших доступными
Ограничения

Система обладает встроенным механизмом auto-failover, автоматически переключающим ADP- датасорсы (СУБД или кластер СУБД хранилища
) в случае сбоя. Это исключает необходимость использования внешних оркестраторов, таких как HAProxy, Patroni или etcd, что снижает сложность архитектуры и повышает ее отказоустойчивость.

Если механизм auto-failover настроен и включен, после ввода датасорсов обратно в строй система восстановит данные, включит датасорсы и начнет снова вовлекать их в исполнении запросов.

Механизм auto-failover доступен только для ADP с установленным модулем postgres_fdw.

Для загрузки (Запись данных через Kafka или по HTTP через конечную точку /upload
) из Kafka при включенном механизме auto-failover используйте внешние readable-таблицы (Сущность, определяющая параметры внешнего источника (standalone-таблицы или топика Kafka)
) + Kafka Jet Writer. Загрузка через внешние таблицы загрузки (Сущность, определяющая параметры загрузки данных из топика Kafka)
) + Kafka Postgres Writer в этом случае не гарантирует консистентность данных.

Возможности auto-failover

Механизм auto-failover:

периодически проверяет физическую доступность датасорсов;
отключает датасорсы (СУБД или кластер СУБД хранилища
), ставшие недоступными, и перенаправляет запросы в оставшиеся датасорсы;
восстанавливает и включает сбойные датасорсы, снова ставшие доступными.

На схеме ниже показан порядок работы auto-failover с восстановлением одного сбойного датасорса.

Автоматические отключение, восстановление и включение сбойного датасорса

Определение физической доступности датасорсов

Ноды (Инстанс узла сервиса исполнения запросов Prostore
) кластера (Ноды Prostore, сконфигурированные как группа
) периодически проверяют физическую доступность датасорсов (СУБД или кластер СУБД хранилища
), выносят свои вердикты и сообщают их лидеру кластера. Проверки и сообщение вердиктов выполняются с интервалом AUTOFAILOVER_CHECK_PERIOD_MS (по умолчанию — 10 секунд), чтобы избежать ложных срабатываний из-за мигания сети.

Лидер кластера выносит вердикт кластера о состоянии каждого датасорса по мнению большинства нод. Если состояние изменилось, лидер в зависимости от изменения отключает датасорс или восстанавливает и включает его.

Состояние датасорсов можно проверить запросом GET_HEALTH_STATE. Вердикты нод возвращаются в столбце vote, вердикты кластера — в столбце state.

Вердикты отдельных нод

Каждая нода (Инстанс узла сервиса исполнения запросов Prostore
), включая лидера, периодически определяет состояние датасорсов (СУБД или кластер СУБД хранилища
):

включенный датасорс (Датасорс, работающий в штатном режиме
) считается физически доступным, пока количество его неуспешных ответов подряд меньше AUTOFAILOVER_FAILS_LIMIT (по умолчанию — меньше 3);
отключенный датасорс (Датасорс, отключенный системой из-за сбоя или администратором
) считается физически недоступным, пока количество его успешных ответов подряд меньше AUTOFAILOVER_HEALING_CONFIRM (по умолчанию — меньше 3).

Неуспешным ответом датасорса считается ответ с кодом ошибки или отсутствие ответа, успешным — ответ с успешным кодом.

Запрос GET_HEALTH_STATE возвращает вердикты нод в столбце vote.

Вердикт кластера

Лидер периодически определяет итоговое состояние датасорсов (СУБД или кластер СУБД хранилища
) по мнению кластера (Ноды Prostore, сконфигурированные как группа
):

включенный датасорс (Датасорс, работающий в штатном режиме
) считается физически доступным (healthy), пока большинство нод (Инстанс узла сервиса исполнения запросов Prostore
), включая лидера, считает его таким;
отключенный датасорс (Датасорс, отключенный системой из-за сбоя или администратором
) считается физически недоступным (not healthy), пока большинство нод, включая лидера, считает его таким.

При отсутствии кворума нод (Большинство из сконфигурированных нод кластера
) сохраняется последний вердикт кластера.

Запрос GET_HEALTH_STATE возвращает вердикты кластера в столбце state.

Отключение недоступных датасорсов

Если большинство нод (Инстанс узла сервиса исполнения запросов Prostore
) решило, что включенный (Датасорс, работающий в штатном режиме
) датасорс (СУБД или кластер СУБД хранилища
) недоступен, лидер отключает его для логических БД (Набор логических сущностей (датамарт)
) окружения (Набор логических БД, доступных при работе с нодой
) и перестает вовлекать в исполнения запросов к данным.

Перенаправление запросов во включенные датасорсы

Запросы к данным

Запросы на чтение, запись и проверку* данных распределяются по включенным (Датасорс, работающий в штатном режиме
) датасорсам (СУБД или кластер СУБД хранилища
). Отключенные (Датасорс, отключенный системой из-за сбоя или администратором
) датасорсы пропускаются, даже если они физически доступны.

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

* Здесь запросы проверки данных — это CHECK_DATA, CHECK_SUM и CHECK_SUM_SNAPSHOT.

Синхронизация материализованных представлений

Синхронизация материализованных представлений (Сущность с сохраненными результатами SELECT-запроса
) сохраняет изменения только во включенные (Датасорс, работающий в штатном режиме
) датасорсы (СУБД или кластер СУБД хранилища
)-приемники. Отключенные (Датасорс, отключенный системой из-за сбоя или администратором
) датасорсы пропускаются, даже если физически доступны.

Синхронизация считается успешной, если изменения текущего цикла сохранены в достаточное количество датасорсов-приемников. В противном случае система отменяет изменения и приостанавливает синхронизацию до восстановления и включения недостающих датасорсов.

Если отключен датасорс-источник, синхронизация зависящих от него представлений приостанавливается до его восстановления и включения.

Достаточное количество датасорсов для записи данных

Запись данных считается успешной, если данные удалось сохранить в количество включенных (Датасорс, работающий в штатном режиме
) датасорсов (СУБД или кластер СУБД хранилища
), указанное в таблице ниже. Это относится к загрузке (Запись данных через Kafka или по HTTP через конечную точку /upload
) и обновлению (Запись данных с помощью INSERT/UPSERT VALUES, INSERT SELECT, UPDATE, DELETE.
) данных в обычных логических таблицах (Логическая таблица без партиционирования
), а также синхронизации материализованных представлений (Сущность с сохраненными результатами SELECT-запроса
).

Датасорсы сущности	Условие успешной записи данных
Включают 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. Если за это время данные удалось записать в достаточное количество датасорсов, операция записи завершается успешно; иначе — операция завершается с ошибкой.

Переповторы выполняются при обновлении (Запись данных с помощью INSERT/UPSERT VALUES, INSERT SELECT, UPDATE, DELETE.
) и потоковой загрузке (Запись данных порциями по HTTP через конечную точку /upload
) данных в логические таблицы (Таблица с версионируемыми данными
), а также при синхронизации материализованных представлений (Сущность с сохраненными результатами SELECT-запроса
). При ошибках загрузки данных из Kafka переповторы не делаются — система сразу возвращает ошибку.

При переповторах значения rowsAffected и rowsAdded могут быть некорректными.

DDL-запросы

Запрос на создание прокси-таблицы (Логическая таблица без версионирования данных
) (CREATE PROXY TABLE, CREATE TABLE) по возможности размещает таблицу включенном (Датасорс, работающий в штатном режиме
) датасорсе (СУБД или кластер СУБД хранилища
). Прокси-таблица размещается в отключенном (Датасорс, отключенный системой из-за сбоя или администратором
) датасорсе, только если он единственный в DATASOURCE_TYPE запроса или хранилище (Набор датасорсов, где хранятся данные логических сущностей окружения
) и при этом физически доступен.

Остальные DDL-запросы, а также TRUNCATE ACTUAL, TRUNCATE HISTORY и ERASE DELTA исполняются во всех физически доступных целевых датасорсах независимо от их статуса. Если какой-то из датасорсов физически недоступен, возвращается ошибка.

Восстановление и включение датасорсов, ставших доступными

Когда большинство нод (Инстанс узла сервиса исполнения запросов Prostore
) решает, что отключенный датасорс (СУБД или кластер СУБД хранилища
) стал доступен, лидер восстанавливает в нем пропущенные данные, включает его и вовлекает в обработку запросов к данным. При ошибках восстановления лидер повторяет попытки через интервал AUTOFAILOVER_EXEC_PERIOD_MS (по умолчанию — через 2 секунды).

Восстановление датасорса успешно завершается, если выполнены условия:

открытые дельты (Целостный набор изменений в логической БД (аналог транзакции)
) всех логических БД (Набор логических сущностей (датамарт)
) окружения (Набор логических БД, доступных при работе с нодой
) закрыты или откачены;
выполняемые операции (Операция вставки, изменения или удаления версионируемых данных
) завершены;
сбойные операции отменены;
данные успешно восстановлены.

Выполняемая операция — операция в статусе 0, сбойная — в статусе 2. Подробнее о статусах см. в разделе Операция записи.

Если все датасорсы были затронуты сбоем и отключены, их автоматическое восстановление возможно при физической доступности последнего отключенного ADP-датасорса, даже если некоторые другие датасорсы остаются недоступными.

Физическая схема (не восстанавливается)

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

Восстанавливаемые данные

Механизм auto-failover восстанавливает данные, которые успели записаться в другие датасорсы за время простоя сбойных датасорсов (СУБД или кластер СУБД хранилища
).

Восстанавливаются данные следующих сущностей:

обычных логических таблиц (Логическая таблица без партиционирования
),
партиций (Логическая таблица, содержащая данные с определенными значениями ключа партиционирования
),
материализованных представлений (Сущность с сохраненными результатами SELECT-запроса
).

Данные прокси-таблиц (Логическая таблица без версионирования данных
) не восстанавливаются.

Датасорсы-источники

Данные каждой сущности восстанавливаются из подходящего датасорса (СУБД или кластер СУБД хранилища
)-источника (донора). Источником служит ADP-датасорс, содержащий данные сущности:

один из включенных (Датасорс, работающий в штатном режиме
) датасорсов — если такие есть;
последний отключенный (Датасорс, отключенный системой из-за сбоя или администратором
) датасорс — если все датасорсы отключены.

Последний отключенный датасорс определяется по наибольшему значению last_version_before_disable. Если таких несколько, из них выбирается один по ADP_AUTOFAILOVER_PRIORITY или произвольно.

Размещение данных сущности задается при ее создании с помощью ключевого слова DATASOURCE_TYPE или позже с помощью запроса ALTER TABLE ADD DATASOURCE.

Открытые дельты и незавершенные операции

Восстановление данных запускается независимо от наличия открытых дельт (Целостный набор изменений в логической БД (аналог транзакции)
) и выполняемых операций записи (Операция вставки, изменения или удаления версионируемых данных
), но завершается только после их закрытия и завершения.

Система восстанавливает данные закрытых дельт и завершенных операций, затем ждет закрытия открытых дельт и завершения выполняемых операций в течение RECOVER_LOOP_TIMEOUT_MS. Логические БД (Набор логических сущностей (датамарт)
), не требующие ожидания, восстанавливаются параллельно.

Система завершает откат дельт, который не смог завершиться из-за сбоя, и откатывает сбойные операции. Откат считается успешным при удалении данных изо всех включенных датасорсов (СУБД или кластер СУБД хранилища
) (если такие есть) или последнего отключенного ADP-датасорса (иначе).

Ограничения

Ограничения датасорсов

Auto-failover работает только для ADP- датасорсов (СУБД или кластер СУБД хранилища
).
Источниками восстановления могут быть только другие ADP-датасорсы.
В датасорсах должен быть установлен модуль postgres_fdw.

Ограничения восстановления

Физическая схема данных (Структура хранения данных логических сущностей в датасорсах
) не восстанавливается.
Данные прокси-таблиц (Логическая таблица без версионирования данных
) не восстанавливаются.

Другие ограничения

Сбойные DDL-операции не отменяются и не завершаются автоматически.
Для завершения восстановления дельты (Целостный набор изменений в логической БД (аналог транзакции)
) во всех логических БД (Набор логических сущностей (датамарт)
) окружения (Набор логических БД, доступных при работе с нодой
) должны быть закрыты, а выполняемые операции записи (Операция вставки, изменения или удаления версионируемых данных
) — завершены.
Консистентность загрузки из Kafka при включенном механизме auto-failover гарантируется только при использовании внешних readable-таблиц (Сущность, определяющая параметры внешнего источника (standalone-таблицы или топика Kafka)
) и Kafka Jet Writer.