How to delete mistakenly added cluster components in TiUP

Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: tiup加错集群组件,如何删除。

| username: 答辩潮人

[TiDB Usage Environment] Production Environment
[TiDB Version] v6.5.5
[Reproduction Path] Operations performed that led to the issue
[Encountered Issue: Issue Phenomenon and Impact]
Port 4000 of Machine A is in cluster test01, and it has also been added to the port 4000 service of Machine A in cluster test02. Now, I want to delete the data of port 4000 of Machine A in cluster test02 to avoid operating on the wrong cluster data.
[Resource Configuration] Go to TiDB Dashboard - Cluster Info - Hosts and take a screenshot of this page
[Attachments: Screenshots/Logs/Monitoring]

| username: TiDB_C罗 | Original post link

Can the cluster test02 be added successfully?

| username: 答辩潮人 | Original post link

Yes, this is also due to inadequate pre-checks by tiup.

| username: 像风一样的男子 | Original post link

Directly scale in the unwanted node using the command: tiup cluster scale-in clustername --node xxxxx:4000

| username: ShawnYan | Original post link

Can machines from different clusters also access each other with mutual trust? Check the metadata of tiup for cluster test2.

| username: 答辩潮人 | Original post link

The 4000 port of this node is used in other clusters. If you scale-in, it will also be removed from the normal cluster.

| username: 答辩潮人 | Original post link

Can you specify the exact path you want?

| username: TiDB_C罗 | Original post link

It should be possible to add but not start, because when deploying a cluster, the instances are not started, so there will be no port conflict issues.

| username: 答辩潮人 | Original post link

There is no need to start it, as it is already in the running state in another cluster. The current issue is that in this cluster, the 4000 port can also be controlled. This is to prevent accidental operations that might affect other clusters.

| username: Kongdom | Original post link

You can delete it by scaling down.

| username: 答辩潮人 | Original post link

The previous comment explained that the 4000 service of this node is functioning normally in other clusters.

| username: 答辩潮人 | Original post link

Moreover, it has already been tested. Operating on port A:4000 of the test02 cluster will be the same operation in the test01 cluster.

| username: tidb狂热爱好者 | Original post link

Confused after reading, the description is confusing.

| username: 答辩潮人 | Original post link

There is a 10.0.0.1:4000 service in both tiup cluster display test01 and test02. Now I want to remove the 10.0.0.1:4000 node from the test02 cluster. If I use scale-in to shrink it, the 10.0.0.1:4000 in test01 will also be scaled in. This service is normally provided on test01.

| username: TiDB_C罗 | Original post link

In this situation

| username: 答辩潮人 | Original post link

Yes, but this node actually only provides services for Cluster 1. However, Cluster 2 can operate on this node. To prevent misoperation, it is necessary to delete this node from Cluster 2. Scaling down does not meet the requirement. It has been tried and will also scale down the node in Cluster 1.

| username: 答辩潮人 | Original post link

Currently, I want to delete the data of this node on tiup, as scale-in cannot meet the requirements.

| username: TiDB_C罗 | Original post link

How about trying to modify .tiup/storage/cluster/clusters/clustername/meta.yaml in test02?

| username: 答辩潮人 | Original post link

OK, thanks.

| username: 答辩潮人 | Original post link

Actually, this can be considered a bug. When adding a node to a new cluster, it detects that the port already exists, yet it still successfully adds the data.