Версия: 2.0.x

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

В этом разделе описывается, как выполнять резервное копирование и восстановление данных в Selena, а также как мигрировать данные в новый cluster Selena.

Selena поддерживает резервное копирование данных в виде снимков во внешнюю систему хранения и восстановление данных в любые cluster Selena.

Начиная с версии v1.5.2, Selena расширила функциональность BACKUP и RESTORE, добавив поддержку большего количества объектов и переработав синтаксис для большей гибкости.

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

Apache™ Hadoop® (HDFS) cluster
AWS S3
Google GCS
MinIO

Selena поддерживает резервное копирование следующих объектов:

Внутренние базы данных, таблицы (всех типов и стратегий партиционирования) и партиции
Метаданные внешних каталогов (поддерживается с версии v1.5.2)
Синхронные материализованные представления и асинхронные материализованные представления
Логические представления (поддерживается с версии v1.5.2)
Пользовательские функции (поддерживается с версии v1.5.2)

ПРИМЕЧАНИЕ

Cluster Selena с общими данными (shared-data) не поддерживают BACKUP и RESTORE данных.

Создание репозитория

Перед резервным копированием данных необходимо создать репозиторий, который используется для хранения снимков данных во внешней системе хранения. В cluster Selena можно создать несколько репозиториев. Подробные инструкции см. в разделе CREATE REPOSITORY.

Создание репозитория в HDFS

Следующий пример создаёт репозиторий с именем test_repo в cluster HDFS.

CREATE REPOSITORY test_repo
WITH BROKER
ON LOCATION "hdfs://<hdfs_host>:<hdfs_port>/repo_dir/backup"
PROPERTIES(
    "username" = "<hdfs_username>",
    "password" = "<hdfs_password>"
);

Создание репозитория в AWS S3

Вы можете выбрать учётные данные на основе IAM-пользователя (Access Key и Secret Key), Instance Profile или Assumed Role в качестве метода аутентификации для доступа к AWS S3.
- Следующий пример создаёт репозиторий с именем test_repo в бакете AWS S3 bucket_s3, используя учётные данные на основе IAM-пользователя.
```
CREATE REPOSITORY test_repo
WITH BROKER
ON LOCATION "s3a://bucket_s3/backup"
PROPERTIES(
    "aws.s3.access_key" = "XXXXXXXXXXXXXXXXX",
    "aws.s3.secret_key" = "yyyyyyyyyyyyyyyyyyyyyyyy",
    "aws.s3.region" = "us-east-1"
);
```
- Следующий пример создаёт репозиторий с именем test_repo в бакете AWS S3 bucket_s3, используя Instance Profile в качестве метода аутентификации.
```
CREATE REPOSITORY test_repo
WITH BROKER
ON LOCATION "s3a://bucket_s3/backup"
PROPERTIES(
    "aws.s3.use_instance_profile" = "true",
    "aws.s3.region" = "us-east-1"
);
```
- Следующий пример создаёт репозиторий с именем test_repo в бакете AWS S3 bucket_s3, используя Assumed Role в качестве метода аутентификации.
```
CREATE REPOSITORY test_repo
WITH BROKER
ON LOCATION "s3a://bucket_s3/backup"
PROPERTIES(
    "aws.s3.use_instance_profile" = "true",
    "aws.s3.iam_role_arn" = "arn:aws:iam::xxxxxxxxxx:role/yyyyyyyy",
    "aws.s3.region" = "us-east-1"
);
```

ПРИМЕЧАНИЕ

Selena поддерживает создание репозиториев в AWS S3 только по протоколу S3A. Поэтому при создании репозиториев в AWS S3 необходимо заменить s3:// в URI S3, который передаётся в качестве местоположения репозитория в ON LOCATION, на s3a://.

Создание репозитория в Google GCS

Следующий пример создаёт репозиторий с именем test_repo в бакете Google GCS bucket_gcs.

CREATE REPOSITORY test_repo
WITH BROKER
ON LOCATION "s3a://bucket_gcs/backup"
PROPERTIES(
    "fs.s3a.access.key" = "xxxxxxxxxxxxxxxxxxxx",
    "fs.s3a.secret.key" = "yyyyyyyyyyyyyyyyyyyy",
    "fs.s3a.endpoint" = "storage.googleapis.com"
);

ПРИМЕЧАНИЕ

Selena поддерживает создание репозиториев в Google GCS только по протоколу S3A. Поэтому при создании репозиториев в Google GCS необходимо заменить префикс в URI GCS, который передаётся в качестве местоположения репозитория в ON LOCATION, на s3a://.

Не указывайте https в адресе конечной точки.

Создание репозитория в MinIO

Следующий пример создаёт репозиторий с именем test_repo в бакете MinIO bucket_minio.

CREATE REPOSITORY test_repo
WITH BROKER
ON LOCATION "s3://bucket_minio/backup"
PROPERTIES(
    "aws.s3.access_key" = "XXXXXXXXXXXXXXXXX",
    "aws.s3.secret_key" = "yyyyyyyyyyyyyyyyy",
    "aws.s3.endpoint" = "http://minio:9000"
);

После создания репозитория вы можете проверить его с помощью SHOW REPOSITORIES. После восстановления данных вы можете удалить репозиторий в Selena с помощью DROP REPOSITORY. Однако снимки данных, сохранённые во внешней системе хранения, не могут быть удалены через Selena. Их необходимо удалить вручную во внешней системе хранения.

Резервное копирование данных

После создания репозитория необходимо создать снимок данных и сохранить его во внешнем репозитории. Подробные инструкции см. в разделе BACKUP. BACKUP — это асинхронная операция. Вы можете проверить статус задания BACKUP с помощью SHOW BACKUP или отменить задание BACKUP с помощью CANCEL BACKUP.

Selena поддерживает ПОЛНОЕ резервное копирование на уровне детализации базы данных, таблицы или партиции.

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

Резервное копирование базы данных

Выполнение полного BACKUP базы данных создаст резервную копию всех таблиц, синхронных и асинхронных материализованных представлений, логических представлений и UDF в базе данных.

Следующие примеры создают резервную копию базы данных sr_hub в снимке sr_hub_backup и загружают снимок в репозиторий test_repo.

-- Поддерживается с версии v1.5.2.
BACKUP DATABASE sr_hub SNAPSHOT sr_hub_backup
TO test_repo;

-- Совместимо с синтаксисом более ранних версий.
BACKUP SNAPSHOT sr_hub.sr_hub_backup
TO test_repo;

Резервное копирование таблицы

Selena поддерживает резервное копирование и восстановление таблиц всех типов и стратегий партиционирования. Выполнение полного BACKUP таблицы создаст резервную копию таблицы и синхронных материализованных представлений, построенных на её основе.

Следующие примеры создают резервную копию таблицы sr_member из базы данных sr_hub в снимке sr_member_backup и загружают снимок в репозиторий test_repo.

-- Поддерживается с версии v1.5.2.
BACKUP DATABASE sr_hub SNAPSHOT sr_member_backup
TO test_repo
ON (TABLE sr_member);

-- Совместимо с синтаксисом более ранних версий.
BACKUP SNAPSHOT sr_hub.sr_member_backup
TO test_repo
ON (sr_member);

Следующий пример создаёт резервную копию двух таблиц, sr_member и sr_pmc, из базы данных sr_hub в снимке sr_core_backup и загружает снимок в репозиторий test_repo.

BACKUP DATABASE sr_hub SNAPSHOT sr_core_backup
TO test_repo
ON (TABLE sr_member, TABLE sr_pmc);

Следующий пример создаёт резервную копию всех таблиц из базы данных sr_hub в снимке sr_all_backup и загружает снимок в репозиторий test_repo.

BACKUP DATABASE sr_hub SNAPSHOT sr_all_backup
TO test_repo
ON (ALL TABLES);

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

Следующие примеры создают резервную копию партиции p1 таблицы sr_member из базы данных sr_hub в снимке sr_par_backup и загружают снимок в репозиторий test_repo.

-- Поддерживается с версии v1.5.2.
BACKUP DATABASE sr_hub SNAPSHOT sr_par_backup
TO test_repo
ON (TABLE sr_member PARTITION (p1));

-- Совместимо с синтаксисом более ранних версий.
BACKUP SNAPSHOT sr_hub.sr_par_backup
TO test_repo
ON (sr_member PARTITION (p1));

Вы можете указать несколько имён партиций, разделённых запятыми (,), для пакетного резервного копирования партиций.

Резервное копирование материализованного представления

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

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

Следующий пример создаёт резервную копию материализованного представления sr_mv1 из базы данных sr_hub в снимке sr_mv1_backup и загружает снимок в репозиторий test_repo.

BACKUP DATABASE sr_hub SNAPSHOT sr_mv1_backup
TO test_repo
ON (MATERIALIZED VIEW sr_mv1);

Следующий пример создаёт резервную копию двух материализованных представлений, sr_mv1 и sr_mv2, из базы данных sr_hub в снимке sr_mv2_backup и загружает снимок в репозиторий test_repo.

BACKUP DATABASE sr_hub SNAPSHOT sr_mv2_backup
TO test_repo
ON (MATERIALIZED VIEW sr_mv1, MATERIALIZED VIEW sr_mv2);

Следующий пример создаёт резервную копию всех материализованных представлений из базы данных sr_hub в снимке sr_mv3_backup и загружает снимок в репозиторий test_repo.

BACKUP DATABASE sr_hub SNAPSHOT sr_mv3_backup
TO test_repo
ON (ALL MATERIALIZED VIEWS);

Резервное копирование логического представления

Следующий пример создаёт резервную копию логического представления sr_view1 из базы данных sr_hub в снимке sr_view1_backup и загружает снимок в репозиторий test_repo.

BACKUP DATABASE sr_hub SNAPSHOT sr_view1_backup
TO test_repo
ON (VIEW sr_view1);

Следующий пример создаёт резервную копию двух логических представлений, sr_view1 и sr_view2, из базы данных sr_hub в снимке sr_view2_backup и загружает снимок в репозиторий test_repo.

BACKUP DATABASE sr_hub SNAPSHOT sr_view2_backup
TO test_repo
ON (VIEW sr_view1, VIEW sr_view2);

Следующий пример создаёт резервную копию всех логических представлений из базы данных sr_hub в снимке sr_view3_backup и загружает снимок в репозиторий test_repo.

BACKUP DATABASE sr_hub SNAPSHOT sr_view3_backup
TO test_repo
ON (ALL VIEWS);

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

Следующий пример создаёт резервную копию UDF sr_udf1 из базы данных sr_hub в снимке sr_udf1_backup и загружает снимок в репозиторий test_repo.

BACKUP DATABASE sr_hub SNAPSHOT sr_udf1_backup
TO test_repo
ON (FUNCTION sr_udf1);

Следующий пример создаёт резервную копию двух UDF, sr_udf1 и sr_udf2, из базы данных sr_hub в снимке sr_udf2_backup и загружает снимок в репозиторий test_repo.

BACKUP DATABASE sr_hub SNAPSHOT sr_udf2_backup
TO test_repo
ON (FUNCTION sr_udf1, FUNCTION sr_udf2);

Следующий пример создаёт резервную копию всех UDF из базы данных sr_hub в снимке sr_udf3_backup и загружает снимок в репозиторий test_repo.

BACKUP DATABASE sr_hub SNAPSHOT sr_udf3_backup
TO test_repo
ON (ALL FUNCTIONS);

Резервное копирование метаданных внешнего каталога

Следующий пример создаёт резервную копию метаданных внешнего каталога iceberg в снимке iceberg_backup и загружает снимок в репозиторий test_repo.

BACKUP EXTERNAL CATALOG (iceberg) SNAPSHOT iceberg_backup
TO test_repo;

Следующий пример создаёт резервную копию метаданных двух внешних каталогов, iceberg и hive, в снимке iceberg_hive_backup и загружает снимок в репозиторий test_repo.

BACKUP EXTERNAL CATALOGS (iceberg, hive) SNAPSHOT iceberg_hive_backup
TO test_repo;

Следующий пример создаёт резервную копию метаданных всех внешних каталогов в снимке all_catalog_backup и загружает снимок в репозиторий test_repo.

BACKUP ALL EXTERNAL CATALOGS SNAPSHOT all_catalog_backup
TO test_repo;

Чтобы отменить операцию BACKUP для внешних каталогов, выполните следующее выражение:

