В этом разделе в общих чертах рассматриваются резервное копирование и восстановление в ClickHouse. Более подробное описание каждого способа резервного копирования см. на страницах, посвящённых конкретным способам, на боковой панели.
Введение
MergeTree, содержащие более
50 ГБ данных. Однако эти механизмы защиты не охватывают все возможные случаи, и
проблемы всё равно могут возникнуть.
Чтобы эффективно снизить риск человеческих ошибок, следует заранее тщательно
подготовить стратегию резервного копирования и восстановления данных.
У каждой компании разные ресурсы и бизнес-требования, поэтому
универсального решения для резервного копирования и восстановления ClickHouse,
которое подошло бы для любой ситуации, не существует. То, что работает для одного гигабайта данных,
скорее всего, не подойдёт для десятков PB данных. Существует множество возможных подходов
со своими плюсами и минусами, которые представлены в этом разделе документации.
Лучше использовать несколько подходов, а не ограничиваться одним, чтобы компенсировать
их различные недостатки.
Имейте в виду: если вы создали резервную копию, но ни разу не пытались её восстановить,
велика вероятность, что восстановление не сработает должным образом, когда оно действительно понадобится (или, по
крайней мере, займёт больше времени, чем может позволить себе бизнес). Поэтому какой бы подход к резервному копированию вы ни выбрали, обязательно автоматизируйте и процесс восстановления, а также регулярно
отрабатывайте его на резервном кластере ClickHouse.
| Страница | Описание |
|---|---|
| Резервное копирование/восстановление с использованием локального диска или диска S3 | Описывает резервное копирование и восстановление на локальный диск или диск S3 и с них |
| Резервное копирование/восстановление с использованием конечной точки S3 | Описывает резервное копирование и восстановление через конечную точку S3 |
| Резервное копирование/восстановление с использованием AzureBlobStorage | Описывает резервное копирование и восстановление в Azure Blob Storage и из него |
| Альтернативные методы | Рассматривает альтернативные методы резервного копирования |
| Резервное копирование снимков | Облегчённые снимки для таблиц SharedMergeTree с использованием объектного хранилища |
- быть полными или инкрементальными
- быть синхронными или асинхронными
- быть параллельными или последовательными
- быть сжатыми или несжатыми
- использовать именованные коллекции
- быть защищены паролем
- создаваться для системных таблиц, таблиц логов или таблиц управления доступом
Типы резервного копирования
- Полные резервные копии для небольших баз данных или критически важных данных.
- Инкрементные резервные копии для более крупных баз данных или если резервное копирование нужно выполнять часто и с минимальными затратами.
- Оба типа, например еженедельные полные резервные копии и ежедневные инкрементные резервные копии.
Синхронное и асинхронное резервное копирование
BACKUP и RESTORE также можно пометить как ASYNC. В этом случае
команда резервного копирования сразу возвращает управление, а сам процесс выполняется в фоновом режиме.
Если команды не помечены как ASYNC, процесс резервного копирования выполняется синхронно, и
команда не завершится, пока резервное копирование не будет завершено.
Параллельные и последовательные резервные копии
true, поэтому по умолчанию параллельное резервное копирование и восстановление
разрешены. Если в кластере для этих настроек задано значение false, в каждый момент времени в кластере
может выполняться только одно резервное копирование или восстановление.
Сжатые и несжатые резервные копии
compression_method и compression_level.
При создании резервной копии можно указать:
Использование именованных коллекций
- Скрывать учетные данные от пользователей без прав администратора
- Упрощать команды за счет централизованного хранения сложной конфигурации
- Поддерживать согласованность между операциями
- Избегать раскрытия учетных данных в журналах запросов
Резервное копирование системных таблиц, таблиц логов и таблиц управления доступом
_log (например,
query_log, part_log), можно включать в резервные копии и восстанавливать так же, как и любые другие таблицы.
Если ваш сценарий использования предполагает анализ исторических данных — например, использование query_log
для отслеживания производительности запросов или отладки проблем, — эти
таблицы рекомендуется включить в стратегию резервного копирования. Однако, если исторические данные из этих таблиц
не нужны, их можно исключить, чтобы сэкономить место в хранилище резервных копий.
Системные таблицы, связанные с управлением доступом, такие как users, roles, row_policies,
settings_profiles и quotas, особым образом обрабатываются при резервном копировании и восстановлении.
Когда эти таблицы включаются в резервную копию, их содержимое экспортируется в специальный
файл accessXX.txt, который содержит эквивалентные SQL-операторы для создания
и настройки сущностей доступа. При восстановлении процесс восстановления
интерпретирует эти файлы и повторно применяет SQL-команды, чтобы воссоздать пользователей,
роли и другие конфигурации. Эта возможность гарантирует, что конфигурацию
управления доступом кластера ClickHouse можно сохранить в резервной копии и восстановить как часть
общей конфигурации кластера.
Эта функциональность работает только для конфигураций, управляемых с помощью SQL-команд
(обозначаемых как “система управления доступом и учётными записями на основе SQL”).
Конфигурации доступа, определённые в файлах конфигурации сервера ClickHouse (например, users.xml),
не включаются в резервные копии и не могут быть восстановлены этим методом.
Общий синтаксис
Сводка команд
| Command | Description | |
|---|---|---|
BACKUP | Создаёт резервную копию указанных объектов | |
RESTORE | Восстанавливает объекты из резервной копии | |
TABLE [db.]table_name [AS [db.]table_name_in_backup] | Создаёт резервную копию или восстанавливает конкретную таблицу (её можно переименовать) | |
[PARTITION[S] partition_expr [,...]] | Создаёт резервную копию или восстанавливает только указанные партиции таблицы | |
DICTIONARY [db.]dictionary_name [AS [db.]name_in_backup] | Создаёт резервную копию или восстанавливает объект словаря | |
DATABASE database_name [AS database_name_in_backup] | Создаёт резервную копию или восстанавливает базу данных целиком (её можно переименовать) | |
TEMPORARY TABLE table_name [AS table_name_in_backup] | Создаёт резервную копию или восстанавливает временную таблицу (её можно переименовать) | |
VIEW view_name [AS view_name_in_backup] | Создаёт резервную копию или восстанавливает представление (его можно переименовать) | |
[EXCEPT TABLES ...] | Исключает определённые таблицы при резервном копировании базы данных | |
ALL | Создаёт резервную копию или восстанавливает всё (все базы данных, таблицы и т. д.). До версии 23.4 ClickHouse ALL можно было использовать только с командой RESTORE. | |
[EXCEPT {TABLES|DATABASES}...] | Исключает определённые таблицы или базы данных при использовании ALL | |
[ON CLUSTER 'cluster_name'] | Выполняет резервное копирование или восстановление на всём кластере ClickHouse | |
TO|FROM | Направление: TO — для пункта назначения резервной копии, FROM — для источника восстановления | |
File('<path>/<filename>') | Сохраняет в локальную файловую систему или восстанавливает из неё | |
Disk('<disk_name>', '<path>/') | Сохраняет на настроенный диск или восстанавливает с него | |
S3('<S3 endpoint>/<path>', '<Access key ID>', '<Secret access key>') | Сохраняет в Amazon S3 или S3-совместимое хранилище либо восстанавливает из них | |
[SETTINGS ...] | Ниже приведён полный список настроек | |
[ASYNC] | Запускает операцию асинхронно (сразу возвращает ID, который можно отслеживать) |
Настройки
| Параметр | Описание | Значение по умолчанию |
|---|---|---|
id | Идентификатор операции резервного копирования или восстановления; если не указан, используется случайно сгенерированный UUID. Если операция с таким идентификатором уже выполняется, генерируется исключение. | |
compression_method | Указывает метод сжатия для резервной копии. См. раздел “кодеки сжатия столбцов” | |
compression_level | Указывает уровень сжатия резервной копии | |
password | Пароль для архива резервной копии. Поддерживается только для архивов ZIP (.zip, .zipx). | |
base_backup | Пункт назначения базовой резервной копии, используемой при создании инкрементных резервных копий. Например: Disk('backups', '1.zip') | |
use_same_password_for_base_backup | Должен ли архив базовой резервной копии наследовать пароль из запроса. | |
structure_only | Если включено, выполняется только резервное копирование или восстановление операторов CREATE без фактических данных таблицы. | |
storage_policy | Политика хранения для восстанавливаемых таблиц. См. “использование нескольких блочных устройств для хранения данных. Применимо только к команде RESTORE. Только для таблиц с движком из семейства MergeTree. | |
allow_non_empty_tables | Позволяет команде RESTORE TABLE вставлять данные в непустые таблицы. Это приведет к смешению уже имеющихся в таблице данных с данными, извлеченными из резервной копии. Поэтому этот параметр может вызвать дублирование данных в таблице, используйте его с осторожностью. | 0 |
backup_restore_keeper_max_retries | Максимальное число повторных попыток для операций [Zoo]Keeper в ходе операции BACKUP или RESTORE. Значение должно быть достаточно большим, чтобы вся операция не завершилась сбоем из-за временного сбоя [Zoo]Keeper. | 1000 |
backup_restore_keeper_retry_initial_backoff_ms | Начальный тайм-аут задержки для операций [Zoo]Keeper во время BACKUP или RESTORE | 100 |
backup_restore_keeper_retry_max_backoff_ms | Максимальный тайм-аут задержки для операций [Zoo]Keeper во время BACKUP или RESTORE | 5000 |
backup_restore_failure_after_host_disconnected_for_seconds | Если в ходе операции BACKUP ON CLUSTER или RESTORE ON CLUSTER хост не пересоздаёт свой эфемерный узел ‘alive’ в ZooKeeper в течение указанного времени, то всё резервное копирование или восстановление считается завершившимся с ошибкой. Это значение должно превышать любое разумное время, необходимое хосту для повторного подключения к ZooKeeper после сбоя. Ноль означает отсутствие ограничения. | 3600 |
backup_restore_keeper_max_retries_while_initializing | Максимальное количество повторных попыток для операций [Zoo]Keeper при инициализации операции BACKUP ON CLUSTER или RESTORE ON CLUSTER. | 20 |
backup_restore_keeper_max_retries_while_handling_error | Максимальное число повторных попыток для операций в [Zoo]Keeper при обработке ошибки в операции BACKUP ON CLUSTER или RESTORE ON CLUSTER. | 20 |
backup_restore_finish_timeout_after_error_sec | Сколько времени инициатор должен ждать, пока остальные узлы отреагируют на узел ‘error’ и прекратят работу в рамках текущей операции BACKUP ON CLUSTER или RESTORE ON CLUSTER. | 180 |
backup_restore_keeper_value_max_size | Максимальный размер данных узла [Zoo]Keeper во время BACKUP | 1048576 |
backup_restore_batch_size_for_keeper_multi | Максимальный размер батча для мультизапроса к [Zoo]Keeper при резервном копировании или восстановлении | 1000 |
backup_restore_batch_size_for_keeper_multiread | Максимальный размер батча для запроса multiread к [Zoo]Keeper при резервном копировании или восстановлении | 10000 |
backup_restore_keeper_fault_injection_probability | Приблизительная вероятность сбоя запроса к Keeper во время резервного копирования или восстановления. Допустимое значение — в интервале [0.0f, 1.0f] | 0 |
backup_restore_keeper_fault_injection_seed | 0 — для случайного начального значения генератора случайных чисел, в противном случае — значение настройки | 0 |
backup_restore_s3_retry_attempts | Настройка для Aws::Client::RetryStrategy; Aws::Client сам выполняет повторные попытки, 0 означает отсутствие повторных попыток. Применяется только при резервном копировании и восстановлении. | 1000 |
max_backup_bandwidth | Максимальная скорость чтения в байтах в секунду для конкретной резервной копии на сервере. Ноль означает отсутствие ограничений. | 0 |
max_backups_io_thread_pool_size | ClickHouse использует потоки из пула потоков ввода-вывода резервных копий для выполнения операций ввода-вывода резервных копий в S3. max_backups_io_thread_pool_size ограничивает максимальное число потоков в этом пуле. | 1000 |
max_backups_io_thread_pool_free_size | Если число бездействующих потоков в пуле потоков ввода-вывода Backups превышает max_backup_io_thread_pool_free_size, ClickHouse освободит ресурсы, занимаемые бездействующими потоками, и уменьшит размер пула. При необходимости потоки могут быть созданы повторно. | 0 |
backups_io_thread_pool_queue_size | Максимальное количество задач, которые можно поставить в очередь в пуле потоков ввода-вывода Backups. Из-за текущей логики резервного копирования в S3 рекомендуется не ограничивать эту очередь. Примечание: значение 0 (по умолчанию) означает отсутствие ограничений. | 0 |
backup_threads | Максимальное количество потоков для выполнения запросов BACKUP. | |
max_backup_bandwidth_for_server | Максимальная скорость чтения в байтах в секунду для всех резервных копий на сервере. Ноль означает отсутствие ограничений. | 0 |
shutdown_wait_backups_and_restores | Если задано значение true, ClickHouse будет ждать завершения выполняющихся резервных копий и операций восстановления перед завершением работы. | 1 |
| Параметр | Описание | Значение по умолчанию |
|---|---|---|
use_same_s3_credentials_for_base_backup | Использовать ли для базовой резервной копии в S3 те же учётные данные, что и в запросе. Работает только с S3. | |
s3_storage_class | Класс хранения, используемый для резервной копии в S3. Например: STANDARD |
| Настройка | Описание | Значение по умолчанию | ||
|---|---|---|---|---|
azure_attempt_to_create_container | При использовании Azure Blob Storage: пытаться ли создать указанный контейнер, если он не существует. | true |
Администрирование и устранение неполадок
id и status, и этот id можно использовать, чтобы
узнать статус резервной копии. Это особенно полезно для отслеживания хода выполнения длительных
резервных копий ASYNC. В примере ниже показана ошибка, возникшая при попытке
перезаписать существующий файл резервной копии:
system.backups, все операции резервного копирования и восстановления также отслеживаются в системной таблице журнала
system.backup_log: