ApsaraDB ClickHouse allows you to migrate data between instances. You can start a data migration task on a destination instance. You can migrate data between instances of the same kernel version. You can also migrate data from an instance of a kernel version to an instance of a later kernel version. This topic describes how to migrate data between instances in the ApsaraDB for ClickHouse console.

Precautions

  • Data can be migrated only to a destination instance whose kernel version is 20.8 or later. No limits are imposed on the kernel version of a source instance.
  • The replicas of the source instance and the destination instance must be consistent.
  • The source and destination instances must be deployed in the same virtual private cloud (VPC) or deployed in the same Cloud Enterprise Network instance.
  • If you enable tiered hot and cold data storage for the source instance, you must enable tiered hot and cold data storage for the destination instance. If you disable tiered hot and cold data storage for the source instance, you must disable tiered hot and cold data storage for the destination instance.
  • Before you migrate data, make sure that no management operations, such as scale-outs, upgrades, or downgrades, are being performed on the source and destination instances.
  • The available storage of the destination instances must be greater than or equal to 1.2 times the storage space of the source instances.
  • Each local table in the source instance must correspond to a unique distributed table.
  • ApsaraDB for ClickHouse supports only full migration.
  • For non-MergeTree tables such as external tables and log tables, only the schemas are migrated. The data is not migrated.

Prerequisites

  • The IP address of your source instance is added to a whitelist of your destination instance.
  • The IP address of the destination instance is added to a whitelist of the source instance.
Note You can execute the select * from system.clusters; statement to query the IP address of an ApsaraDB ClickHouse instance. For more information about how to configure a whitelist for an ApsaraDB for ClickHouse instance, see Configure a whitelist.

Impacts

The following table describes whether read and write operations can be performed on the source and destination instances during data migration and after data migration.
Instance type During migration After migration
Source instance Only read operations are supported. Read and write operations are supported.
Destination instance Read and write operations are not supported. Read and write operations are supported.

Procedure

  1. Log on to the ApsaraDB for ClickHouse console.
  2. On the Clusters page, click Default Instances, find the destination instance, and click the ID of the instance.
  3. In the left-side navigation pane of the page that appears, click Migrate Instance.
  4. In the upper-left corner of the Migrate Instance page, click Create Migration Task. Migrate data between instances
    Note If no data is migrated to the destination instance, the message "No data available." is displayed.
  5. In the Select the source and destination instances step, configure the Instance ID, Database Account, and Database Password parameters in the Source Instance Information section. Then, configure the Database Account and Database Password parameters in the Destination Instance Information section. Select the source and destination instances
    Notice You can migrate data only between instances that are deployed in the same region.
  6. Click Test Connectivity and Proceed to check whether the two instances are connected.
    • If the connection is established, proceed to the next step.
    • If the connection fails to be established, use one of the following methods to resolve the issue:
      • If a message that indicates a password authentication failure for the account of the source instance or the destination instance appears, reconfigure the Database Account or Database Password parameters.
      • If a message that indicates a connectivity error between the source instance and the destination instance appears, check whether the instances are deployed in the same VPC or deployed in the same Cloud Enterprise Network instance.
  7. After the source and destination instances are connected, proceed to the Migration Content step. Click Next: Pre-detect and Start Synchronization. Migration Content step
    Note You can migrate the following objects from the source instance: the cluster, databases, tables, data dictionaries, materialized views, user permissions, and cluster configurations.
  8. After the migration task is configured, the system prechecks the migration configuration and starts the migration task in the backend.
    • If no issues are detected during the precheck, click Completed. No issues detected
    • If an issue is detected, follow the on-screen instructions to resolve the issue, and then migrate the data again. The following table describes the precheck items.
      Precheck item Description
      Instance Status Detection Before you migrate data, make sure that no management operations, such as scale-outs, upgrades, or downgrades, are being performed on the source and destination instances. If management operations are being performed on the source and destination instances, the system cannot start a migration task.
      Replica Consistency Detection The replicas of the source instance and the destination instance must be consistent. Otherwise, the replicas cannot be configured because the required parameters are missing.
      Storage Space Detection Before the system starts a migration task, the system checks the storage capacity of the source and destination instances. The available storage of the destination instance must be greater than or equal to 1.2 times the storage space of the source instance.
      Local Table and Distributed Table Detection If no distributed table is created for a local table or multiple distributed tables are created for the same local table, the precheck fails. Delete redundant distributed tables to ensure that the distributed table of each local table is unique.
  9. After the migration task is complete, you can view the migration task on the Migrate Instance page. Manage migration tasks

References

For information about how to migrate data from a self-managed ClickHouse instance to an ApsaraDB ClickHouse instance, see Migrate table data from a self-managed ClickHouse cluster to an ApsaraDB for ClickHouse cluster.