Connect to your ClickHouse® host. You can copy the value of the Native Interface field from the Overview tab on your cluster information page. It has the following structure:
clickhouse-client --host <FQDN of the host> \
--secure \
--user <Cluster user name> \
--password <Cluster user password> \
--port 9440
If you run a RedHat 7-based Linux distribution, including Cent OS 7, Oracle Linux 7 and others, you need to download and install trusted certificates, and manually add the path to them in the clickhouse-client configuration file as follows:
Locate your clickhouse-client configuration file (by default, you can find it at /etc/clickhouse-client/config.xml) and add the path to the certificates into the <openSSL> section:
<client><!-- Used for connection to server's secure tcp port --><loadDefaultCAFile>true</loadDefaultCAFile><cacheSessions>true</cacheSessions><disableProtocols>sslv2,sslv3</disableProtocols><preferServerCiphers>true</preferServerCiphers><caConfig>/etc/ssl/certs/ca-bundle.crt</caConfig><!-- Use for self-signed: <verificationMode>none</verificationMode> --><invalidCertificateHandler><!-- Use for self-signed: <name>AcceptCertificateHandler</name> --><name>RejectCertificateHandler</name></invalidCertificateHandler></client>
Connect to your ClickHouse® host. You can copy the value of the Native Interface field from the Overview tab on your cluster information page. It has the following structure:
clickhouse-client --host <FQDN of the host> \
--secure \
--user <Cluster user name> \
--password <Cluster user password> \
--port 9440
Prepare your self-managed cluster
If your self-managed ClickHouse® cluster has tables created with the CollapsingMergeTree engine, you need to disable automatic merges. This will protect you from possible data corruption on the target:
Disable automatic merges by executing the following query:
SYSTEM STOP MERGES ON CLUSTER 'default'<database-name>.<table-name>
The FINAL statement merges all the table parts into one, and the DEDUPLICATE statement removes repeating rows during the merge to avoid possible data corruption.
Arrive at the cluster configuration in DoubleCloud
When migrating a self-managed ClickHouse® cluster to DoubleCloud which is already sharded, we strongly recommend using a single-shard configuration whenever possible.
With hybrid storage enabled, sharding isn't necessary when the only reason is the amount of data. Hybrid storage can handle tens of terabytes per node with EAS.
Therefore, sharding on DoubleCloud is only needed if a single node can't cover your writes anymore.
In case of read performance instead, increase the number of replicas and upgrade your cluster to a better hardware configuration.
If the primary reason for sharding is to improve the write performance, it's important that you choose a sharding key that fits your use case. To select the best key option for your use case, see the official ClickHouse® documentation .
To handle large amounts of data, consider splitting it into manageable chunks when setting up a multi-shard cluster. Consult the official ClickHouse® documentation on data partitioning
Prepare the DoubleCloud cluster
Recreate the DDL structure of the cluster you want to migrate on the DoubleCloud side:
Connect to your cluster and recreate create a database:
Select the name of your cluster to open its information page. By default, you will see the Overview tab.
Under Connection strings, find the Native interface string and click Copy.
Open your terminal and run a command to connect to your cluster:
<Native interface connection string>
After you have connected to the cluster, run the CREATE query for each database you want to recreate on the target cluster:
CREATE DATABASE IF NOTEXISTS<database_name>ON CLUSTER default
Manually recreate at the target database each table you want to migrate. To get the CREATE query for all the tables within a database, run the following on your source ClickHouse® cluster:
SELECT create_table_query FROM system.tables WHERE database NOTIN ('system', 'information_schema’) AND (engine NOT IN ('MaterializedView', 'View', 'Dictionary'))
You need to add the ON CLUSTER default to every CREATE statement at the DoubleCloud target cluster.
Go to your cluster's information page and open the Hosts tab.
Find the host to which you want to migrate your data and click .
Post-migration
After migrating the data, you need to recreate all materialized views manually (you need to add the ON CLUSTER default at the source):
SELECT create_table_query
FROM system.tables
WHERE (lower(database)
NOTIN ('system', 'information_schema'))
AND (engine IN ('MaterializedView', 'View', 'Dictionary'))