Как восстановиться после поврежденного снимка Keeper

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

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

Обзор снимков Keeper

Что такое снимок?

Снимок — это сериализованное состояние внутренних данных Keeper (таких как метаданные о кластерах, путях координации таблиц и конфигурациях) на определённый момент времени. Снимки крайне важны для повторной синхронизации узлов Keeper в кластере, восстановления метаданных при сбоях, а также для процессов запуска и перезапуска, которым требуется заведомо корректное состояние Keeper.

Где найти снимки?

Снимки хранятся в виде файлов в локальной файловой системе узлов Keeper. По умолчанию они находятся в /var/lib/clickhouse/coordination/snapshots/ либо по пользовательскому пути, заданному параметром snapshot_storage_path в файле keeper_server.xml. Снимки именуются последовательно (например, snapshot.23): чем новее снимок, тем больше его номер. В многоузловых кластерах у каждого узла Keeper есть свой каталог снимков.

Для восстановления критически важно, чтобы снимки на разных узлах были согласованными.

Основные симптомы и проявления поврежденных снимков Keeper

В таблице ниже перечислены некоторые распространенные симптомы и проявления поврежденных снимков Keeper:

Категория	Тип проблемы	На что обратить внимание
Эксплуатационные проблемы	Режим только для чтения	Таблицы неожиданно переходят в режим только для чтения
	Сбои запросов	Постоянные сбои запросов с ошибками `Coordination::Exception`
Повреждение метаданных	Устаревшие метаданные	Удаленные таблицы не отображаются; сбои операций из-за устаревших метаданных
Перегрузка ресурсов	Исчерпание системных ресурсов	Узлы Keeper потребляют чрезмерно много CPU, памяти или дискового пространства; возможен простой
	Диск переполнен	Переполнение диска во время создания снимка
Резервное копирование и восстановление	Сбои резервного копирования	Сбой резервного копирования из-за отсутствующих или несогласованных метаданных Keeper
Создание/передача снимков	Сбой Keeper	Сбой Keeper во время создания снимка (ищите ошибки “SEGFAULT”)
	Повреждение при передаче снимка	Повреждение во время передачи снимка между репликами
	Состояние гонки	Состояние гонки во время компактации журнала — фоновый поток коммита обращается к удаленным журналам
	Сетевая синхронизация	Сетевые проблемы, мешающие синхронизации снимка от лидера к ведомым узлам

Признаки в журналах: Прежде чем диагностировать повреждение снимка, проверьте журналы Keeper на наличие характерных шаблонов ошибок:

Тип журнала	На что обратить внимание
Ошибки повреждения снимка	• `Aborting because of failure to load from latest snapshot with index` • `Failure to load from latest snapshot with index {}: {}. Manual intervention is necessary for recovery` • `Failed to preprocess stored log at index {}, aborting to avoid inconsistent state` • Сбои сериализации/загрузки снимка при запуске
Другие проблемы Keeper	• `Coordination::Exception` • `Zookeeper::Session Timeout` • Проблемы с синхронизацией или выбором лидера • Состояния гонки при компактации журнала

Восстановление после повреждения снимков Keeper

Прежде чем работать с какими-либо файлами, обязательно:

Остановите все узлы Keeper, чтобы предотвратить дальнейшее повреждение данных
Сделайте резервную копию всего содержимого, скопировав весь каталог coordination в безопасное место
Проверьте кворум кластера, чтобы убедиться, что хотя бы на одном узле сохранились корректные данные

1. Восстановление из существующей резервной копии

Используйте этот способ, если:

Повреждение метаданных Keeper или снимков делает текущие данные невосстановимыми.
Существует резервная копия с заведомо корректным состоянием Keeper.

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

Найдите и проверьте самую новую резервную копию на согласованность метаданных.
Остановите сервисы ClickHouse и Keeper.
Замените повреждённые снимки и журналы версиями из каталога резервной копии.
Перезапустите кластер Keeper и проверьте синхронизацию метаданных.

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

2. Откат к более старому снимку

Используйте этот процесс в следующих случаях:

Недавние снимки повреждены, но более старые всё ещё пригодны к использованию.
Инкрементальные журналы не повреждены, что позволяет выполнить согласованное восстановление.

Чтобы откатиться к более старому снимку, выполните следующие шаги:

Найдите и выберите корректный старый снимок (например, snapshot.19) в каталоге Keeper.
Удалите более новые снимки и журналы.
Перезапустите Keeper, чтобы он заново воспроизвёл журналы и восстановил состояние метаданных.

Риск рассинхронизации метаданныхСуществует риск рассинхронизации метаданных, если снимки и журналы отсутствуют или неполны.

