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

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

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 на основе данных других датасорсов этих же типов. При этом возможны любые комбинации — например, можно восстановить датасорс adp2 на основе данных adb или adp.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. После сбоя, но до отключения и восстановления.
2. После отключения, но до восстановления.
3. В процессе восстановления.
4. После успешного завершения восстановления.

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

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

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

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

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

Отключить датасорс можно запросом 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, количество ADP-датасорсов сущности
	Не включают ADP	Любой датасорс сущности
Снапшот-таблица	ADP**	Минимум ADP-датасорсов из: AUTOFAILOVER_MIN_SYNC_REPLICAS, количество 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.

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

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

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

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

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

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

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

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

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

• восстановление только пропущенных данных — при запуске RECOVER_DATASOURCE без флага полного восстановления или с флагом, имеющим значение false;
• полное восстановление с пересозданием сущностей и перезаписью данных — при запуске 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, если восстановление потребовало ручного разбора.

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