Перейти к содержимому
Последнее обновление

Резервное копирование

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

Сценарии использования​

СценарийОписание
Регулярное резервное копирование данныхПериодически создавайте полные резервные копии баз данных, таблиц или партиций, чтобы предотвратить потерю данных из-за случайного удаления или отказа оборудования.
Аварийное восстановлениеСохраняйте резервные копии в удалённом хранилище на внешней площадке (S3, HDFS и т. д.), чтобы восстановить данные при отказе всего кластера.
Перенос данных между кластерамиСоздайте резервную копию в исходном кластере и восстановите её в целевом кластере, чтобы перенести данные между ними.
Подготовка данных для тестовой средыСоздайте резервную копию части таблиц или партиций рабочей среды и восстановите их в тестовом кластере.
Имитация инкрементального резервного копированияСоздавайте резервные копии только новых или изменённых партиций, чтобы приблизиться к поведению инкрементального резервного копирования (Doris пока не поддерживает встроенное инкрементальное резервное копирование).

Предварительные требования​

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

  • Права доступа: учётная запись, от имени которой выполняется операция, имеет права ADMIN (они необходимы как для резервного копирования, так и для восстановления).
  • Режим развёртывания: текущий кластер работает в режиме с объединёнными вычислениями и хранением (режим с разделением вычислений и хранения не поддерживает резервное копирование и восстановление).
  • Удалённое хранилище: подготовлено доступное удалённое хранилище (S3, Azure, GCP, OSS, COS, MinIO, HDFS или другое S3-совместимое объектное хранилище) и получены соответствующие учётные данные для доступа.
  • Сетевая доступность: узлы FE и BE могут обращаться к конечной точке удалённого хранилища.
  • Ограничения для объектов: объекты, для которых создаются резервные копии, не относятся к следующим неподдерживаемым типам:
    • Асинхронные материализованные представления (MTMV)
    • Таблицы, использующие политику хранения

Основные понятия​

ПонятиеОпределение
СнимокЗафиксированное состояние данных базы данных, таблицы или партиции на определённый момент времени. При создании снимка необходимо указать его Label, а после завершения создания формируется временная метка. Снимок однозначно определяется сочетанием Repository, Label снимка и временной метки.
RepositoryУдалённое расположение для хранения файлов резервных копий. Поддерживаются S3, Azure, GCP, OSS, COS, MinIO, HDFS и другие S3-совместимые объектные хранилища.
Операция резервного копированияСоздаёт снимок базы данных, таблицы или партиции, загружает файлы снимка в удалённый Repository и сохраняет метаданные резервной копии.
Операция восстановленияСкачивает снимок из удалённого Repository и восстанавливает его в кластере Doris.

Ограничения использования​

ОграничениеОписание
Режим с разделением вычислений и хранения не поддерживаетсяФункции резервного копирования и восстановления недоступны в режиме развёртывания с разделением вычислений и хранения.
Асинхронные материализованные представления (MTMV) не поддерживаютсяОперации резервного копирования и восстановления не включают асинхронные материализованные представления.
Таблицы с политикой хранения не поддерживаютсяТаблицы, использующие политику хранения, не поддерживают операции резервного копирования и восстановления.
Поддерживаются только полные резервные копииВ настоящее время Doris поддерживает только полное резервное копирование. Инкрементальное резервное копирование (сохранение только данных, изменившихся с момента последнего резервного копирования) пока не поддерживается. Можно имитировать его поведение, создавая резервные копии отдельных партиций.
Свойство colocate_with не сохраняетсяПри резервном копировании или восстановлении Doris не сохраняет свойство таблицы colocate_with. После восстановления может потребоваться повторно настроить таблицы colocate.
Динамическое партиционирование необходимо включить повторноПосле восстановления таблицы необходимо вручную включить свойство динамического партиционирования с помощью команды ALTER TABLE.
Ограничение на одновременное выполнениеВ пределах одной базы данных одновременно может выполняться только одна задача резервного копирования или восстановления.

Обзор процесса резервного копирования​

