Перейти к основному содержимому
Перейти к основному содержимому

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

Сводка команд​

ALL

Перед версией 23.4 ClickHouse, ALL применялся только к команде RESTORE.

Фон​

Хотя репликация обеспечивает защиту от аппаратных сбоев, она не защищает от человеческих ошибок: случайное удаление данных, удаление неправильной таблицы или таблицы на неправильном кластере, и программные ошибки, которые приводят к неверной обработке данных или их повреждению. В большинстве случаев такие ошибки повлияют на все реплики. ClickHouse имеет встроенные механизмы защиты от некоторых типов ошибок — например, по умолчанию вы не можете просто удалить таблицы с движком, подобным MergeTree, содержащие более 50 Гб данных. Однако эти механизмы защиты не охватывают все возможные случаи и могут быть обойдены.

Чтобы эффективно смягчить возможные человеческие ошибки, вам следует тщательно подготовить стратегию резервного копирования и восстановления ваших данных заранее.

Каждая компания имеет разные доступные ресурсы и бизнес-требования, поэтому не существует универсального решения для резервного копирования и восстановления ClickHouse, которое подошло бы под каждую ситуацию. То, что работает для одного гигабайта данных, вероятно, не сработает для десятков петабайт. Существует множество возможных подходов, каждый из которых имеет свои плюсы и минусы, которые будут обсуждены ниже. Использовать несколько подходов вместо одного — хорошая идея, чтобы компенсировать их разные недостатки.

примечание

Имейте в виду, что если вы что-то резервировали и никогда не пытались восстановить, есть вероятность, что восстановление не сработает должным образом, когда оно вам действительно понадобится (или по крайней мере займет больше времени, чем может позволить бизнес). Поэтому, какой бы подход к резервированию вы ни выбрали, убедитесь, что вы также автоматизировали процесс восстановления и регулярно практикуете его на запасном кластере ClickHouse.

Резервное копирование на локальный диск​

Настройка назначения резервного копирования​

В приведенных ниже примерах место назначения резервного копирования указывается как Disk('backups', '1.zip'). Чтобы подготовить назначение, добавьте файл в /etc/clickhouse-server/config.d/backup_disk.xml, указав место назначения для резервного копирования. Например, этот файл определяет диск с именем backups, а затем добавляет этот диск в список backups > allowed_disk:

Параметры​

Резервные копии могут быть полными или инкрементными и могут включать таблицы (включая материализованные представления, проекции и словари) и базы данных. Резервные копии могут быть синхронными (по умолчанию) или асинхронными. Они могут быть сжаты. Резервные копии могут быть защищены паролем.

Команды BACKUP и RESTORE принимают список имен DATABASE и TABLE, назначение (или источник), параметры и настройки:

  • Назначение для резервного копирования или источник для восстановления. Это основано на ранее определенном диске. Например Disk('backups', 'filename.zip')
  • ASYNC: резервное копирование или восстановление асинхронно
  • PARTITIONS: список партиций для восстановления
  • SETTINGS:
    • id: идентификатор операции резервного копирования или восстановления, используется случайно сгенерированный UUID, если не указан вручную. Если уже есть выполняющаяся операция с тем же id, возникает исключение.
    • compression_method и уровень сжатия
    • password для файла на диске
    • base_backup: назначение предыдущей резервной копии этого источника. Например, Disk('backups', '1.zip')
    • use_same_s3_credentials_for_base_backup: следует ли базовой резервной копии для S3 наследовать учетные данные из запроса. Работает только с S3.
    • use_same_password_for_base_backup: следует ли архиву базовой резервной копии наследовать пароль из запроса.
    • structure_only: если включено, позволяет резервировать или восстановить только операторы CREATE без данных таблиц
    • storage_policy: политика хранения для восстанавливаемых таблиц. Смотрите Использование нескольких блоковых устройств для хранения данных. Эта настройка применяется только к команде RESTORE. Указанная политика хранения применяется только к таблицам с движком из семейства MergeTree.
    • s3_storage_class: класс хранения, используемый для резервного копирования в S3. Например, STANDARD
    • azure_attempt_to_create_container: при использовании Azure Blob Storage, будет ли указанный контейнер пытаться создаваться, если он не существует. По умолчанию: true.
    • core settings также могут быть использованы здесь

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

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

Соответствующее восстановление:

примечание

Вышеуказанное восстановление не сработает, если таблица test.table содержит данные, вам придется удалить таблицу, чтобы протестировать восстановление, или использовать настройку allow_non_empty_tables=true:

Таблицы могут быть восстановлены или зарезервированы с новыми именами:

Инкрементные резервные копии​

Инкрементные резервные копии могут быть созданы, указав base_backup.

примечание

Инкрементные резервные копии зависят от базовой резервной копии. Базовая резервная копия должна быть доступна, чтобы восстановить из инкрементной резервной копии.