CANCEL BACKUP FOR EXTERNAL CATALOG;

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

Вы можете восстановить снимок данных, сохранённый во внешней системе хранения, в текущий или другие cluster Selena для восстановления или миграции данных.

При восстановлении объекта из снимка необходимо указать временную метку снимка.

Используйте выражение RESTORE для восстановления снимков данных из внешней системы хранения.

RESTORE — это асинхронная операция. Вы можете проверить статус задания RESTORE с помощью SHOW RESTORE или отменить задание RESTORE с помощью CANCEL RESTORE.

(Опционально) Создание репозитория в новом cluster

Чтобы мигрировать данные в другой cluster Selena, необходимо создать репозиторий с тем же именем репозитория и местоположением в целевом cluster, иначе вы не сможете просмотреть ранее сохранённые снимки данных. Подробности см. в разделе Создание репозитория.

Получение временной метки снимка

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

Следующий пример проверяет информацию о снимках в test_repo.

mysql> SHOW SNAPSHOT ON test_repo;
+------------------+-------------------------+--------+
| Snapshot         | Timestamp               | Status |
+------------------+-------------------------+--------+
| sr_member_backup | 2023-02-07-14-45-53-143 | OK     |
+------------------+-------------------------+--------+
1 row in set (1.16 sec)

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

Следующие примеры восстанавливают базу данных sr_hub из снимка sr_hub_backup в базу данных sr_hub в целевом cluster. Если база данных не существует в снимке, система вернёт ошибку. Если база данных не существует в целевом cluster, система создаст её автоматически.

-- Поддерживается с версии v1.5.2.
RESTORE SNAPSHOT sr_hub_backup
FROM test_repo
DATABASE sr_hub
PROPERTIES("backup_timestamp" = "2024-12-09-10-25-58-842");

-- Совместимо с синтаксисом более ранних версий.
RESTORE SNAPSHOT sr_hub.sr_hub_backup
FROM `test_repo`
PROPERTIES("backup_timestamp" = "2024-12-09-10-25-58-842");

Следующий пример восстанавливает базу данных sr_hub из снимка sr_hub_backup в базу данных sr_hub_new в целевом cluster. Если база данных sr_hub не существует в снимке, система вернёт ошибку. Если база данных sr_hub_new не существует в целевом cluster, система создаст её автоматически.

-- Поддерживается с версии v1.5.2.
RESTORE SNAPSHOT sr_hub_backup
FROM test_repo
DATABASE sr_hub AS sr_hub_new
PROPERTIES("backup_timestamp" = "2024-12-09-10-25-58-842");

Восстановление таблицы

Следующие примеры восстанавливают таблицу sr_member из базы данных sr_hub в снимке sr_member_backup в таблицу sr_member базы данных sr_hub в целевом cluster.

-- Поддерживается с версии v1.5.2.
RESTORE SNAPSHOT sr_member_backup
FROM test_repo
DATABASE sr_hub
ON (TABLE sr_member)
PROPERTIES ("backup_timestamp" = "2024-12-09-10-52-10-940");

-- Совместимо с синтаксисом более ранних версий.
RESTORE SNAPSHOT sr_hub.sr_member_backup
FROM test_repo
ON (sr_member)
PROPERTIES ("backup_timestamp"="2024-12-09-10-52-10-940");

Следующие примеры восстанавливают таблицу sr_member из базы данных sr_hub в снимке sr_member_backup в таблицу sr_member_new базы данных sr_hub_new в целевом cluster.

RESTORE SNAPSHOT sr_member_backup
FROM test_repo
DATABASE sr_hub  AS sr_hub_new
ON (TABLE sr_member AS sr_member_new)
PROPERTIES ("backup_timestamp" = "2024-12-09-10-52-10-940");

Следующий пример восстанавливает две таблицы, sr_member и sr_pmc, из базы данных sr_hub в снимке sr_core_backup в две таблицы, sr_member и sr_pmc, базы данных sr_hub в целевом cluster.

RESTORE SNAPSHOT sr_core_backup
FROM test_repo
DATABASE sr_hub
ON (TABLE sr_member, TABLE sr_pmc)
PROPERTIES ("backup_timestamp" = "2024-12-09-10-52-10-940");

Следующий пример восстанавливает все таблицы из базы данных sr_hub в снимке sr_all_backup.

RESTORE SNAPSHOT sr_all_backup
FROM test_repo
DATABASE sr_hub
ON (ALL TABLES);

Следующий пример восстанавливает одну из всех таблиц из базы данных sr_hub в снимке sr_all_backup.

RESTORE SNAPSHOT sr_all_backup
FROM test_repo
DATABASE sr_hub
ON (TABLE sr_member)
PROPERTIES ("backup_timestamp" = "2024-12-09-10-52-10-940");

Восстановление партиции

Следующие примеры восстанавливают партицию p1 таблицы sr_member в снимке sr_par_backup в партицию p1 таблицы sr_member в целевом cluster.

-- Поддерживается с версии v1.5.2.
RESTORE SNAPSHOT sr_par_backup
FROM test_repo
DATABASE sr_hub
ON (TABLE sr_member PARTITION (p1))
PROPERTIES ("backup_timestamp" = "2024-12-09-10-52-10-940");

-- Совместимо с синтаксисом более ранних версий.
RESTORE SNAPSHOT sr_hub.sr_par_backup
FROM test_repo
ON (sr_member PARTITION (p1))
PROPERTIES ("backup_timestamp" = "2024-12-09-10-52-10-940");

Вы можете указать несколько имён партиций, разделённых запятыми (,), для пакетного восстановления партиций.

Восстановление материализованного представления

Следующий пример восстанавливает материализованное представление sr_mv1 из базы данных sr_hub в снимке sr_mv1_backup в целевой cluster.

RESTORE SNAPSHOT sr_mv1_backup
FROM test_repo
DATABASE sr_hub
ON (MATERIALIZED VIEW sr_mv1)
PROPERTIES ("backup_timestamp" = "2024-12-09-10-52-10-940");

Следующий пример восстанавливает два материализованных представления, sr_mv1 и sr_mv2, из базы данных sr_hub в снимке sr_mv2_backup в целевой cluster.

RESTORE SNAPSHOT sr_mv2_backup
FROM test_repo
DATABASE sr_hub
ON (MATERIALIZED VIEW sr_mv1, MATERIALIZED VIEW sr_mv2)
PROPERTIES ("backup_timestamp" = "2024-12-09-10-52-10-940");

Следующий пример восстанавливает все материализованные представления из базы данных sr_hub в снимке sr_mv3_backup в целевой cluster.

RESTORE SNAPSHOT sr_mv3_backup
FROM test_repo
DATABASE sr_hub
ON (ALL MATERIALIZED VIEWS)
PROPERTIES ("backup_timestamp" = "2024-12-09-10-52-10-940");

Следующий пример восстанавливает одно из материализованных представлений из базы данных sr_hub в снимке sr_mv3_backup в целевой cluster.

RESTORE SNAPSHOT sr_mv3_backup
FROM test_repo
DATABASE sr_hub
ON (MATERIALIZED VIEW sr_mv1)
PROPERTIES ("backup_timestamp" = "2024-12-09-10-52-10-940");

к сведению

После RESTORE вы можете проверить статус материализованного представления с помощью SHOW MATERIALIZED VIEWS.

Если материализованное представление активно, его можно использовать сразу.
Если материализованное представление неактивно, это может быть связано с тем, что его базовые таблицы не были восстановлены. После восстановления всех базовых таблиц вы можете использовать ALTER MATERIALIZED VIEW для повторной активации материализованного представления.

Восстановление логического представления

Следующий пример восстанавливает логическое представление sr_view1 из базы данных sr_hub в снимке sr_view1_backup в целевой cluster.

RESTORE SNAPSHOT sr_view1_backup
FROM test_repo
DATABASE sr_hub
ON (VIEW sr_view1)
PROPERTIES ("backup_timestamp" = "2024-12-09-10-52-10-940");

Следующий пример восстанавливает два логических представления, sr_view1 и sr_view2, из базы данных sr_hub в снимке sr_view2_backup в целевой cluster.

RESTORE SNAPSHOT sr_view2_backup
FROM test_repo
DATABASE sr_hub
ON (VIEW sr_view1, VIEW sr_view2)
PROPERTIES ("backup_timestamp" = "2024-12-09-10-52-10-940");

