В этом разделе в общих чертах рассматриваются резервное копирование и восстановление в ClickHouse. Более подробное описание каждого способа резервного копирования см. на страницах, посвящённых конкретным способам, на боковой панели.
Введение
Хотя репликация обеспечивает защиту от аппаратных сбоев, она не защищает от человеческих ошибок: случайного удаления данных, удаления не той таблицы или таблицы не в том кластере, а также ошибок в программном обеспечении, которые приводят к некорректной обработке данных или их повреждению. Во многих случаях такие ошибки затронут все реплики. В ClickHouse есть встроенные механизмы защиты, предотвращающие некоторые типы ошибок; например, по умолчанию нельзя просто удалить таблицы с движком семействаMergeTree, содержащие более
50 ГБ данных. Однако эти механизмы защиты не охватывают все возможные случаи, и
проблемы всё равно могут возникнуть.
Чтобы эффективно снизить риск человеческих ошибок, следует заранее тщательно
подготовить стратегию резервного копирования и восстановления данных.
У каждой компании разные ресурсы и бизнес-требования, поэтому
универсального решения для резервного копирования и восстановления ClickHouse,
которое подошло бы для любой ситуации, не существует. То, что работает для одного гигабайта данных,
скорее всего, не подойдёт для десятков PB данных. Существует множество возможных подходов
со своими плюсами и минусами, которые представлены в этом разделе документации.
Лучше использовать несколько подходов, а не ограничиваться одним, чтобы компенсировать
их различные недостатки.
Имейте в виду: если вы создали резервную копию, но ни разу не пытались её восстановить,
велика вероятность, что восстановление не сработает должным образом, когда оно действительно понадобится (или, по
крайней мере, займёт больше времени, чем может позволить себе бизнес). Поэтому какой бы подход к резервному копированию вы ни выбрали, обязательно автоматизируйте и процесс восстановления, а также регулярно
отрабатывайте его на резервном кластере ClickHouse.
Резервные копии могут:
- быть полными или инкрементальными
- быть синхронными или асинхронными
- быть параллельными или последовательными
- быть сжатыми или несжатыми
- использовать именованные коллекции
- быть защищены паролем
- создаваться для системных таблиц, таблиц логов или таблиц управления доступом
Типы резервного копирования
Резервные копии бывают полными и инкрементными. Полная резервная копия — это полная копия данных, тогда как инкрементная резервная копия содержит изменения, внесенные в данные после последней полной резервной копии. Преимущество полных резервных копий в том, что это простой, независимый (от других резервных копий) и надежный способ восстановления. Однако их создание может занимать много времени и требовать много места. Инкрементные резервные копии, напротив, более эффективны как по времени, так и по занимаемому месту, но для восстановления данных необходимо, чтобы были доступны все резервные копии. В зависимости от ваших потребностей можно использовать:- Полные резервные копии для небольших баз данных или критически важных данных.
- Инкрементные резервные копии для более крупных баз данных или если резервное копирование нужно выполнять часто и с минимальными затратами.
- Оба типа, например еженедельные полные резервные копии и ежедневные инкрементные резервные копии.
Синхронное и асинхронное резервное копирование
КомандыBACKUP и RESTORE также можно пометить как ASYNC. В этом случае
команда резервного копирования сразу возвращает управление, а сам процесс выполняется в фоновом режиме.
Если команды не помечены как ASYNC, процесс резервного копирования выполняется синхронно, и
команда не завершится, пока резервное копирование не будет завершено.
Параллельные и последовательные резервные копии
По умолчанию ClickHouse позволяет выполнять резервное копирование и восстановление параллельно. Это означает, что вы можете одновременно запускать несколько операций резервного копирования или восстановления. Однако существуют настройки уровня сервера, которые позволяют запретить такое поведение. Если установить для этих настроек значение false, в кластере одновременно будет разрешено выполнять только одну операцию резервного копирования или восстановления. Это помогает избежать конкуренции за ресурсы или возможных конфликтов между операциями. Чтобы запретить параллельное резервное копирование/восстановление, можно использовать следующие настройки соответственно:true, поэтому по умолчанию параллельное резервное копирование и восстановление
разрешены. Если в кластере для этих настроек задано значение false, в каждый момент времени в кластере
может выполняться только одно резервное копирование или восстановление.
Сжатые и несжатые резервные копии
Резервные копии ClickHouse поддерживают сжатие с помощью параметровcompression_method и compression_level.
При создании резервной копии можно указать:
Использование именованных коллекций
Именованные коллекции позволяют хранить пары ключ-значение (например, учетные данные S3, конечные точки и настройки), которые можно повторно использовать при операциях резервного копирования и восстановления. Они помогают:- Скрывать учетные данные от пользователей без прав администратора
- Упрощать команды за счет централизованного хранения сложной конфигурации
- Поддерживать согласованность между операциями
- Избегать раскрытия учетных данных в журналах запросов
Резервное копирование системных таблиц, таблиц логов и таблиц управления доступом
Системные таблицы также можно включать в процессы резервного копирования и восстановления, но необходимость этого зависит от вашего конкретного сценария использования. Системные таблицы, в которых хранятся исторические данные, например таблицы с суффиксом_log (например,
query_log, part_log), можно включать в резервные копии и восстанавливать так же, как и любые другие таблицы.
Если ваш сценарий использования предполагает анализ исторических данных — например, использование query_log
для отслеживания производительности запросов или отладки проблем, — эти
таблицы рекомендуется включить в стратегию резервного копирования. Однако, если исторические данные из этих таблиц
не нужны, их можно исключить, чтобы сэкономить место в хранилище резервных копий.
Системные таблицы, связанные с управлением доступом, такие как users, roles, row_policies,
settings_profiles и quotas, особым образом обрабатываются при резервном копировании и восстановлении.
Когда эти таблицы включаются в резервную копию, их содержимое экспортируется в специальный
файл accessXX.txt, который содержит эквивалентные SQL-операторы для создания
и настройки сущностей доступа. При восстановлении процесс восстановления
интерпретирует эти файлы и повторно применяет SQL-команды, чтобы воссоздать пользователей,
роли и другие конфигурации. Эта возможность гарантирует, что конфигурацию
управления доступом кластера ClickHouse можно сохранить в резервной копии и восстановить как часть
общей конфигурации кластера.
Эта функциональность работает только для конфигураций, управляемых с помощью SQL-команд
(обозначаемых как “система управления доступом и учётными записями на основе SQL”).
Конфигурации доступа, определённые в файлах конфигурации сервера ClickHouse (например, users.xml),
не включаются в резервные копии и не могут быть восстановлены этим методом.
Общий синтаксис
Сводка команд
Подробное описание каждой из перечисленных выше команд приведено ниже:Резервное копирование таблицы без данных
EXCEPT DATA FROM {TABLE|TABLES} включает в резервную копию определение таблицы, но не её строки. Это полезно
для таблиц, содержимое которых можно сформировать заново после восстановления из резервной копии, например для целевых таблиц materialized view.
Эта конструкция определяет, что BACKUP записывает в резервную копию, но не влияет на возможности RESTORE. Если
RESTORE может создать таблицу заново, по определению без строк будет восстановлена пустая таблица. Однако конструкция не позволяет
восстановить таблицу, которую нельзя было бы восстановить без неё: возможность воссоздать таблицу по определению из резервной копии
зависит от движка, а некоторые движки вовсе не поддерживают такое восстановление. См.
Движки, таблицы которых RESTORE не может создать заново.
Конструкция действует только в пределах элемента, в котором она указана:
- В элементе
DATABASEилиALLможно указать любую таблицу, которую этот элемент включает в резервную копию:
table, dictionary, view, database или all: после
запятой такое имя без кавычек воспринимается как начало следующего элемента.
- Для элемента, относящегося к одному объекту (
TABLE,DICTIONARY,VIEW,TEMPORARY TABLE), в области действия находится только этот объект. Поэтому в условии нужно указать его и никакие другие объекты. Для каждой таблицы создайте отдельный элемент с отдельным условием:
EXCEPT DATA FROM более широкого элемента,
её данные попадают в резервную копию: указание таблицы как отдельного элемента подразумевает и её данные. Аналогично работает EXCEPT TABLES:
явно указанная таблица попадает в резервную копию, даже если более широкий элемент её исключает.
Данные внутренней таблицы materialized view (или внутренних таблиц таблицы TimeSeries)
исключаются по имени внешнего объекта; имена внутренних таблиц в этом предложении не допускаются.
EXCEPT DATA FROM {TABLE|TABLES} допустимо только для BACKUP. Команда RESTORE отклоняет это предложение, а не принимает его
как операцию без эффекта.
Движки, которые RESTORE не может воссоздать
Некоторые движки RESTORE не может воссоздать ни с EXCEPT DATA FROM {TABLE|TABLES}, ни без него. Для
таких таблиц эта конструкция по-прежнему влияет на размер резервной копии, но не позволяет восстановить их
пустыми: таблица вообще не появится, поскольку RESTORE откажется её создавать.
В частности, это касается отдельной таблицы MaterializedPostgreSQL. Сразу после создания она начала бы реплицировать данные из
действующего источника PostgreSQL, смешивая данные из снимка в резервной копии с текущим состоянием удалённого источника. Поэтому
RESTORE отклоняет её на этапе создания хранилища — ещё до создания таблицы — с ошибкой NOT_IMPLEMENTED. Эта
особенность движка действует и при восстановлении из обычной полной резервной копии.
Поддерживаемый способ — восстановить таблицу под другим именем в заранее созданную таблицу с движком ReplacingMergeTree
и структурой вложенной таблицы (включая столбцы _sign и _version):
allow_different_table_def необходим, поскольку определение таблицы в резервной копии использует движок
MaterializedPostgreSQL, а восстанавливают её намеренно с обычным движком ReplacingMergeTree.
Без EXCEPT DATA FROM TABLE та же команда RESTORE восстановит и данные таблицы.
Настройки
Общие настройки резервного копирования и восстановления
Настройки для S3
Настройки для Azure
Администрирование и устранение неполадок
Команда backup возвращаетid и status, и этот id можно использовать, чтобы
узнать статус резервной копии. Это особенно полезно для отслеживания хода выполнения длительных
резервных копий ASYNC. В примере ниже показана ошибка, возникшая при попытке
перезаписать существующий файл резервной копии:
system.backups, все операции резервного копирования и восстановления также отслеживаются в системной таблице журнала
system.backup_log: