Normally the upgrade procedure looks like that:
- pick the release to upgrade
- check the release notes/changelog between the release you use currently and the target release
- sometimes you may need to change some configuration settings to change the defaults (for better compatibility, etc)
- upgrade itself is simple:
- upgrade package (it doesn’t trigger the restart of clickhouse-server automatically)
- restart clickhouse-server
- check healthchecks / logs
- repeat on other nodes
- Mixing several versions working together in the same cluster may often lead to different degradations. Usually, it’s not recommended to have a big delay between upgrading different nodes on the same cluster. Usually, you do upgrade on the odd replicas first, and after they were back online - restart the even replicas.
- upgrade the dev / staging first
- ensure your schema/queries work properly on the staging env
- do the production upgrade.
Report on ClickHouse functions, table functions, table engines, system and MergeTree settings, with availability information.
Last modified 2022.03.17: Update _index.md (d8e1fc6)