Следующий пример восстанавливает все логические представления из базы данных sr_hub в снимке sr_view3_backup в целевой cluster.

RESTORE SNAPSHOT sr_view3_backup
FROM test_repo
DATABASE sr_hub
ON (ALL VIEWS)
PROPERTIES ("backup_timestamp" = "2024-12-09-10-52-10-940");

Следующий пример восстанавливает одно из всех логических представлений из базы данных sr_hub в снимке sr_view3_backup в целевой cluster.

RESTORE SNAPSHOT sr_view3_backup
FROM test_repo
DATABASE sr_hub
ON (VIEW sr_view1)
PROPERTIES ("backup_timestamp" = "2024-12-09-10-52-10-940");

Восстановление UDF

Следующий пример восстанавливает UDF sr_udf1 из базы данных sr_hub в снимке sr_udf1_backup в целевой cluster.

RESTORE SNAPSHOT sr_udf1_backup
FROM test_repo
DATABASE sr_hub
ON (FUNCTION sr_udf1)
PROPERTIES ("backup_timestamp" = "2024-12-09-10-52-10-940");

Следующий пример восстанавливает два UDF, sr_udf1 и sr_udf2, из базы данных sr_hub в снимке sr_udf2_backup в целевой cluster.

RESTORE SNAPSHOT sr_udf2_backup
FROM test_repo
DATABASE sr_hub
ON (FUNCTION sr_udf1, FUNCTION sr_udf2)
PROPERTIES ("backup_timestamp" = "2024-12-09-10-52-10-940");

Следующий пример восстанавливает все UDF из базы данных sr_hub в снимке sr_udf3_backup в целевой cluster.

RESTORE SNAPSHOT sr_udf3_backup
FROM test_repo
DATABASE sr_hub
ON (ALL FUNCTIONS)
PROPERTIES ("backup_timestamp" = "2024-12-09-10-52-10-940");

Следующий пример восстанавливает один из всех UDF из базы данных sr_hub в снимке sr_udf3_backup в целевой cluster.

RESTORE SNAPSHOT sr_udf3_backup
FROM test_repo
DATABASE sr_hub
ON (FUNCTION sr_udf1)
PROPERTIES ("backup_timestamp" = "2024-12-09-10-52-10-940");

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

Следующий пример восстанавливает метаданные внешнего каталога iceberg из снимка iceberg_backup в целевой cluster и переименовывает его в iceberg_new.

RESTORE SNAPSHOT iceberg_backup
FROM test_repo
EXTERNAL CATALOG (iceberg AS iceberg_new)
PROPERTIES ("backup_timestamp" = "2024-12-09-10-52-10-940");

Следующий пример восстанавливает метаданные двух внешних каталогов, iceberg и hive, из снимка iceberg_hive_backup в целевой cluster.

RESTORE SNAPSHOT iceberg_hive_backup
FROM test_repo
EXTERNAL CATALOGS (iceberg, hive)
PROPERTIES ("backup_timestamp" = "2024-12-09-10-52-10-940");

Следующий пример восстанавливает метаданные всех внешних каталогов из снимка all_catalog_backup в целевой cluster.

RESTORE SNAPSHOT all_catalog_backup
FROM test_repo
ALL EXTERNAL CATALOGS
PROPERTIES ("backup_timestamp" = "2024-12-09-10-52-10-940");

Чтобы отменить операцию RESTORE для внешних каталогов, выполните следующее выражение:

CANCEL RESTORE FOR EXTERNAL CATALOG;

Настройка заданий BACKUP или RESTORE

Вы можете оптимизировать производительность заданий BACKUP или RESTORE, изменив следующие параметры конфигурации в файле конфигурации BE be.conf:

