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

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

Резюме команд​

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 принимают список имен БАЗ ДАННЫХ и ТАБЛИЦ, назначение (или источник), параметры и настройки:

  • Назначение для резервного копирования или источник для восстановления. Это основано на диске, определенном ранее. Например, Disk('backups', 'filename.zip')
  • ASYNC: резервное копирование или восстановление асинхронно
  • PARTITIONS: список разделов для восстановления
  • SETTINGS:
    • id: 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.
    • основные настройки также могут быть использованы здесь

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

Создаем резервную копию и затем восстанавливаем таблицу:

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

примечание

Вышеуказанное восстановление не сработает, если таблица 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:

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

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

  • Конечная точка S3, например, 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, за которой следует директория внутри ведра, которую необходимо использовать для этой резервной копии. В этом примере директория называется my_backup.

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

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

Сделать инкрементное резервное копирование​

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

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

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

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

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

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

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

Резервное копирование/восстановление с использованием 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), но они могут быть не лучшим выбором для обслуживания живых запросов. Возможное решение — создать дополнительные реплики с такой файловой системой и исключить их из распределенных таблиц, которые используются для SELECT запросов. Снимки на таких репликах не будут доступны для любых запросов, которые изменяют данные. В качестве бонуса эти реплики могут иметь специальные аппаратные конфигурации с большим количеством подключенных дисков на сервер, что было бы экономически выгодно.

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

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

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

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

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

Настройки, чтобы запретить одновременное резервное копирование/восстановление​

Чтобы запретить одновременное резервное копирование/восстановление, вы можете использовать следующие настройки соответственно.

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

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

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

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

Назначение для резервного копирования будет указано так:

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

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

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

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

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

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

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

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