Постепенно сохраняйте новые данные. Настройка base_backup приводит к тому, что данные с предыдущей резервной копии в Disk('backups', 'd.zip') сохраняются в Disk('backups', 'incremental-a.zip'):

Восстановите все данные из инкрементной резервной копии и базовой резервной копии в новую таблицу test.table2:

Назначьте пароль для резервной копии​

Резервные копии, записанные на диск, могут иметь примененный пароль к файлу:

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

Настройки сжатия​

Если вы хотите указать метод или уровень сжатия:

Восстановление конкретных партиций​

Если конкретные партиции, связанные с таблицей, необходимо восстановить, их можно указать. Чтобы восстановить партиции 1 и 4 из резервной копии:

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

Резервные копии также могут храниться в виде tar-архивов. Функциональность такая же, как для zip, за исключением того, что пароль не поддерживается.

Запишите резервную копию в виде tar:

Соответствующее восстановление:

Чтобы изменить метод сжатия, правильный суффикс файла должен быть добавлен к имени резервной копии. Например, чтобы сжать архив tar с использованием gzip:

Поддерживаемые суффиксы файлов для сжатия: tar.gz, .tgz, tar.bz2, tar.lzma, .tar.zst, .tzst и .tar.xz.

Проверка статуса резервных копий​

Команда резервного копирования возвращает id и status, и это id может быть использован для получения статуса резервной копии. Это очень полезно для проверки прогресса длинных асинхронных резервных копий. Приведенный ниже пример показывает сбой, который произошел при попытке перезаписать существующий файл резервной копии:

Вместе с таблицей system.backups, все операции резервного копирования и восстановления также отслеживаются в таблице системного лога backup_log:

Настройка BACKUP/RESTORE для использования S3 Endpoint​

Чтобы записывать резервные копии в корзину S3, вам нужно три pieces информации:

  • S3 endpoint, например https://mars-doc-test.s3.amazonaws.com/backup-S3/
  • Access key ID, например ABC123
  • Secret access key, например Abc+123
примечание

Создание корзины S3 рассмотрено в Использование объектного хранилища S3 в качестве диска ClickHouse, просто вернитесь к этому документу после сохранения политики, нет необходимости настраивать ClickHouse для использования корзины S3.

Место назначения для резервной копии будет указано следующим образом:

Создание базовой (начальной) резервной копии​

Инкрементные резервные копии требуют базовой резервной копии, с которой можно начать, этот пример будет использован позже как базовая резервная копия. Первый параметр назначения S3 — это S3 endpoint, за которым следует каталог в корзине, который будет использоваться для этой резервной копии. В этом примере каталог называется my_backup.

Добавление дополнительных данных​

Инкрементные резервные копии заполняются разницей между базовой резервной копией и текущим содержимым таблицы, которую резервируют. Добавьте дополнительные данные перед проведением инкрементного резервного копирования:

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

Эта команда резервного копирования похожа на базовую резервную копию, но добавляет SETTINGS base_backup и местоположение базовой резервной копии. Обратите внимание, что назначение для инкрементной резервной копии не то же самое, что и базовая, это тот же endpoint с другой целевой директорией в корзине. Базовая резервная копия находится в my_backup, а инкрементная будет записана в my_incremental:

Восстановление из инкрементной резервной копии​

Эта команда восстанавливает инкрементную резервную копию в новую таблицу data3. Обратите внимание, что при восстановлении инкрементной резервной копии базовая резервная копия также включена. Укажите только инкрементную резервную копию при восстановлении:

Проверьте количество​

В оригинальной таблице data было две вставки, одна с 1,000 строк и одна с 100 строк, в общей сложности 1,100. Убедитесь, что восстановленная таблица содержит 1,100 строк:

Проверьте содержимое​

Это сравнивает содержимое оригинальной таблицы data с восстановленной таблицей data3:

BACKUP/RESTORE С использованием S3 диска​

Также возможно BACKUP/RESTORE в S3, настроив диск S3 в конфигурации хранения ClickHouse. Настройте диск следующим образом, добавив файл в /etc/clickhouse-server/config.d:

А затем BACKUP/RESTORE, как обычно:

примечание

Но имейте в виду, что:

  • Этот диск не следует использовать для MergeTree непосредственно, только для BACKUP/RESTORE
  • Если ваши таблицы поддерживаются S3 хранилищем и типы дисков различаются, он не использует вызовы CopyObject для копирования частей в целевую корзину, вместо этого он загружает и загружает их, что очень неэффективно. Предпочитайте использовать синтаксис BACKUP ... TO S3(<endpoint>) для этого сценария.

Использование именованных коллекций​

Именованные коллекции могут быть использованы для параметров BACKUP/RESTORE. Смотрите здесь для примера.

Альтернативы​

ClickHouse хранит данные на диске, и есть множество способов резервного копирования дисков. Вот некоторые альтернативы, которые использовались в прошлом и которые могут хорошо вписаться в вашу среду.