Полный процесс резервного копирования состоит из следующих 5 шагов:

  1. Создайте Repository: зарегистрируйте в Doris расположение в удалённом хранилище.
  2. Выполните резервное копирование: запустите задачу резервного копирования с помощью BACKUP SNAPSHOT.
  3. Проверьте ход резервного копирования: используйте SHOW BACKUP, чтобы проверить состояние выполнения задачи.
  4. Просмотрите существующие снимки в Repository: используйте SHOW SNAPSHOT, чтобы получить список доступных резервных копий.
  5. (Необязательно) Отмените резервное копирование: при возникновении ошибки завершите задачу с помощью CANCEL BACKUP.

В следующих разделах каждый шаг описан в указанном порядке.

Шаг 1: создание Repository​

Выберите команду создания Repository в зависимости от типа используемого удалённого хранилища. Подробности см. в разделе CREATE REPOSITORY.

подсказка

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

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

СпособУдалённое хранилищеПримечания
Способ 1S3AWS S3 или S3-совместимое объектное хранилище
Способ 2Azure Blob StorageПоддерживается начиная с Doris 3.1.3
Способ 3GCP (Google Cloud Storage)Необходимо указать фиктивное значение s3.region
Способ 4OSS (Alibaba Cloud Object Storage)Нет
Способ 5MinIOЕсли Virtual Host-style не включён, требуется use_path_style=true
Способ 6HDFSНет

Способ 1: создание Repository в S3​

Создайте Repository в AWS S3:

CREATE REPOSITORY `s3_repo`
WITH S3
ON LOCATION "s3://bucket_name/s3_repo"
PROPERTIES
(
    "s3.endpoint" = "https://s3.us-east-1.amazonaws.com",
    "s3.region" = "us-east-1",
    "s3.access_key" = "ak",
    "s3.secret_key" = "sk"
);

Примечания:

  • Замените bucket_name именем вашего бакета S3.
  • Укажите соответствующие значения endpoint, access key, secret key и region для настройки S3.

Способ 2: создание Repository в Azure​

Поддерживается начиная с Doris 3.1.3.

Создайте Repository в Azure Blob Storage:

CREATE REPOSITORY `azure_repo`
WITH S3
ON LOCATION "s3://<container_name>/azure_repo"
PROPERTIES
(
    "azure.endpoint" = "https://<account_name>.blob.core.windows.net",
    "azure.account_name" = "<account_name>",
    "azure.account_key" = "<account_key>",
    "provider" = "AZURE"
);

Примечания:

  • Замените <container_name> именем вашего контейнера Azure.
  • Укажите учётную запись хранилища Azure и ключ для аутентификации.
  • Значение provider должно быть AZURE.

Способ 3: создание Repository в GCP​

Создайте Repository в хранилище Google Cloud Platform (GCP):

CREATE REPOSITORY `gcp_repo`
WITH S3
ON LOCATION "s3://bucket_name/backup/gcp_repo"
PROPERTIES
(
    "s3.endpoint" = "storage.googleapis.com",
    "s3.region" = "US-WEST2",
    "s3.access_key" = "ak",
    "s3.secret_key" = "sk"
);

Примечания:

  • Замените bucket_name именем вашего бакета GCP.
  • Укажите значения endpoint, access key и secret key для GCP.
  • s3.region задаёт лишь фиктивный регион. Можно указать любое значение, но сам параметр обязателен.

Способ 4: создание Repository в OSS (Alibaba Cloud Object Storage Service)​

Создайте Repository в OSS:

CREATE REPOSITORY `oss_repo`
WITH S3
ON LOCATION "s3://bucket_name/oss_repo"
PROPERTIES
(
    "s3.endpoint" = "oss.aliyuncs.com",
    "s3.region" = "cn-hangzhou",
    "s3.access_key" = "ak",
    "s3.secret_key" = "sk"
);

Примечания:

  • Замените bucket_name именем вашего бакета OSS.
  • Укажите значения endpoint, region, access key и secret key для OSS.

Способ 5: создание Repository в MinIO​

Создайте Repository в хранилище MinIO:

CREATE REPOSITORY `minio_repo`
WITH S3
ON LOCATION "s3://bucket_name/minio_repo"
PROPERTIES
(
    "s3.endpoint" = "yourminio.com",
    "s3.region" = "dummy-region",
    "s3.access_key" = "ak",
    "s3.secret_key" = "sk",
    "use_path_style" = "true"
);

