ClickHouse 26.3.25 LTS: як безпечно оновити production-кластер

ClickHouse опублікував 26.3.25.2 у гілці LTS — це maintenance-реліз для команд, які свідомо залишаються на довгостроково підтримуваній 26.3, а не переходять на новішу feature-гілку. У короткій офіційній нотатці немає переліку нових функцій, тому головна новина тут операційна: з’явився новий підписаний build із 52 assets, а оновлювати кластер потрібно як LTS patch — із canary, перевіркою реплікації та готовим rollback.

Що означає позначка LTS

LTS-гілка потрібна не для накопичення нових можливостей, а для передбачуваного життєвого циклу. Команда ClickHouse у власній production-рекомендації розділяє stable та LTS releases; LTS виходять рідше й підтримуються довше. Версія 26.3.25.2 продовжує саме цю лінію, тож її адресат — production-кластери, де важливіше мінімізувати зміну поведінки, ніж якнайшвидше отримувати feature releases.

Номер 26.3.25.2 не варто читати як “великий двадцять п’ятий реліз”. Це точка конкретної збірки в maintenance-гілці. Офіційна GitHub-сторінка показує підписаний commit і набір пакетів для різних платформ, але не заявляє нових SQL-функцій. Тому вигадувати feature list або переносити опис усієї 26.3 до цього patch було б неправильно.

Чому короткий changelog не означає автоматичне оновлення

Навіть maintenance build аналітичної БД змінює серверний binary, а отже торкається парсера запитів, background merges, replicated tables, codecs, системних таблиць і взаємодії з keeper. Ризик нижчий, ніж при переході на нову feature-гілку, але він не нульовий. Особливо обережними мають бути кластери з user-defined functions, експериментальними settings, materialized views і великим backlog мутацій.

Не слід робити висновок про виправлені CVE лише з появи нового build. Для security-рішень команда повинна окремо читати security changelog і policy підтримуваних версій. Якщо офіційна release note не називає конкретну вразливість, у внутрішньому change request не можна приписувати її цьому релізу.

Безпечний rolling upgrade

Перший крок — перевірити точну поточну версію на кожній репліці, а не лише Docker tag у manifest. Mutable tag може вже вказувати на іншу збірку. Для відтворюваності варто зафіксувати package version або image digest і зберегти попередній artifact до завершення спостереження.

Canary обирають так, щоб він отримував реальний профіль запитів, але його відмова не зупиняла shard. Після оновлення перевіряють стартові логи, system.errors, черги реплікації, затримку merges, disk space, parts count і p95/p99 запитів. Лише після повного replication catch-up переходять до наступної replica.

У distributed cluster не можна хаотично змішувати версії довше, ніж потрібно для rolling procedure. Якщо клієнти використовують нові або рідкісні settings, потрібні окремі probes на кожну версію. Схемні зміни, mutation і TTL materialization краще не запускати одночасно з upgrade: інакше причина навантаження або збою буде неочевидною.

Що перевірити після оновлення

• Репліки синхронізовані, черги не ростуть, немає нових readonly replicas.
• Фонові merges і mutations просуваються з нормальною швидкістю.
• Типові SELECT/INSERT, materialized views і distributed queries дають той самий результат.
• CPU, memory, open files, disk latency та network traffic не мають нових стрибків.
• Backup/restore і підключення драйверів перевірені на тестовому наборі.

Практичний висновок: 26.3.25.2 LTS — кандидат на планове patch-оновлення для кластерів 26.3, але не причина міняти release train. Команди на stable або новішій LTS мають порівнювати власну політику підтримки, а не “понижуватися” через свіжішу дату GitHub-релізу.

Обмеження інформації

Сторінка релізу навмисно лаконічна й не містить детального списку змін. Тому цей матеріал пояснює значення LTS build і безпечний процес розгортання, а не приписує версії непідтверджені оптимізації. Перед production адміністратору слід переглянути порівняння commit, офіційний changelog своєї гілки та security notices, що стосуються конкретної конфігурації.

Джерело та права

Матеріал є самостійним українським перекладом-переказом офіційної release note ClickHouse 26.3.25.2 LTS, опублікованої 28 серпня 2026 року robot-clickhouse, та офіційної production-рекомендації щодо типів релізів. Матеріали репозиторіїв ClickHouse поширюються за Apache License 2.0. Перекладено, адаптовано й доповнено редакцією «Бібліотеки програміста». Обкладинка створена редакцією за допомогою AI і не входить до першоджерела.