Резервное копирование и восстановление в ClickHouse
В этом разделе в общих чертах рассматриваются операции резервного копирования и восстановления в ClickHouse. Более подробное описание каждого метода резервного копирования см. на страницах соответствующих методов в боковой панели.
Введение
Хотя репликация обеспечивает защиту от сбоев оборудования, она не защищает от человеческих ошибок: случайного удаления данных, удаления не той таблицы или таблицы не в том кластере, а также программных ошибок, приводящих к некорректной обработке данных или их повреждению.
Во многих случаях такие ошибки затронут все реплики. В ClickHouse есть встроенные
механизмы безопасности для предотвращения некоторых типов ошибок, например, по умолчанию
вы не можете просто удалить таблицы с движком семейства MergeTree, содержащие более
50 Гб данных. Однако эти механизмы не охватывают все возможные случаи, и
проблемы все равно могут возникать.
Чтобы эффективно снизить риск человеческих ошибок, следует заранее тщательно подготовить стратегию резервного копирования и восстановления данных.
У каждой компании свои доступные ресурсы и бизнес‑требования, поэтому не существует универсального решения для резервного копирования и восстановления ClickHouse, подходящего для любой ситуации. То, что работает для одного гигабайта данных, скорее всего, не будет работать для десятков петабайт данных. Существует множество возможных подходов со своими плюсами и минусами, которые представлены в этом разделе документации. Имеет смысл использовать несколько подходов, а не только один, чтобы компенсировать их различные недостатки.
Имейте в виду, что если вы что‑то сохранили в резервной копии, но ни разу не пробовали это восстановить, велика вероятность, что восстановление не сработает должным образом, когда оно действительно понадобится (или как минимум займет больше времени, чем бизнес может себе позволить). Поэтому, какой бы подход к резервному копированию вы ни выбрали, обязательно автоматизируйте и процесс восстановления и регулярно отрабатывайте его на запасном кластере ClickHouse.
На следующих страницах описаны различные методы резервного копирования и восстановления, доступные в ClickHouse:
| Страница | Описание |
|---|---|
| Резервное копирование/восстановление с использованием локального диска или диска S3 | Описывает резервное копирование/восстановление на локальный диск или S3‑диск и с них |
| Резервное копирование/восстановление с использованием S3 endpoint | Описывает резервное копирование/восстановление на конечную точку S3 и с нее |
| Резервное копирование/восстановление с использованием AzureBlobStorage | Описывает резервное копирование/восстановление в хранилище BLOB Azure и из него |
| Альтернативные методы | Описывает альтернативные методы резервного копирования |
Резервные копии могут:
- быть полными или инкрементальными
- быть синхронными или асинхронными
- быть параллельными или непараллельными
- быть сжатыми или несжатыми
- использовать именованные коллекции
- быть защищены паролем
- создаваться для системных таблиц, лог‑таблиц или таблиц управления доступом
Типы резервных копий
Резервные копии могут быть полными или инкрементальными. Полные резервные копии представляют собой полную копию данных, тогда как инкрементальные содержат только изменения по сравнению с последней полной резервной копией.
Полные резервные копии просты, независимы (от других резервных копий) и являются надежным методом восстановления. Однако их создание может занимать много времени и требовать значительного объема дискового пространства. Инкрементальные резервные копии, напротив, более эффективны как по времени, так и по занимаемому пространству, но для восстановления данных требуется наличие всех резервных копий.
В зависимости от ваших потребностей вы можете использовать:
- Полные резервные копии для небольших баз данных или критически важных данных.
- Инкрементальные резервные копии для крупных баз данных или когда резервное копирование нужно выполнять часто и экономично.
- Оба варианта, например, еженедельные полные резервные копии и ежедневные инкрементальные.
Синхронные и асинхронные резервные копии
Команды BACKUP и RESTORE также могут выполняться с модификатором ASYNC. В этом случае
команда резервного копирования завершается немедленно, а процесс создания резервной копии продолжается в фоновом режиме.
Если команды не помечены ASYNC, процесс резервного копирования выполняется синхронно, и
выполнение команды блокируется до завершения резервного копирования.
Параллельные и последовательные резервные копии
По умолчанию ClickHouse разрешает параллельное создание и восстановление резервных копий. Это означает, что вы
можете инициировать несколько операций резервного копирования или восстановления одновременно. Однако
существуют серверные настройки, позволяющие запретить такое поведение. Если установить
эти настройки в значение false, в кластере одновременно может выполняться только одна операция резервного копирования или восстановления. Это помогает избежать конкуренции за ресурсы и потенциальных конфликтов между операциями.
Чтобы запретить параллельное резервное копирование/восстановление, вы можете использовать следующие настройки:
Значение по умолчанию для обоих параметров — true, поэтому по умолчанию параллельные операции резервного копирования и восстановления разрешены. Если эти настройки на кластере имеют значение false, одновременно в кластере может выполняться только одна операция резервного копирования или восстановления.
Сжатые и несжатые бэкапы
Бэкапы ClickHouse поддерживают сжатие, настраиваемое через параметры compression_method и compression_level.
При создании бэкапа вы можете указать:
Использование именованных коллекций
Именованные коллекции позволяют хранить пары ключ-значение (например, учетные данные S3, endpoints и настройки), которые можно повторно использовать в операциях резервного копирования и восстановления. Они помогают:
- Скрывать учетные данные от пользователей без административного доступа
- Упрощать команды за счет централизованного хранения сложной конфигурации
- Поддерживать согласованность во всех операциях
- Избегать раскрытия учетных данных в журналах запросов
См. раздел "именованные коллекции" для получения дополнительной информации.
Резервное копирование системных таблиц, таблиц логов или таблиц управления доступом
Системные таблицы также могут быть включены в ваши процессы резервного копирования и восстановления, однако необходимость их включения зависит от конкретного сценария использования.
Системные таблицы, которые хранят исторические данные, например, с суффиксом _log (такие как
query_log, part_log), можно сохранять в резервную копию и восстанавливать как любые другие таблицы.
Если ваш сценарий опирается на анализ исторических данных — например, использование query_log
для отслеживания производительности запросов или отладки проблем — рекомендуется включать эти
таблицы в стратегию резервного копирования. Однако, если исторические данные из этих таблиц
не требуются, их можно исключить для экономии места, занимаемого резервными копиями.
Системные таблицы, связанные с управлением доступом, такие как users, roles, row_policies,
settings_profiles и quotas, обрабатываются особым образом при операциях резервного копирования и восстановления.
Когда эти таблицы включены в резервную копию, их содержимое экспортируется в специальный
файл accessXX.txt, который содержит эквивалентные SQL-операторы для создания
и настройки сущностей доступа. При восстановлении процесс восстановления
интерпретирует эти файлы и повторно применяет SQL-команды для воссоздания пользователей,
ролей и других конфигураций. Данная возможность обеспечивает резервное копирование и восстановление конфигурации управления доступом к кластеру ClickHouse как части
общей конфигурации кластера.
Эта функциональность работает только для конфигураций, управляемых через SQL-команды
(называемых "SQL-driven Access Control and Account Management").
Конфигурации доступа, определённые в конфигурационных файлах сервера ClickHouse (например, users.xml),
не включаются в резервные копии и не могут быть восстановлены этим способом.
Общий синтаксис
See "command summary" for more details of each command.
Краткое описание команд
Каждая из приведённых выше команд описана ниже подробнее:
| Команда | Описание |
|---|---|
BACKUP | Создаёт резервную копию указанных объектов |
RESTORE | Восстанавливает объекты из резервной копии |
[ASYNC] | Выполняет операцию асинхронно (немедленно возвращает идентификатор, по которому можно отслеживать выполнение) |
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 ...] | Полный список настроек см. ниже |
Настройки
Общие настройки резервного копирования/восстановления
| Setting | Description | Default value |
|---|---|---|
id | ID of backup or restore operation, randomly generated UUID is used if not specified. If there's already a running operation with the same ID, an exception is thrown. | |
compression_method | Specifies the compression method for the backup. See section "column compression codecs" | |
compression_level | Specifies the compression level for the backup | |
password | Password for the file on disk. | |
base_backup | The destination of the base backup used for incremental backups. For example: Disk('backups', '1.zip') | |
use_same_password_for_base_backup | Whether base backup archive should inherit the password from the query. | |
structure_only | If enabled, only backs up or restores the CREATE statements without the actual table data. | |
storage_policy | Storage policy for the tables being restored. See "using multiple block devices for data storage. Only applicable to the RESTORE command. Applies only to tables with an engine from the MergeTree family. | |
allow_non_empty_tables | Allows RESTORE TABLE to insert data into non-empty tables. This will mix earlier data in the table with the data extracted from the backup. This setting can therefore cause data duplication in the table, use with caution. | 0 |
backup_restore_keeper_max_retries | Max retries for [Zoo]Keeper operations in the middle of a BACKUP or RESTORE operation. Should be big enough so the whole operation won't fail because of a temporary [Zoo]Keeper failure. | 1000 |
backup_restore_keeper_retry_initial_backoff_ms | Initial backoff timeout for [Zoo]Keeper operations during backup or restore | 100 |
backup_restore_keeper_retry_max_backoff_ms | Max backoff timeout for [Zoo]Keeper operations during backup or restore | 5000 |
backup_restore_failure_after_host_disconnected_for_seconds | If a host during a BACKUP ON CLUSTER or RESTORE ON CLUSTER operation doesn't recreate its ephemeral 'alive' node in ZooKeeper for this amount of time then the whole backup or restore is considered as failed. This value should be bigger than any reasonable time for a host to reconnect to ZooKeeper after a failure. Zero means unlimited. | 3600 |
backup_restore_keeper_max_retries_while_initializing | Max retries for [Zoo]Keeper operations during the initialization of a BACKUP ON CLUSTER or RESTORE ON CLUSTER operation. | 20 |
backup_restore_keeper_max_retries_while_handling_error | Max retries for [Zoo]Keeper operations while handling an error of a BACKUP ON CLUSTER or RESTORE ON CLUSTER operation. | 20 |
backup_restore_finish_timeout_after_error_sec | How long the initiator should wait for other host to react to the 'error' node and stop their work on the current BACKUP ON CLUSTER or RESTORE ON CLUSTER operation. | 180 |
backup_restore_keeper_value_max_size | Maximum size of data of a [Zoo]Keeper's node during backup | 1048576 |
backup_restore_batch_size_for_keeper_multi | Maximum size of batch for multi request to [Zoo]Keeper during backup or restore | 1000 |
backup_restore_batch_size_for_keeper_multiread | Maximum size of batch for multiread request to [Zoo]Keeper during backup or restore | 10000 |
backup_restore_keeper_fault_injection_probability | Approximate probability of failure for a keeper request during backup or restore. Valid value is in interval [0.0f, 1.0f] | 0 |
backup_restore_keeper_fault_injection_seed | 0 for a random seed, otherwise the setting value | 0 |
backup_restore_s3_retry_attempts | Setting for Aws::Client::RetryStrategy, Aws::Client does retries itself, 0 means no retries. It takes place only for backup/restore. | 1000 |
max_backup_bandwidth | The maximum read speed in bytes per second for particular backup on server. Zero means unlimited. | 0 |
max_backups_io_thread_pool_size | ClickHouse uses threads from the Backups IO Thread pool to do S3 backup IO operations. max_backups_io_thread_pool_size limits the maximum number of threads in the pool. | 1000 |
max_backups_io_thread_pool_free_size | If the number of idle threads in the Backups IO Thread pool exceeds max_backup_io_thread_pool_free_size, ClickHouse will release resources occupied by idling threads and decrease the pool size. Threads can be created again if necessary. | 0 |
backups_io_thread_pool_queue_size | The maximum number of jobs that can be scheduled on the Backups IO Thread pool. It is recommended to keep this queue unlimited due to the current S3 backup logic. Note: A value of 0 (default) means unlimited. | 0 |
backup_threads | The maximum number of threads to execute BACKUP requests. | |
max_backup_bandwidth_for_server | The maximum read speed in bytes per second for all backups on server. Zero means unlimited. | 0 |
shutdown_wait_backups_and_restores | If set to true ClickHouse will wait for running backups and restores to finish before shutdown. | 1 |
Специальные настройки для S3
| Setting | Description | Default value |
|---|---|---|
use_same_s3_credentials_for_base_backup | Whether base backup to S3 should inherit credentials from the query. Only works with S3. | |
s3_storage_class | The storage class used for S3 backup. For example: STANDARD |
Специальные настройки для Azure
| Setting | Description | Default value |
|---|---|---|
azure_attempt_to_create_container | When using Azure Blob Storage, whether to attempt creating the specified container if it doesn't exist. | true |
Администрирование и устранение неполадок
Команда резервного копирования возвращает id и status, и этот id можно
использовать, чтобы узнать статус резервной копии. Это очень полезно для
отслеживания прогресса длительных асинхронных (ASYNC) резервных копий. В примере ниже показан
сбой, который произошёл при попытке перезаписать существующий файл резервной
копии:
Помимо таблицы system.backups все операции резервного копирования и восстановления также протоколируются в системной таблице журнала
system.backup_log:
