ClickHouse 22.3 LTS: первый LTS-релиз новой схемы и обновление аналитического кластера

ClickHouse в марте выпустил 22.3 - и впервые в своей истории пометил его как LTS. Для тех, кто гоняет ClickHouse в продакшне, это не просто маркетинговая нашивка: отныне понятно, какие версии будут получать backport-патчи, а какие - нет. Мы как раз планировали обновление аналитического кластера одного из клиентов и воспользовались моментом, чтобы разобраться, что именно изменилось и стоит ли сразу вставать на LTS.

Что такое новая схема версионирования

До 22.x ClickHouse версионировался по году и месяцу (21.3, 21.8, 21.11 и т.д.), но никакого формального деления на «стабильные» и «экспериментальные» не было. Выбор версии для продакшна был вопросом опыта и чуйки: смотришь на changelog, читаешь issues, спрашиваешь в Telegram-сообществе.

Теперь ClickHouse Inc. (образована в 2021 году) формализовала схему: каждый год выходит один LTS-релиз, который получает backport-патчи в течение года. Остальные релизы - обычные, патчи в них попадают только в ближайшее время после выхода. 22.3 - первый LTS в этой схеме.

Практическая разница:

• LTS-релиз - гарантированные backport'ы критических багов и CVE в течение ~12 месяцев. Обновление внутри LTS-ветки (22.3.x -> 22.3.y) - только патчи, без breaking changes.
• Обычный релиз - новые фичи каждые несколько недель, патчи в него попадают, пока он «актуальный», т.е. не вышел следующий. Темп разработки ClickHouse высокий, поэтому обычный релиз быстро устаревает.

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

Что нового в 22.3 по существу

Версионирование - это хорошо, но нас интересует и что именно появилось в самом релизе. Из значимого:

Parallel replicas для MergeTree. Экспериментальная фича: запрос может обрабатываться параллельно несколькими репликами одновременно, распределяя нагрузку сканирования между ними. Флаг allow_experimental_parallel_reading_from_replicas. Мы пока не включили в продакшн - «experimental» в названии говорит само за себя - но для аналитических запросов по большим таблицам фактов это выглядит интересно.

Улучшения в projection'ах. Проекции в ClickHouse - это предвычисленные агрегаты, которые хранятся вместе с основными данными и автоматически используются оптимизатором. В 22.3 они стали работать стабильнее при мердже и репликации. После нескольких неприятных историй с проекциями в 21.x это важно.

ClickHouse Keeper. Встроенный аналог ZooKeeper, который позволяет не поднимать отдельный ZooKeeper-кластер для репликации. В 22.3 Keeper объявлен production-ready. Это серьёзное заявление - ZooKeeper всегда был отдельной болью в ClickHouse-стеке.

Обновление кластера клиента

Кластер, который мы обновляли, - четыре узла в двух шардах по две реплики. В качестве координатора - ZooKeeper, отдельный трёхузловой кворум. Версия до обновления - 21.8 LTS (де-факто LTS по старой традиции, хотя формально так не называлась).

Переход с 21.8 на 22.3 прошёл без сюрпризов. Стандартная процедура: один узел выводим из репликации, обновляем, ждём догонки, переходим к следующему. Rolling upgrade работает, breaking changes между этими версиями нам не попались - проверили changelog заранее.

Одна деталь: в 22.3 изменилось поведение некоторых настроек на уровне users.xml. Несколько параметров, которые мы задавали вручную, теперь имеют другие дефолты или немного другую семантику. Ничего критичного, но пришлось пройтись по конфигу и проверить, что всё как надо.

ClickHouse Keeper: смотрим, но пока не трогаем

Отдельно разобрались с Keeper. Идея понятная: Keeper реализует протокол Raft (в отличие от ZooKeeper, который использует ZAB), но написан на C++ и живёт внутри ClickHouse-процесса. Конфигурируется через config.xml, управляется теми же инструментами, что и сам ClickHouse.

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

Тем не менее в текущем кластере мы пока оставили ZooKeeper. Причины простые: кластер работает, ZooKeeper стабилен, мотивации менять работающее нет. Миграцию с ZooKeeper на Keeper обязательно попробуем на следующем развёртывании - там проще начать с чистого листа, чем переносить живой кластер.

Что стоит знать про Keeper: он требует нечётного числа узлов для кворума (как и ZooKeeper), конфигурируется секцией <keeper_server> в основном конфиге, и данные хранит в отдельном каталоге. При аварии ноды поведение аналогично ZooKeeper - репликация приостанавливается до восстановления кворума.

Где сейчас

Кластер на 22.3 LTS работает третью неделю. Метрики запросов в норме, репликация без отставания. Проекции используем на двух таблицах фактов - пока ведут себя адекватно, ни одного инцидента с потерей данных при мердже, который преследовал нас на 21.6.

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