Параметр конфигурации	Описание
make_snapshot_worker_count	Максимальное количество потоков для задач создания снимков заданий BACKUP на узле BE. По умолчанию: `5`. Увеличьте значение этого параметра для увеличения параллелизма задачи создания снимка.
release_snapshot_worker_count	Максимальное количество потоков для задач освобождения снимков неудавшихся заданий BACKUP на узле BE. По умолчанию: `5`. Увеличьте значение этого параметра для увеличения параллелизма задачи освобождения снимка.
upload_worker_count	Максимальное количество потоков для задач загрузки заданий BACKUP на узле BE. По умолчанию: `0`. `0` означает, что значение устанавливается равным количеству ядер CPU на машине, где находится BE. Увеличьте значение этого параметра для увеличения параллелизма задачи загрузки.
download_worker_count	Максимальное количество потоков для задач скачивания заданий RESTORE на узле BE. По умолчанию: `0`. `0` означает, что значение устанавливается равным количеству ядер CPU на машине, где находится BE. Увеличьте значение этого параметра для увеличения параллелизма задачи скачивания.

Примечания по использованию

Выполнение операций резервного копирования и восстановления на глобальном уровне, уровне базы данных, таблицы и партиции требует различных привилегий. Подробную информацию см. в разделе Настройка ролей на основе сценариев.
В каждой базе данных одновременно разрешено выполнение только одного задания BACKUP или RESTORE. В противном случае Selena вернёт ошибку.
Поскольку задания BACKUP и RESTORE занимают много ресурсов вашего cluster Selena, вы можете выполнять резервное копирование и восстановление данных, когда ваш cluster Selena не сильно загружен.
Selena не поддерживает указание алгоритмов сжатия данных для резервного копирования.
Поскольку данные резервируются в виде снимков, данные, загруженные после создания снимка, не включаются в снимок. Поэтому, если вы загружаете данные в старый cluster после создания снимка и до завершения задания RESTORE, вам также необходимо загрузить данные в cluster, в который восстанавливаются данные. Рекомендуется параллельно загружать данные в оба cluster в течение некоторого времени после завершения миграции данных, а затем перевести приложение на новый cluster после проверки корректности данных и сервисов.
До завершения задания RESTORE вы не можете оперировать таблицей, которая восстанавливается.
Таблицы с первичным ключом не могут быть восстановлены в cluster Selena версии ранее v1.5.2.
Вам не нужно создавать таблицу, которая будет восстановлена, в новом cluster перед её восстановлением. Задание RESTORE создаст её автоматически.
Если существует таблица с дублирующимся именем с таблицей, которая будет восстановлена, Selena сначала проверяет, соответствует ли схема существующей таблицы схеме таблицы, которая будет восстановлена. Если схемы совпадают, Selena перезаписывает существующую таблицу данными из снимка. Если схема не совпадает, задание RESTORE завершится неудачей. Вы можете либо переименовать таблицу, которая будет восстановлена, используя ключевое слово AS, либо удалить существующую таблицу перед восстановлением данных.
Если задание RESTORE перезаписывает существующую базу данных, таблицу или партицию, перезаписанные данные не могут быть восстановлены после того, как задание войдёт в фазу COMMIT. Если задание RESTORE завершится неудачей или будет отменено на этом этапе, данные могут быть повреждены и недоступны. В этом случае вы можете только выполнить операцию RESTORE снова и дождаться завершения задания. Поэтому мы рекомендуем не восстанавливать данные путём перезаписи, если вы не уверены, что текущие данные больше не используются. Операция перезаписи сначала проверяет согласованность метаданных между снимком и существующей базой данных, таблицей или партицией. Если обнаружено несоответствие, операция RESTORE не может быть выполнена.
В настоящее время Selena не поддерживает резервное копирование и восстановление конфигурационных данных, связанных с учётными записями пользователей, привилегиями и группами ресурсов.
В настоящее время Selena не поддерживает резервное копирование и восстановление отношений Colocate JOIN между таблицами.

Создание репозитория​

Резервное копирование данных​

Резервное копирование базы данных​

Резервное копирование таблицы​

Резервное копирование партиции​

Резервное копирование материализованного представления​

Резервное копирование логического представления​

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

Резервное копирование метаданных внешнего каталога​

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

(Опционально) Создание репозитория в новом cluster​

Получение временной метки снимка​

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

Восстановление таблицы​

Восстановление партиции​

Восстановление материализованного представления​

Восстановление логического представления​

Восстановление UDF​

Восстановление метаданных внешнего каталога​

Настройка заданий BACKUP или RESTORE​

Примечания по использованию​