To query cluster shard information, perform the following steps:
cd Client installation directory
source bigdata_env
In security mode, run the following commands:
kinit ClickHouse service user
clickhouse client --host IP address of the ClickHouse instance --port 9440 --secure
In normal mode, run the following command:
clickhouse client --host IP address of the ClickHouse instance --user Username --password --port 9000
Enter the password.
select cluster,shard_num,replica_num,host_name from system.clusters;
Ensure that the disk space of nodes that will not be decommissioned is sufficient for storing data of all decommissioned nodes. There must be approximately 10% redundant storage space after decommissioning to ensure that the remaining instances can run properly. The procedure is as follows:
free_space indicates the free disk space, and total_space indicates the total disk space. The used space is calculated by subtracting the value of free_space from that of total_space, and its unit is byte.
If there is any faulty ClickHouseServer instance node in the cluster, all instance nodes in the cluster cannot be decommissioned. Log in to Manager, choose Cluster > Services > ClickHouse, click Instance, and view the running status of each node in the cluster.
If a database is deployed only on an instance node you want to decommission, the instance node cannot be decommissioned. To remove the instance node, you need to create the database on all ClickHouseServer instance nodes in the cluster. The procedure is as follows:
name indicates the database name. engine indicates the database engine, and the default value is Atomic. If the default engine is used, you do not need to specify the engine when creating a table.
If a local non-replicated table is deployed only on an instance node you want to decommission, the instance node cannot be decommissioned. To decommission the node, create a local non-replicated table with the same name on any node that will not be decommissioned.
For example, the current cluster has two shards, shard 1 has two nodes A and B, and shard 2 has two nodes C and D. The non-replicated table test was created without the ON CLUSTER keyword, so the table is created only on node A.
In this case, to decommission nodes A and B in shard 1, you need to create the table test on node C or D in shard 2.
Run the following command to list the data tables of each node:
select database,name,engine,create_table_query from system.tables where database != 'system';
Perform the following operations according to the result:
CREATE TABLE {database}.{table} ('column name' type...) ENGINE = MergeTree;
If a replicated table exists only on some nodes in the cluster, the nodes where the replicated table is deployed cannot be decommissioned. You need to manually create the replicated table on all instance nodes where no replicated table is deployed in the cluster before decommissioning.
For example, the current cluster has two shards, shard 1 has two nodes A and B, and shard 2 has two nodes C and D. The replicated table test was created without the ON CLUSTER keyword, so the table is created only on nodes A and B.
To decommission nodes A and B in shard 1, you need to create the table test on nodes C and D in shard 2.
Run the following command to list the data tables of each node:
select database,name,engine,create_table_query from system.tables where database != 'system';
Perform the following operations according to the result:
Distributed tables will not be migrated automatically for decommissioning. Create distributed tables on the nodes that will not be decommissioned.
Run the following command to list data tables of each node and check the engine column. These tables are distributed tables if this column contains field Distributed.
select database,name,engine from system.tables where database != 'system';
Creating distributed tables on these nodes will not affect the decommissioning, but may affect subsequent service operations.
Views will not be automatically migrated for decommissioning, and views do not store data. Run the following command to list data tables of each node and check the engine column. These tables are views if this column contains field View.
select database,name,engine from system.tables where database != 'system';
Run the following command to delete the views one by one:
drop view {database_name}.{table_name};
Materialized views will not be automatically migrated for Decommissioning. Create materialized views on the nodes that will not be decommissioned. If the materialized view of a node to be decommissioned does not display the specified aggregation table but uses an embedded table, the node cannot be decommissioned.
Run the following command to list data tables of each node and check the engine column. These tables are materialized views if this column contains field MaterializedView.
select database,name,engine, create_table_query from system.tables where database != 'system';
The table whose create_table_query column contains the POPULATE field is an embedded table. Views are initialized when they are created, and newly inserted data is ignored during the initialization. A table that does not contain the POPULATE field is an aggregation table. Newly inserted data is directly inserted into the view charts and support tables, and the original data is manually loaded into the views and support tables. The table creation operations of the aggregation table and embedded table are different.
Perform the following operations to process the materialized views of the node to be decommissioned:
Currently, tables of third-party engines cannot be automatically migrated for decommissioning.
Run the following command to list data tables of each node and check the engine column. These tables are tables of third-party engines if this column does not contain any of the following fields: MergeTree, View, MaterializedView, Distributed, and Log. (The engine column of a third-party engine table may contain field Memory, HDFS, or MySQL.)
select database,name,engine from system.tables where database != 'system';
Create third-party engine tables on the nodes that will not be decommissioned and delete those from the nodes that will be decommissioned.
If the table on a node to be decommissioned has been detached and data still exists in the detached directory, the node cannot be decommissioned. You need to attach the data in the detached directory to other directories before decommissioning.
select * from system.detached_parts;
ALTER TABLE {table_name} DROP DETACHED PARTITION {partition_expr} SETTINGS allow_drop_detached = 1;
select * from system.detached_parts;
If the command output is empty, there is no detached part data in this system catalog.