Add `cluster_id` to the `mysql.tidb`

[YangKeao]

Feature Request

Describe the feature you'd like:

Sometimes the external software will need to know the CLUSTER_ID to know whether the two TiDB instances are from the same cluster. For example: the CDC can use it to decide whether the upstream and downstream are from the same cluster and give an error to the user.

The CLUSTER_ID is already generated and stored in PD, but it's not exposed from TiDB side.

Describe alternatives you've considered:

I've considered two workaround before having this feature implemented:

Workaround 1: Use CLUSTER_INFO.SERVER_ID

Currently, we have a workaround to use CLUSTER_INFO.SERVER_ID to decide whether two servers are from the same cluster. For example, with a given server_id from the SERVER1, you can query SELECT count(1) FROM information_schema.cluster_info WHERE server_id = ? in the SERVER2 to know whether the two servers are from the same cluster.

However, a cluster may have a lot of servers and the possibility of conflict server id is not small enough. For example, if I have two cluster and each one of them has 100 server, the possibility of having conflict server id is:

$$ \frac{(1<<22 - 1 - 100) \choose 100}{(1<<22 - 1) \choose 100} = 99.7618...% $$

When I have 200 servers, the possibility is:

$$ \frac{(1<<22 - 1 - 200) \choose 200}{(1<<22 - 1) \choose 200} = 99.0508...% $$

Workaround 2: Sort and Hash CLUSTER_INFO.SERVER_ID

As using one SERVER_ID may face conflict, we can use the information provided by all servers, and hash them together. Run SELECT SERVER_ID FROM information_schema.cluster_info order by SERVER_ID and hash them. Now it should generate an unique id for each cluster. However, this ID will change during the scaling of the cluster, so it may have some bugs when we are generating the hash during scaling.

The both two workarounds are not that elegant.

Teachability, Documentation, Adoption, Migration Strategy:

1. Add a new row to the mysql.tidb: CLUSTER_ID xxxxx

[YangKeao]

The only concern is that the CLUSTER_ID for all servers should be the same. It'll be a little strange 🤦 .

[Defined2014]

How about add it into mysql.tidb table?

[YangKeao]

How about add it into mysql.tidb table?

Good @Defined2014 . I think it's better. The only problem is that it's a real table, so we'll need to update the information during bootstrap/upgrade right? (Assume that the cluster_id of a cluster will never change).

Should we also sync the cluster_id regularly (or for each restart) after bootstrap?

cc @bb7133 and @wlwilliamx

[Defined2014]

Good @Defined2014 . I think it's better. The only problem is that it's a real table, so we'll need to update the information during bootstrap/upgrade right? (Assume that the cluster_id of a cluster will never change).

Should we also sync the cluster_id regularly (or for each restart) after bootstrap?

I think you can update it anytime. Because it also contains tikv_gc_last_run_time which will be updated when gc is triggered. But I am not sure whether the cluster_id value will change. Intuitively, it should not change.

[wlwilliamx]

I think adding the cluster_id column to the CLUSTER_INFO table would be better. First, intuitively, if users need to know the cluster_id information, they would naturally look for it in the CLUSTER_INFO table. Additionally, since the CLUSTER_INFO table already records information about all nodes, users can easily find the cluster_id of a specific node—for example, if they want to check the cluster_id of a TiKV node. If the cluster_id column is placed in the mysql.tidb table, it would still not be convenient for all TiDB nodes to access this information. Adding it to CLUSTER_INFO ensures that the cluster_id of any node can be easily identified.

PS, recording cluster_id information for all instances is not a bad idea, as it allows all components of TiDB (e.g., TiKV, PD, TiDB itself) to conveniently query the cluster_id of any instance. This centralized approach improves consistency and accessibility across the system.

[YangKeao]

We've decided to insert new row cluster_id xxx to the mysql.tidb table, instead of exposing it through information_schema.cluster_info. I'll create a new PR for it.