Skip to main content
Вернуться в Блог

Битый снепшот ClickHouse Keeper: как закончившееся место убило хранилище

Разбор реального инцидента простым языком: что такое ClickHouse, шарды, реплики и Keeper — и почему очистка диска не всегда решает проблему.

У заказчика закончилось место на сервере. Продукт перестал запускаться. Почистили немного места — веб поднялся, но хранилище на базе ClickHouse запускаться отказалось.

В логах была вот такая ошибка:

Aborting because of failure to load from latest snapshot with index 216333318

Давайте разбираться. Начнём с основных технических понятий.

Что такое ClickHouse

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

Поэтому ClickHouse используют в системах мониторинга, логирования, аналитики и в SIEM-системах. Например, такие ребята Яндекс, Tesla и Microsoft используют эту БД.

Немного про архитектуру

Что такое шард

Шард — это кусок данных. Допустим, событий так много, что один сервер не справляется. Тогда данные можно распределить между несколькими серверами:

  • Шард 1 хранит одну часть событий
  • Шард 2 хранит вторую часть
  • Шард 3 хранит третью часть

Это и есть шардирование. Главная идея — не держать данные одним огромным массивом на одном сервере, а распределить их между несколькими узлами.

Что такое реплика

Реплика — это копия шарда. Если шард — это кусок данных, то реплика — это копия этого куска.

Например:

  • Шард 1, реплика 1
  • Шард 1, реплика 2

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

То есть:

  • Шардирование помогает распределять нагрузку и объём данных
  • Репликация создаёт отказоустойчивость

Что такое ClickHouse Keeper

А вот и виновник всей истории.

Keeper — это служба координации. Она хранит служебное состояние, которое нужно ClickHouse для согласования репликации и работы кластера в целом.

Если проще, Keeper позволяет разным узлам договориться:

  • Какие реплики существуют и какие в них данные
  • Какие операции уже были выполнены
  • Что нужно синхронизировать

То есть ClickHouse хранит данные на шардах, дублирует их на репликах, а Keeper помогает этим репликам координироваться.

Коротко по ролям:

  • ClickHouse хранит и обрабатывает данные
  • Шард отвечает за разделение данных
  • Реплика отвечает за копию данных
  • Keeper отвечает за координацию между репликами и служебное состояние

Если Keeper не работает — реплики не могут нормально согласовывать своё состояние.

Снепшоты Keeper

Keeper тоже должен где-то хранить своё состояние. Snapshot у Keeper — это снимок состояния на определённый момент времени. При старте Keeper берёт последний снепшот и «восстанавливается из контрольной точки».

Что произошло в нашем случае

  1. У заказчика закончилось место на диске.
  2. Продукт перестал запускаться.
  3. Почистили место — веб поднялся.
  4. Storage (на базе ClickHouse) запускаться не стал.
  5. Keeper при старте попытался прочитать снепшот, но тот оказался битым: во время записи снепшота закончилось место. Отсюда и ошибка в логах: Aborting because of failure to load from latest snapshot with index 216333318
  6. Сторадж не поднимается.
  7. Идём в папку со снепшотами и видим их: snapshot_216133318.bin snapshot_216233318.bin snapshot_216333318.bin
  8. Удаляем битый снепшот 216333318 (именно на него ругался Keeper в ошибке). Keeper берёт предыдущий снепшот и поднимается. Победа 🕺

Почему это помогло

В данном случае был простой кластер:

  • 1 нода
  • 1 шард
  • 1 реплика
  • 1 Keeper

То есть не было нескольких Keeper’ов, которым пришлось бы между собой согласовывать состояние кластера. Поэтому откат к предыдущему снепшоту прошёл безболезненно — терять было нечего, кроме последнего (битого) снимка.

Вывод

Когда на сервере заканчивается место, проблема не всегда решается простой очисткой диска. Пока диск был забит, что-то могло записаться некорректно и «накрыться» — как в нашем случае с битым снепшотом.

Поэтому в диагностике важно смотреть не только на сам симптом «места нет», но и на его последствия.