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

Отказоустойчивость данных

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

Совет

Клиентам следует периодически выполнять тестовое восстановление из резервной копии, чтобы определить фактическое значение RTO для масштаба и конфигурации их сервиса.

Определения

Для начала полезно рассмотреть несколько определений.

RPO (Recovery Point Objective, целевой параметр точки восстановления): Максимально допустимая потеря данных, измеряемая временем, прошедшим с момента последней доступной точки восстановления до сбоя. Пример: RPO 30 минут означает, что в случае сбоя базу данных можно восстановить к состоянию не старше 30 минут. Это, разумеется, зависит от того, как часто создаются резервные копии.

RTO (Recovery Time Objective, целевой параметр времени восстановления): Максимально допустимое время простоя до восстановления нормальной работы после сбоя. Пример: RTO 30 минут означает, что в случае сбоя команда сможет восстановить данные и приложения и вернуть систему к нормальной работе в течение 30 минут.

Резервные копии и снимки базы данных: Резервные копии обеспечивают долговременное надежное хранение с отдельной копией данных. Снимки не создают дополнительную копию данных, обычно выполняются быстрее и обеспечивают более строгие значения RPO.

Резервные копии базы данных

Наличие резервной копии основного сервиса позволяет восстановить его в случае простоя или недоступности. ClickHouse Cloud поддерживает следующие варианты резервного копирования.

  1. Резервные копии по умолчанию

По умолчанию ClickHouse Cloud делает резервную копию вашего сервиса каждые 24 часа. Эти резервные копии находятся в том же регионе, что и сервис, и создаются в бакете хранилища CSP (cloud service provider) ClickHouse. Если данные в основном сервисе будут повреждены, резервную копию можно использовать для восстановления нового сервиса.

  1. Внешние резервные копии (в собственном storage bucket клиента)

Клиенты уровня Enterprise Tier могут экспортировать резервные копии в объектное хранилище в своём аккаунте — в том же регионе или в другом регионе. Поддержка экспорта резервных копий между разными облачными провайдерами (cross-cloud) будет добавлена позже. За передачу данных при резервном копировании между регионами и между облачными провайдерами будет взиматься соответствующая плата.

Примечание

Эта функция в настоящее время недоступна в сервисах PCI/HIPAA.

  1. Настраиваемые резервные копии

Клиенты могут настраивать резервное копирование с более высокой частотой, с периодичностью до одного раза в 6 часов, чтобы улучшить RPO. Также клиенты могут настраивать более длительный срок хранения резервных копий.

Резервные копии, доступные в данный момент для сервиса, перечислены на странице «Backups» в консоли ClickHouse Cloud. В этом разделе также отображается статус (успешно/с ошибкой) для каждой резервной копии.

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

  1. Резервные копии по умолчанию, размещённые в бакете ClickHouse Cloud, могут быть восстановлены в новый сервис в том же регионе.
  2. Внешние резервные копии (в объектном хранилище клиента) могут быть восстановлены в новый сервис в том же или другом регионе.

Рекомендации по длительности резервного копирования и восстановления

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

В наших тестах мы наблюдали, что создание относительно небольших резервных копий размером около 1 ТБ может занимать 10–15 минут или дольше. Резервные копии размером менее 20 ТБ обычно создаются в течение часа, а резервное копирование около 50 ТБ данных должно занимать 2–3 часа. На больших объемах резервное копирование выигрывает от эффекта масштаба, и мы наблюдали, что резервные копии объемом до 1 ПБ для некоторых внутренних сервисов завершались менее чем за 10 часов.

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

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

Примечание

В настоящее время НЕТ поддержки автоматического переключения (failover) между двумя экземплярами ClickHouse Cloud, как в одном, так и в разных регионах. В настоящее время НЕТ автоматической синхронизации данных между разными сервисами ClickHouse Cloud в одном или разных регионах, то есть репликации в режиме Active-Active.

Процесс восстановления

В этом разделе описаны различные варианты восстановления и порядок действий для каждого из них.

Повреждение данных основного сервиса

В этом случае данные можно восстановить из резервной копии в другой сервис в том же регионе. Резервная копия может быть возрастом до 24 часов при использовании политики резервного копирования по умолчанию или до 6 часов (при использовании настраиваемых резервных копий с частотой каждые 6 часов).

Шаги восстановления

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

Перейдите в раздел «Backups» консоли ClickHouse Cloud.

Нажмите на три точки в столбце «Actions» для конкретной резервной копии, из которой вы хотите выполнить восстановление.

Задайте новому сервису уникальное имя и выполните восстановление из этой резервной копии.

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

Недоступность основного региона

Клиенты уровня Enterprise могут экспортировать резервные копии в собственный бакет облачного провайдера. Если вы обеспокоены сбоями на уровне региона, рекомендуется экспортировать резервные копии в другой регион. Имейте в виду, что при этом будут взиматься платежи за межрегиональную передачу данных.

Если основной регион становится недоступен, резервную копию, размещённую в другом регионе, можно восстановить в новый сервис в этом другом регионе.

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

  • Обновление переменных окружения или секретов
  • Перезапуск сервисов приложения для установления новых подключений
Примечание

Резервное копирование и восстановление во внешний бакет в настоящее время не поддерживается для сервисов, использующих Transparent Data Encryption (TDE).

Дополнительные варианты

Существуют дополнительные варианты, которые стоит рассмотреть.

  1. Двойная запись в отдельные кластеры

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

  1. Использование репликации CSP

В этом варианте вы используете встроенную репликацию объектного хранилища облачного провайдера для копирования данных. Например, с BYOB вы можете экспортировать резервную копию в бакет, который принадлежит вам в основным регионе, и реплицировать его в другой регион, используя AWS cross region replication.