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

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

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

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

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

Восстановление логических БД в датасорсе возможно в следующих объемах:

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

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

Отслеживать прогресс восстановления можно с помощью GET_RECOVER_STATUS.

Для 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.

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

Синхронизация материализованных представлений сохраняет изменения только во включенные датасорсы-приемники. Отключенные датасорсы пропускаются, даже если физически доступны.

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

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

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

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

Датасорсы сущности	Условие успешной записи данных
Включают 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-датасорса.

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, если восстановление потребовало ручного разбора.

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