Дублирование исходных данных где-то еще​

Часто данные, которые поступают в ClickHouse, доставляются через какой-то постоянный очередь, например, Apache Kafka. В этом случае возможно настроить дополнительный набор подписчиков, которые будут читать тот же поток данных, пока он записывается в ClickHouse и хранить его в холодном хранилище где-то. Большинство компаний уже имеют какое-то рекомендуемое холодное хранилище, которое может быть объектным хранилищем или распределенной файловой системой, такой как HDFS.

Снимки файловой системы​

Некоторые локальные файловые системы предоставляют функциональность снимков (например, ZFS), но они могут не быть наилучшим выбором для обслуживания активных запросов. Возможное решение заключается в создании дополнительных реплик с использованием такого типа файловой системы и исключении их из таблиц Distributed, которые используются для запросов SELECT. Снимки на таких репликах будут недоступны для любых запросов, которые изменяют данные. В качестве бонуса, эти реплики могут иметь специальные аппаратные конфигурации с большим количеством дисков на сервер, что будет экономически целесообразно.

Для меньших объемов данных также может сработать простое INSERT INTO ... SELECT ... в удаленные таблицы.

Манипуляции с частями​

ClickHouse позволяет использовать запрос ALTER TABLE ... FREEZE PARTITION ... для создания локальной копии партиций таблицы. Это реализуется с помощью жестких ссылок на папку /var/lib/clickhouse/shadow/, поэтому обычно не требует дополнительного пространства на диске для старых данных. Созданные копии файлов не обрабатываются сервером ClickHouse, так что вы можете просто оставить их там: у вас будет простое резервное копирование, не требующее какой-либо дополнительной внешней системы, но оно все равно будет подвержено аппаратным проблемам. По этой причине лучше удаленно скопировать их в другое место, а затем удалить локальные копии. Распределенные файловые системы и объектные хранилища по-прежнему являются хорошими вариантами для этого, но обычные подключенные файловые серверы с достаточной емкостью также могут подойти (в этом случае передача будет происходить через сетевую файловую систему или, возможно, rsync). Данные можно восстановить из резервной копии с помощью ALTER TABLE ... ATTACH PARTITION ...

Для получения дополнительной информации о запросах, связанных с манипуляциями с партициями, смотрите документацию ALTER.

Доступен сторонний инструмент для автоматизации этого подхода: clickhouse-backup.

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

Для запрета одновременного резервного копирования/восстановления вы можете использовать эти настройки соответственно.

Значение по умолчанию для обоих равно true, поэтому по умолчанию одновременное резервное копирование/восстановление разрешено. Когда эти настройки равны false в кластере, одновременно разрешается только одна операция резервного копирования/восстановления.

Настройка BACKUP/RESTORE для использования AzureBlobStorage Endpoint​

Чтобы записывать резервные копии в контейнер AzureBlobStorage, вам потребуется следующая информация:

  • Строка подключения к AzureBlobStorage endpoint / url,
  • Контейнер,
  • Путь,
  • Имя учетной записи (если указывается url)
  • Ключ учетной записи (если указывается url)

Место назначения для резервной копии будет указано следующим образом:

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

Системные таблицы также могут быть включены в ваши процессы резервного копирования и восстановления, но их включение зависит от вашего конкретного случая использования.

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

Системные таблицы, которые хранят исторические данные, такие как те, которые имеют суффикс _log (например, query_log, part_log), могут быть зарезервированы и восстановлены так же, как и любая другая таблица. Если ваш случай использования зависит от анализа исторических данных — например, используя query_log для отслеживания производительности запросов или отладки проблем — рекомендуется включить эти таблицы в вашу стратегию резервного копирования. Однако, если исторические данные из этих таблиц не требуются, их можно исключить, чтобы сэкономить место в резервной копии.

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

Системные таблицы, связанные с управлением доступом, такие как пользователи, роли, row_policies, settings_profiles и квоты, получают особое обращение во время операций резервного копирования и восстановления. Когда эти таблицы включаются в резервную копию, их содержимое экспортируется в специальный файл accessXX.txt, который инкапсулирует эквивалентные SQL операторы для создания и настройки объектов доступа. При восстановлении процесс восстановления интерпретирует эти файлы и повторно применяет SQL-команды для воссоздания пользователей, ролей и других конфигураций.

Эта функция гарантирует, что конфигурация контроля доступа к кластеру ClickHouse может быть зарезервирована и восстановлена как часть общей настройки кластера.

Примечание: Эта функциональность работает только для конфигураций, управляемых через SQL-команды (называемых "Управление доступом и учетными записями на основе SQL"). Конфигурации доступа, определенные в конфигурационных файлах сервера ClickHouse (например, users.xml), не включаются в резервные копии и не могут быть восстановлены таким образом.