О восстановлении датасорсов

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

1. Поддерживаемые СУБД
2. Восстанавливаемые сущности
3. Сущности, не подлежащие восстановлению
4. Этапы восстановления датасорса
5. Отключение датасорса
6. Перенаправление запросов во включенные датасорсы
   1. Запросы к данным
   2. Синхронизация материализованных представлений
   3. Датасорсы, необходимые для записи данных
   4. DDL-запросы
7. Восстановление схемы данных
8. Восстановление данных
9. Режимы восстановления датасорса
   1. Восстановление только пропущенных данных
   2. Полное восстановление с пересоздания сущностей и перезаписью данных
10. Выбор датасорса-источника
    1. Выбор из включенных датасорсов-источников
    2. Выбор из отключенных датасорсов-источников
11. Включение датасорса

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

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

При восстановлении датасорса восстанавливаются только сущности, перечисленные в секции Восстанавливаемые сущности. Прогресс восстановления можно отслеживать с помощью GET_RECOVER_STATUS.

Для загрузки из Kafka при восстановлении датасорсов используйте внешние readable-таблицы + Kafka Jet Writer. Загрузка через внешние таблицы загрузки + Kafka Postgres Writer в этом случае не гарантирует консистентность данных.

Для ADP-датасорсов доступна автоматическая альтернатива — механизм auto-failover.

Поддерживаемые СУБД

Доступно восстановление датасорсов типов ADB и ADP на основе данных датасорсов типов ADB и ADP. При этом возможны любые комбинации этих типов — например, можно восстановить датасорс adp2 на основе данных датасорсов adb и adp.

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

Для датасорса восстанавливаются:

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

Восстановление сущности доступно, если она имеет реплики (копии данных) как минимум в еще одном датасорсе.

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

На рисунке ниже показаны две логические таблицы: данные таблицы А размещены в датасорсах ds1 и ds2, а данные таблицы Б — в датасорсах ds1, ds2 и ds3. Обе таблицы можно восстановить в ds2 при его сбое, так как эти таблицы имеют реплики данных в других датасорсах.

Логические таблицы, подлежащие восстановлению в датасорсе ds2

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

Логическая таблица, не подлежащая восстановлению в датасорсе ds2

Сущности, не подлежащие восстановлению

Партиционированные таблицы (следует не путать с партициями) и прокси-таблицы не восстанавливаются. При необходимости вы можете их пересоздать после успешного восстановления датасорса.

Другие типы сущностей — внешние таблицы и логические представления — не имеют связанных физических таблиц и данных в датасорсах и поэтому не требуют восстановления при сбое датасорса.

Этапы восстановления датасорса

Восстановление датасорса в системе состоит из следующих этапов:

1. Отключение.
2. Восстановление схемы и данных.
3. Включение.

Указанные выше этапы отражают порядок выполнения действий в системе. Полный список действий по восстановлению датасорса может быть шире. Подробнее см. в разделе Как восстановить датасорс.

На рисунках ниже показаны этапы восстановления сбойного датасорса:

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

Сбойный датасорс до его отключения и восстановления

Сбойный датасорс после его отключения

Восстановление датасорса

Датасорс после успешного восстановления

Отключение датасорса

Отключить датасорс можно запросом DISABLE_DATASOURCE. При отключении датасорса система помечает этот датасорс как отключенный и перестает вовлекать его в исполнение запросов.

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

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

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

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

* Здесь запросы проверки данных — это 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	Запись в любой датасорс сущности
Партиционированная таблица (Логическая таблица, позволяющая работать с данными партиций. Не хранит данные долговременно )	ADP†	Запись в самый оптимальный датасорс сущности
Партиция (Логическая таблица, содержащая данные с определенными значениями ключа партиционирования ) (при записи через партиционированную таблицу или напрямую)	ADP†	Запись в любой датасорс сущности

† Партиционирование доступно только для ADP-датасорсов.

Пример 1 — логическая таблица:

• датасорсы сущности: adp, adp2, adp3;
• значение AUTOFAILOVER_MIN_SYNC_REPLICAS: 1;
• условие успешной записи: запись в любой датасорс из [adp, adp2, adp3].

Пример 2 — материализованное представление:

• датасорсы сущности: adp, adb;
• значение AUTOFAILOVER_MIN_SYNC_REPLICAS: 2;
• условие успешной записи: запись в adp.

Пример 3 — партиционированная таблица:

• датасорсы сущностей:
  • партиционированной таблицы: adp, adp2, adp3;
  • партиции 1: adp, adp2;
  • партиции 2: adp2, adp3;
• значение AUTOFAILOVER_MIN_SYNC_REPLICAS: 2 (не применяется; для партиционированных таблиц и партиций всегда равно 1);
• условие успешной записи:
  • в партиционированную таблицу: запись в adp2;
  • в партицию 1: запись в любой датасорс из [adp, adp2];
  • в партицию 2: запись в любой датасорс из [adp2, adp3].

DDL-запросы

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

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

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

Восстановить схему и данные логических сущностей в датасорсе можно запросом RECOVER_DATASOURCE.

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

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

Подробнее о вариантах восстановления см. в секции Режимы восстановления датасорса.

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

При восстановлении данных датасорса система определяет логические сущности, подлежащие восстановлению, и копирует данные этих сущностей из датасорсов, которые служат источниками данных (донорами), в восстанавливаемый датасорс. Объем восстановления данных зависит от заданного режима восстановления датасорса.

Источниками данными для восстанавливаемой логической БД могут быть несколько датасорсов, но для каждой логической сущности система выбирает один наиболее оптимальный датасорс-источник.

Режимы восстановления датасорса

Доступны следующие режимы восстановления датасорса:

• восстановление только пропущенных данных — применяется, если флаг full_recovery в команде RECOVER_DATASOURCE отсутствует или имеет значение false;
• полное восстановление с пересозданием сущностей и перезаписью данных — применяется, если флаг full_recovery в команде RECOVER_DATASOURCE имеет значение true.

Холодные данные не восстанавливаются во всех режимах восстановления.

Восстановление только пропущенных данных

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

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

Полное восстановление с пересоздания сущностей и перезаписью данных

В режиме полного восстановления система выполняет следующие действия:

1. Для всех логических таблиц и материализованных представлений, подлежащих восстановлению, удаляет из восстанавливаемого датасорса связанные физические таблицы вместе со всеми данными.
2. Пересоздает нужные физические таблицы.
3. Наполняет пересозданные физические таблицы данными, скопированными из датасорсов-источников. Данные копируются с нулевой по последнюю завершенную операцию записи.

Режим пересоздания сущностей с восстановлением данных предназначен для следующих случаев:

• восстанавливается новая логическая БД — например, при замене сервера;
• физическая схема в восстанавливаемом датасорсе расходится с логической схемой.

Выбор датасорса-источника

Каждая логическая сущность восстанавливается из оптимального для нее датасорса-источника. Источником служит датасорс с данными сущности:

• из заданных в команде RECOVER_DATASOURCE — если они заданы;
• из сконфигурированных — иначе.

Выбор из включенных датасорсов-источников

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

Тип восстанавливаемого датасорса	Порядок выбора типа датасорса-источника
ADP	1. ADP, 2. ADB. Предпочтение отдается датасорсу без retention-правил для целевой таблицы
ADB	1. ADB, 2. ADP. Предпочтение отдается датасорсу без retention-правил для целевой таблицы

Выбор из отключенных датасорсов-источников

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

• (ADP) с наибольшим значением ADP_AUTOFAILOVER_PRIORITY или произвольный;
• (ADB) произвольный.

Последним отключенным считается датасорс с наибольшим значением last_version_before_disable.

Если датасорсы-источники заданы в RECOVER_DATASOURCE и при этом все отключены, в ответе возвращается ошибка.

Включение датасорса

Датасорс включается автоматически, если команда RECOVER_DATASOURCE успешно восстановила датасорс, или вручную с помощью команды ENABLE_DATASOURCE, если восстановление потребовало ручного разбора.

При включении датасорса система помечает датасорс как включенный и начинает вовлекать его в обработку запросов.