# PD's Role in TiDB Cluster

![`smart`](PDArchitecture_aa_004_20220509.png)

------------------------------------------------------------------------------
PD is the central control of the TiDB cluster and is known as the "brain" of the entire cluster. 

In the TiDB cluster, it is responsible for storing metadata (mainly providing routes for the TiDB server, etc.); assigning global ID, transaction ID, and global timestamp; generating TSO; discovering services; collecting information such as the topology of the cluster, real-time data distribution, and hot spot metrics. And, it is also responsible for scheduling data in the TiKV nodes.

The PD itself consists of at least 3 nodes, and the PD supports auto failover by integrating etcd, so there is no need to worry about a single point of failure. At the same time, the PD also ensures strong data consistency through etcd's Raft, so there is no need to worry about data loss. In a production environment, it is recommended to deploy an odd number of PD nodes.

Finally, in the PD cluster, a node with the role of Leader provides stateless services to the outside world. Even if the PD node goes down, with the help of the PD election mechanism, the newly selected PD Leader can serve the outside world immediately without considering any intermediate state.

We need to define the following terms first for further study:

Store: The Store in PD refers to the storage nodes in the cluster, which is the TiKV instance. Note that Store and TiKV instances are strictly one-by-one; even if multiple TiKV instances are deployed on the same host or even on the same block of disk, these instances will correspond to different Store instances.

Region, Peer, and Raft Group: Each Region is responsible for maintaining a continuous segment of the cluster's data (an average of about 96 MB in the default configuration), and each replica stores multiple copies of a different Store (the default configuration is 3 copies), and each replica is called Peer. Multiple Peer's of the same Region synchronize data through the Raft protocol, so Peer is also used to refer to members in an Raft instance. TiKV uses the Multi-Raft model to manage data, that is, each Region corresponds to an independently running Raft instance. We also call such a Raft instance a Raft Group.

Leader, Follower, and Learner: They correspond to each of the three Peer roles. Among them, Leader is responsible for responding to client reads and writes requests; Follower passively synchronizes data from Leader and elects a new Leader when the Leader fails.

And, Learner is a special role that only participates in synchronizing Raft Log and does not participate in voting.

Region Split: The Region in a TiKV cluster is not divided from the beginning, more Regions will be generated gradually as data is written. The splitting process is called Region Split. The mechanism is that an initial Region covers the entire key space is built when the cluster is initialized, and then a new Region is generated through Split every time the Region data reaches a certain amount during operation.

`Pending` and `Down` are two special possible statuses of Peer.
- `Pending` indicates a large gap in Raft Log between Follower or Learner and Leader. And, Follower in `Pending` status cannot be elected as Leader.
- `Down` refers to Leader not receiving corresponding Peer messages for a long time, usually indicating that the corresponding node has crashed or been isolated from the network.

Additionally, TiDB Dashboard service is provided on PD node by default.