3. Восстановление метаданных с помощью `SYSTEM RESTORE REPLICA`

Следуйте этому процессу, если:

метаданные Keeper утрачены или повреждены, но данные таблицы по-прежнему есть на диске
таблицы перешли в режим только для чтения из-за отсутствия метаданных ZooKeeper/Keeper
вам нужно заново создать метаданные в Keeper на основе локально доступных частей данных

Чтобы восстановить метаданные, выполните следующие действия:

Убедитесь, что данные таблицы локально присутствуют в пути к данным вашего clickhouse-server, заданном параметром <path> в конфигурации. (по умолчанию /var/lib/clickhouse/data/)
Для каждой затронутой таблицы выполните:

SYSTEM RESTART REPLICA [db.]table_name;
SYSTEM RESTORE REPLICA [db.]table_name;

Для восстановления на уровне базы данных (если используется движок базы данных Replicated):

SYSTEM RESTORE DATABASE REPLICA db_name;

Дождитесь завершения синхронизации:

SYSTEM SYNC REPLICA [db.]table_name;

Проверьте восстановление: убедитесь, что в system.replicas значение is_readonly = 0, и следите за system.detached_parts

Как это работаетSYSTEM RESTORE REPLICA отсоединяет все существующие части, заново создает метаданные в Keeper (как будто это новая пустая таблица), а затем снова присоединяет все части. Это позволяет избежать повторной загрузки данных по сети.

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

4. Удаление и повторное создание метаданных реплики в Keeper

Используйте этот порядок действий, если:

Ошибка возникает только на одной реплике кластера, и её метаданные в Keeper повреждены или несогласованы
Вы сталкиваетесь с ошибками вида “Part XXXXX intersects previous part YYYYY”
Вам нужно полностью сбросить метаданные реплики в Keeper, сохранив локальные данные

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

На затронутой реплике отсоедините таблицу:

DETACH TABLE [db.]table_name;

Удалите метаданные реплики из Keeper (выполните на любой реплике):

SYSTEM DROP REPLICA 'replica_name' FROM ZKPATH '/clickhouse/tables/{shard}/table_name';

Чтобы найти правильный путь ZooKeeper:

SELECT zookeeper_path, replica_name FROM system.replicas WHERE table = 'table_name';

Повторно выполните ATTACH таблицы (она будет в режиме только для чтения):

ATTACH TABLE [db.]table_name;

Восстановите метаданные реплики:

SYSTEM RESTORE REPLICA [db.]table_name;

Синхронизируйтесь с другими репликами:

SYSTEM SYNC REPLICA [db.]table_name;

Проверьте system.detached_parts на всех репликах после восстановления

Выполните на всех затронутых репликахЕсли повреждение затронуло несколько реплик, повторите эти шаги на каждой из них по очереди.

Для всей базы данныхЕсли используется база данных Replicated, вместо этого можно выполнить SYSTEM DROP REPLICA ... FROM DATABASE db_name.

Альтернатива: использование флага force_restore_data Для автоматического восстановления всех реплицируемых таблиц при запуске сервера:

Остановите сервер ClickHouse
Создайте флаг восстановления:

sudo -u clickhouse touch /var/lib/clickhouse/flags/force_restore_data

Запустите сервер ClickHouse
Сервер автоматически удалит флаг и восстановит все реплицированные таблицы
Следите за ходом восстановления в журналах

Этот подход полезен, когда нужно одновременно восстановить несколько таблиц.

5. Пересборка кластера Keeper

Используйте этот процесс в следующих случаях:

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

Чтобы пересобрать кластер Keeper, выполните следующие шаги:

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

Трудоёмкий процессЭтот процесс требует много времени и сопряжён с риском длительного простоя. Потребуется полное восстановление данных.

​Обзор снимков Keeper

​Что такое снимок?

​Где найти снимки?

​Основные симптомы и проявления поврежденных снимков Keeper

​Восстановление после повреждения снимков Keeper

​1. Восстановление из существующей резервной копии

​2. Откат к более старому снимку

​3. Восстановление метаданных с помощью SYSTEM RESTORE REPLICA

​4. Удаление и повторное создание метаданных реплики в Keeper

​5. Пересборка кластера Keeper

Обзор снимков Keeper

Что такое снимок?

Где найти снимки?

Основные симптомы и проявления поврежденных снимков Keeper

Восстановление после повреждения снимков Keeper

1. Восстановление из существующей резервной копии

2. Откат к более старому снимку

3. Восстановление метаданных с помощью `SYSTEM RESTORE REPLICA`

4. Удаление и повторное создание метаданных реплики в Keeper

5. Пересборка кластера Keeper