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 involve changes to the underlying architecture and may affect compatibility, performance, and data consistency of existing clusters. Therefore, before you formally upgrade the major engine version of a cluster, we recommend that you perform a complete verification and planning. This topic describes three methods for upgrading the major engine version, including one-click upgrade, migration upgrade, and clone upgrade. This topic also compares the characteristics, scenarios, and usage notes of the methods to help you choose the most suitable solution.
Comparison item | |||
Scenario | The upgrade process is simple but has compatibility risks and cannot be rolled back. We recommend that you perform a compatibility test first. After you confirm that no compatibility issue exists, you can perform the upgrade. | This method is suitable for scenarios with small data volumes. We recommend that the data volume does not exceed 10 TB. | This method is suitable for scenarios that require data compatibility verification. |
Operation object | Operations are directly performed on the source cluster. | Operations are performed on the source and destination clusters at the same time. | Operations are performed on the source and clone clusters at the same time. |
Number of clusters | One cluster. | Two clusters, including the source and destination clusters. | Two clusters, including the source and clone clusters. |
Upgrade rollback | The upgrade process cannot be rolled back. If the upgrade fails, the cluster cannot be rolled back to the previous version. | The migration task can be canceled, but cannot be rolled back after the migration is complete. | The clone task cannot be rolled back, but the source cluster remains unchanged. You can handle the source cluster based on your business requirements. |
Write suspension | Write operations must be suspended until the upgrade is complete. | When the migration is nearing completion, you must stop writing data to the source cluster to ensure data consistency between the source and destination clusters. | When the source cluster is creating snapshots, write operations must be suspended. |
Time-consuming factors |
For more information about the cluster architecture type, see Confirm cluster architecture. | The time required for migration increases with the amount of data to be migrated and the frequency of write operations. If you do not stop writing to the source cluster, the migration task may fail. | The process takes less time, mainly depending on the snapshot creation time and cluster startup time. |
Data migration method | Data migration is not required. The major engine version upgrade is directly performed on the cluster. | Data is gradually migrated from the source cluster to the destination cluster. | A clone cluster is generated based on a data disk snapshot. |
Cold data migration | Supported. | Supported. | Not supported. |
Switchover | Switchover is not required. Only one cluster is used. | You need to manually switch your workloads to the destination cluster and handle the source cluster based on your business requirements. | You need to manually switch your workloads to the clone cluster and handle the source cluster based on your business requirements. |