Резервное копирование и восстановление в 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),
не включаются в резервные копии и не могут быть восстановлены этим способом.
Общий синтаксис
Дополнительные сведения о каждой команде см. в разделе "краткий обзор команд".
Краткое описание команд
Каждая из приведённых выше команд описана ниже подробнее:
| Команда | Описание |
|---|---|
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 ...] | Полный список настроек см. ниже |
Настройки
Общие настройки резервного копирования/восстановления
| Настройка | Описание | Значение по умолчанию |
|---|---|---|
id | Идентификатор операции резервного копирования или восстановления; если он не указан, генерируется случайный UUID. Если уже выполняется операция с тем же идентификатором, будет выброшено исключение. | |
compression_method | Указывает метод сжатия для резервной копии. См. раздел «Кодеки сжатия столбцов» | |
compression_level | Задает уровень сжатия резервной копии | |
password | Пароль к файлу на диске. | |
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 | Начальный таймаут backoff для операций [Zoo]Keeper при выполнении резервного копирования или восстановления | 100 |
backup_restore_keeper_retry_max_backoff_ms | Максимальный таймаут экспоненциальной задержки (backoff) для операций [Zoo]Keeper при резервном копировании или восстановлении | 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 при создании резервной копии | 1048576 |
backup_restore_batch_size_for_keeper_multi | Максимальный размер пакета для операции 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 — для случайного значения seed, иначе — значение параметра | 0 |
backup_restore_s3_retry_attempts | Настройка для Aws::Client::RetryStrategy: повторные попытки выполняются самим Aws::Client, 0 означает отсутствие повторных попыток. Применяется только для резервного копирования и восстановления. | 1000 |
max_backup_bandwidth | Максимальная скорость чтения в байтах в секунду для данной резервной копии на сервере. Ноль означает отсутствие ограничений. | 0 |
max_backups_io_thread_pool_size | ClickHouse использует потоки из пула Backups IO Thread для выполнения операций ввода-вывода при резервном копировании в S3. max_backups_io_thread_pool_size ограничивает максимальное количество потоков в этом пуле. | 1000 |
max_backups_io_thread_pool_free_size | Если количество простаивающих потоков в пуле Backups IO Thread pool превышает max_backup_io_thread_pool_free_size, ClickHouse освободит ресурсы, занятые этими потоками, и уменьшит размер пула. При необходимости потоки могут быть созданы снова. | 0 |
backups_io_thread_pool_queue_size | Максимальное количество задач, которые могут быть поставлены в очередь пула потоков Backups IO Thread. Рекомендуется оставлять эту очередь неограниченной из-за текущей логики резервного копирования в S3. Примечание: значение 0 (по умолчанию) означает неограниченную очередь. | 0 |
backup_threads | Максимальное число потоков, используемых при выполнении запросов BACKUP. | |
max_backup_bandwidth_for_server | Максимальная скорость чтения в байтах в секунду для всех резервных копий на сервере. Ноль — без ограничений. | 0 |
shutdown_wait_backups_and_restores | Если установлено значение true, ClickHouse будет ожидать завершения выполняющихся операций резервного копирования и восстановления перед завершением работы. | 1 |
Специальные настройки для S3
| Setting | Description | Default value |
|---|---|---|
use_same_s3_credentials_for_base_backup | Должен ли базовый резервный бэкап в S3 наследовать учётные данные доступа из запроса. Работает только с S3. | |
s3_storage_class | Класс хранилища, используемый для резервного копирования в S3. Например: STANDARD |
Специальные настройки для Azure
| Setting | Description | Default value |
|---|---|---|
azure_attempt_to_create_container | При использовании Azure Blob Storage определяет, следует ли создавать указанный контейнер, если он не существует. | true |
Администрирование и устранение неполадок
Команда резервного копирования возвращает id и status, и этот id можно
использовать, чтобы узнать статус резервной копии. Это очень полезно для
отслеживания прогресса длительных асинхронных (ASYNC) резервных копий. В примере ниже показан
сбой, который произошёл при попытке перезаписать существующий файл резервной
копии:
Помимо таблицы system.backups все операции резервного копирования и восстановления также протоколируются в системной таблице журнала
system.backup_log:
