Rolling zero-downtime ClickHouse upgrades
Upgrading a replicated ClickHouse cluster one replica at a time: preparation, the order of shards and replicas, expected checksum warnings during mixed versions, and post-upgrade checks.
ClickHouse upgrades
Planning and running self-managed ClickHouse upgrades: rolling upgrades across replicas, LTS jumps, version compatibility windows, rollback, and breaking changes such as the mandatory analyzer.
Upgrading ClickHouse from one LTS release to the next
Moving between twice-yearly LTS lines such as 26.3 and 26.8: reading changelogs for breaking changes, testing on representative data, and staying inside the supported version list.
Upgrading ClickHouse versions more than a year old
Bringing an outdated ClickHouse cluster current: choosing intermediate versions or a downtime upgrade, handling accumulated breaking changes, and risks of mixed versions beyond the compatibility window.
Rolling back a ClickHouse upgrade
When a ClickHouse downgrade is possible, why using new features blocks it, backups to take before upgrading, and a rollback plan for production clusters.
Preparing for the mandatory analyzer in ClickHouse 26.9
What changes now that the old query analysis is gone: known incompatibilities in HAVING, JOIN and aliases, testing queries on 26.x, and migration aids such as analyzer_compatibility_allow_non_aggregate_in_having.
Using the compatibility setting during ClickHouse upgrades
Pinning default settings to an earlier version while applications are tested on a new ClickHouse release, its limits, and when to remove it.
Upgrading ClickHouse Keeper
When and how to upgrade Keeper separately from ClickHouse servers: keeping quorum during a rolling restart, snapshot and log compatibility, and verifying the ensemble afterward.
