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

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

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

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: идентификатор операции резервного копирования или восстановления, используется случайно сгенерированный 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:

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

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

  • Конечная точка S3, например https://mars-doc-test.s3.amazonaws.com/backup-S3/
  • Идентификатор ключа доступа, например ABC123
  • Секретный ключ доступа, например 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, поэтому по умолчанию разрешается совместное выполнение резервного копирования/восстановления. Когда эти параметры имеют значение false в кластере, только 1 резервное копирование/восстановление может выполняться в кластере одновременно.

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

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

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

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

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

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

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

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

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

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

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

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