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

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

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

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

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

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

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

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

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

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

Для датасорса восстанавливаются только логические таблицы следующих видов:

• обычные логические таблицы;
• партиции.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Работа с данными при отключенном датасорсе

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

Запросы на проверку записанных данных — CHECK_DATA, CHECK_SUM и CHECK_SUM_SNAPSHOT — рассчитывают контрольную сумму и проверяют целостность данных только в активных (включенных) датасорсах. Отключенные датасорсы пропускаются без возврата ошибки.

Работа со схемой данных при отключенном датасорсе

Все 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 без retention-правил для целевой таблицы, 2. ADB без retention-правил для целевой таблицы, 3. ADP с retention-правилами для целевой таблицы, 4. ADB с retention-правилами для целевой таблицы
ADB	1. ADB без retention-правил для целевой таблицы, 2. ADP без retention-правил для целевой таблицы, 3. ADB с retention-правилами для целевой таблицы, 4. ADP с retention-правилами для целевой таблицы

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

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

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