Upgrade the major engine version of an ApsaraDB for ClickHouse cluster-ApsaraDB for ClickHouse-阿里云帮助中心

ApsaraDB for ClickHouse regularly releases major engine version updates to enhance the features and performance of Community Compatible Edition clusters. However, major engine version upgrades may affect compatibility, performance, and data consistency of existing clusters. Therefore, we recommend that you perform a complete verification and planning before you formally upgrade. This topic describes three methods for upgrading the major engine version: one-click upgrade, migration upgrade, and clone upgrade. Compare these methods to find the best fit for your scenario.

Comparison item	One-click major engine version upgrade	Migration upgrade	Clone upgrade
Scenario	Simple but has compatibility risks and cannot be rolled back. Run a compatibility test before upgrading.	Best for data volumes that do not exceed 10 TB.	Best when data compatibility verification is required.
Target	Source cluster only.	Source and destination clusters.	Source and clone clusters.
Number of clusters	One cluster.	Two: source and destination.	Two: source and clone.
Upgrade rollback	Irreversible. If the upgrade fails, the cluster cannot revert to the previous version.	Can be canceled during migration. Irreversible after completion.	Irreversible, but the source cluster remains unchanged. You can handle the source cluster based on your business requirements.
Write suspension	Suspend writes until the upgrade completes.	Stop writes to the source cluster near the end of migration to ensure data consistency.	Suspend writes during snapshot creation.
Time-consuming factors	New architecture: depends on cluster startup time. Old architecture: depends on the amount of data to be migrated. To identify your cluster architecture, follow Confirm cluster architecture.	Increases with data volume and write frequency. The migration may fail if writes continue.	Relatively fast. Depends mainly on snapshot creation and cluster startup time.
Data migration method	Not required. The upgrade runs in place on the cluster.	Data is gradually migrated from the source cluster to the destination cluster.	Clone cluster created from a data disk snapshot.
Cold data migration	Supported.	Supported.	Not supported.
Switchover	Not required.	Manually switch workloads to the destination cluster. Handle the source cluster as needed.	Manually switch workloads to the clone cluster. Handle the source cluster as needed.