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

На этой странице приведены рекомендации по аварийному восстановлению для ClickHouse Cloud, а также инструкции для клиентов по восстановлению после сбоя. ClickHouse Cloud в настоящее время не поддерживает автоматическое переключение или автоматическую синхронизацию между несколькими географическими регионами. Сначала полезно разобрать несколько определений. RPO (Recovery Point Objective): Максимально допустимая потеря данных, измеряемая во времени, после аварийного события. Пример: RPO в 30 минут означает, что в случае сбоя DB должна быть возможно восстановить до состояния, в котором данным не более 30 минут. Это, разумеется, зависит от того, как часто создаются резервные копии. RTO (Recovery Time Objective): Максимально допустимое время простоя до возобновления нормальной работы после сбоя. Пример: RTO в 30 минут означает, что в случае сбоя команда сможет восстановить данные и приложения и возобновить нормальную работу в течение 30 минут. Резервные копии базы данных и снимки: Резервные копии обеспечивают надежное долгосрочное хранение за счет создания отдельной копии данных. Снимки не создают дополнительную копию данных, обычно создаются быстрее и обеспечивают более низкие значения RPO. Резервная копия основного сервиса позволяет восстановиться в случае его недоступности. ClickHouse Cloud поддерживает следующие возможности резервных копий.

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

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

2. Внешние резервные копии (в собственном бакете хранилища клиента)

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

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

Клиенты могут настроить резервные копии так, чтобы они создавались чаще, вплоть до одного раза каждые 6 часов, чтобы улучшить RPO. Клиенты также могут настроить более длительный срок хранения. Резервные копии, доступные в настоящий момент для сервиса, перечислены на странице «резервная копия» в консоли ClickHouse Cloud. В этом разделе также отображается статус выполнения каждой резервной копии — успешно или ошибка.

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

​

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

Время резервного копирования и восстановления значительно зависит от объема данных, сложности схемы и количества таблиц. Приведенные ниже показатели получены в ходе внутреннего тестирования и не являются обязательствами по производительности. По результатам нашего тестирования, резервное копирование примерно 1 ТБ занимало около 10–15 минут, а 20 ТБ — около часа. Для больших датасетов требуется пропорционально больше времени, и резервное копирование нескольких сотен ТБ или более может занимать много часов, хотя на больших объемах проявляется эффект масштаба. Восстановление обычно выполняется медленнее, чем эквивалентное резервное копирование, особенно если оно включает длинную цепочку инкрементальных резервных копий, поскольку необходимо применить полную резервную копию и все последующие инкрементальные резервные копии в цепочке. Восстановление очень крупного сервиса может занимать более суток. Поскольку время выполнения в значительной степени зависит от ваших данных, схемы и конфигурации резервного копирования, мы настоятельно рекомендуем протестировать восстановление на собственных данных, прежде чем ориентироваться на какое-либо целевое время восстановления. В этом разделе рассматриваются различные варианты восстановления и порядок действий для каждого случая. В этом случае данные можно восстановить из резервной копии в другом сервисе в том же регионе. При использовании политики резервного копирования по умолчанию резервная копия может быть давностью до 24 часов, а при использовании настраиваемых резервных копий с интервалом 6 часов — до 6 часов.

​

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

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

1. Перейдите в раздел «Резервная копия» в консоли ClickHouse Cloud.
2. Нажмите на три точки в разделе «Действия» у нужной резервной копии, из которой вы хотите восстановить данные.
3. Укажите имя нового сервиса и восстановите данные из этой резервной копии

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

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

Есть ещё несколько вариантов, которые стоит рассмотреть.

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

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

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

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