GC: Support TiDB server with different keyspace to advance GC safe point separately

[ystaticy]

Enhancement

Support TiDB with different keyspace to advance gc separately.

Background

TiDB already supports deploying multiple clusters with different keyspaces on a single PD TiKV cluster.

Previously, we have implemented multiple TiDB clusters with a single TiDB GC Worker that does not configure Keyspace to advance the global GC safe point. Each keyspace TiDB only depends on the global GC safepoint. Do your own deleteRange cleanup.

The PR #51300 Implement that the keyspace TiDB cluster can advance the GC safe point of the current Keyspace in the Keyspace dimension by itself after enabling keyspace level GC. In this way, the GC safe points between keyspaces are separated, so that if one Keyspace GC safe point is advancing slowly, it can not affect the GC safe points of other keyspaces.

Implementation

1. If the keyspace-name is not configured in TiDB, nothing will be changed.
2. If the keyspace meta doesn't configure keyspace level GC, it will still use the global GC, nothing will be changed.
3. The following storage and GC and safe point ETCD keys are distinguished by keyspace:

• Minstartts
• Saved safe point
• GC safe point
• Service safe point

5. One limitation: If either TiDB with keyspace sets keyspace level GC, then this keyspace cannot be returned global GC.

Related Tasks

TiDB Server support keyspace level GC

• [] [DNM]GC: Support keyspace level GC #51300

TiDB BR,Lightning,Dumpling,CDC implementation

• GC: Support TiDB BR,Lightning,Dumpling use keyspace level GC when keyspace already enable it #51622

PD interface implementation

• Introduce keyspace safepoint interface tikv/pd#6419