Примечания:

  • Замените bucket_name именем вашего бакета MinIO.
  • Укажите значения endpoint, access key и secret key для MinIO.
  • s3.region задаёт лишь фиктивный регион. Можно указать любое значение, но сам параметр обязателен.
  • Если Virtual Host-style не включён, параметру use_path_style необходимо присвоить значение true.

Способ 6: создание Repository в HDFS​

Создайте Repository в HDFS:

CREATE REPOSITORY `hdfs_repo`
WITH hdfs
ON LOCATION "hdfs://127.0.0.1:9000/prefix_path/hdfs_repo"
PROPERTIES
(
    "fs.defaultFS" = "hdfs://127.0.0.1:9000",
    "hadoop.username" = "doris-test"
)

Примечания:

  • Замените prefix_path фактическим путём.
  • Укажите endpoint и имя пользователя для HDFS.

Шаг 2: выполнение резервного копирования​

Запустите задачу резервного копирования с помощью BACKUP SNAPSHOT. Подробности см. в разделе BACKUP.

подсказка

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

В зависимости от объектов резервного копирования можно выбрать разные варианты команды:

СпособОбъект резервного копированияСценарий использования
Способ 1Текущая база данныхПолное резервное копирование базы данных, выбранной командой USE
Способ 2Указанная база данныхПолное резервное копирование базы данных с явно заданным именем
Способ 3Указанные таблицыРезервное копирование только определённых таблиц
Способ 4Указанные партицииРезервное копирование отдельных партиций таблицы; можно сочетать с копированием целых таблиц
Способ 5Исключение определённых таблицПолное резервное копирование базы данных за исключением указанных таблиц

Способ 1: резервное копирование текущей базы данных​

Следующая SQL-команда создаёт резервную копию текущей базы данных в Repository с именем example_repo, используя Label снимка exampledb_20241225:

BACKUP SNAPSHOT exampledb_20241225
TO example_repo;

Способ 2: резервное копирование указанной базы данных​

Следующая SQL-команда создаёт резервную копию базы данных с именем destdb в Repository с именем example_repo, используя Label снимка destdb_20241225:

BACKUP SNAPSHOT destdb.`destdb_20241225`
TO example_repo;

Способ 3: резервное копирование указанных таблиц​

Следующая SQL-команда создаёт резервную копию двух таблиц в Repository с именем example_repo, используя Label снимка exampledb_tbl_tbl1_20241225:

BACKUP SNAPSHOT exampledb_tbl_tbl1_20241225
TO example_repo
ON (example_tbl, example_tbl1);

Способ 4: резервное копирование указанных партиций​

Следующая SQL-команда создаёт резервную копию таблицы с именем example_tbl2, а также партиций p1 и p2 таблицы с именем example_tbl, в Repository с именем example_repo, используя Label снимка example_tbl_p1_p2_tbl1_20241225:

BACKUP SNAPSHOT example_tbl_p1_p2_tbl1_20241225
TO example_repo
ON
(
      example_tbl PARTITION (p1,p2),
      example_tbl2
);

Способ 5: резервное копирование текущей базы данных с исключением определённых таблиц​

Следующая SQL-команда создаёт резервную копию текущей базы данных в Repository с именем example_repo, используя Label снимка exampledb_20241225 и исключая две таблицы с именами example_tbl и example_tbl1:

BACKUP SNAPSHOT exampledb_20241225
TO example_repo
EXCLUDE
(
      example_tbl,
      example_tbl1
);

Шаг 3: просмотр состояния выполнения последних задач резервного копирования​

Используйте следующую SQL-команду для просмотра состояния выполнения последних задач резервного копирования:

mysql> show BACKUP\G;
*************************** 1. row ***************************
                  JobId: 17891847
           SnapshotName: exampledb_20241225
                 DbName: example_db
                  State: FINISHED
             BackupObjs: [example_db.example_tbl]
             CreateTime: 2022-04-08 15:52:29
   SnapshotFinishedTime: 2022-04-08 15:52:32
     UploadFinishedTime: 2022-04-08 15:52:38
           FinishedTime: 2022-04-08 15:52:44
        UnfinishedTasks:
               Progress:
             TaskErrMsg:
                 Status: [OK]
                Timeout: 86400
   1 row in set (0.01 sec)

Описание основных полей:

ПолеЗначение
JobIdИдентификатор задачи резервного копирования.
SnapshotNameLabel снимка, соответствующий имени, указанному в BACKUP SNAPSHOT.
DbNameБаза данных, к которой относится резервная копия.
StateСостояние задачи. Например, FINISHED означает, что задача завершена.
BackupObjsСписок объектов, для которых фактически созданы резервные копии.
CreateTime / SnapshotFinishedTime / UploadFinishedTime / FinishedTimeВременные метки создания задачи, завершения создания снимка, завершения загрузки и завершения всей задачи.
StatusСтатус результата выполнения задачи. [OK] означает успешное выполнение; в противном случае поле содержит сведения об ошибке.
TimeoutВремя ожидания выполнения задачи (в секундах).

Шаг 4: просмотр существующих резервных копий в Repository​

Используйте следующую SQL-команду для просмотра существующих резервных копий в Repository с именем example_repo. Столбец Snapshot содержит Label снимка, а Timestamp — временную метку:

mysql> SHOW SNAPSHOT ON example_repo;
+-----------------+---------------------+--------+
| Snapshot        | Timestamp           | Status |
+-----------------+---------------------+--------+
| exampledb_20241225 | 2022-04-08-15-52-29 | OK     |
+-----------------+---------------------+--------+
1 row in set (0.15 sec)

При выполнении операции восстановления необходимо использовать сочетание Snapshot и Timestamp, чтобы однозначно определить версию резервной копии.

Шаг 5: отмена резервного копирования (при необходимости)​

Если при выполнении задачи резервного копирования возникла ошибка или её необходимо прервать, используйте следующую SQL-команду, чтобы отменить выполняющуюся задачу резервного копирования в базе данных:

CANCEL BACKUP FROM db_name;

Более подробные сведения см. в разделе CANCEL BACKUP.

Часто задаваемые вопросы​

Вопрос: что делать, если не удаётся создать Repository?​

Обычно это связано с неверными учётными данными удалённого хранилища, недоступной конечной точкой или отсутствующим бакетом либо контейнером. Проверьте правильность значений endpoint, access key, secret key и имени бакета, а также убедитесь, что узлы FE/BE могут обращаться к удалённому хранилищу.

Вопрос: что делать, если резервное копирование в MinIO завершается ошибкой?​

Обычно это происходит, когда Virtual Host-style не включён, а параметр use_path_style отсутствует. Добавьте "use_path_style" = "true" в PROPERTIES.

Вопрос: что делать, если GCP/MinIO сообщает об отсутствии региона?​

s3.region необходимо указать, даже если используется фиктивное значение, например dummy-region.

Вопрос: что делать, если не удаётся создать Repository в Azure?​

Версии Doris до 3.1.3 не поддерживают Azure Blob Storage. Обновите Doris до версии 3.1.3 или более поздней и убедитесь, что задано provider = AZURE.

Вопрос: что делать, если в одной базе данных возникает конфликт резервного копирования и восстановления?​

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

Вопрос: что делать, если кластер с разделением вычислений и хранения не может выполнять резервное копирование?​

Резервное копирование и восстановление не поддерживаются в режиме с разделением вычислений и хранения. Переключитесь в режим с объединёнными вычислениями и хранением или используйте другой способ экспорта данных.

Вопрос: почему материализованное представление не попало в резервную копию?​

Асинхронные материализованные представления (MTMV) не включаются в резервные копии. После восстановления необходимо заново создать соответствующие материализованные представления в целевом кластере.

Вопрос: как устранить повреждение данных, возникающее при резервном копировании из разных кластеров по одному и тому же пути?​

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

Вопрос: почему динамическое партиционирование не работает после восстановления?​

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

Вопрос: что делать, если таблицы colocate работают некорректно после восстановления?​

Резервное копирование и восстановление не сохраняют свойство colocate_with. После восстановления повторно настройте свойство colocate_with для таблиц colocate.

Report issue
На этой странице