# Pd Architecture
__*PD architecture*__

![left](./student-guide/diagram/PDArchitecture_aa_002_20220509.png)

------------------------------------------------------------
PD is the central controller of the TiDB database and is called the "brain" of the entire cluster. In the TiDB database cluster, it is responsible for storing metadata (mainly providing routes for TiDB Server, etc.), assigning global ID, transaction ID, global timestamp TSO generation, service discovery, collection of information such as the overall topology of the cluster, real-time data distribution and hot spot status, and scheduling of data in TiKV nodes. At the same time, TiDB Dashboard services are provided.

Next, let's take a look at the architecture and composition of PD. PD itself consists of at least 3 nodes. PD supports auto failover by integrating etcd, so there is no need to worry about a single point of failure. At the same time, PD also uses ETCD's raft to ensure strong consistency of data, so there is no need to worry about data loss. In production, it is recommended to deploy an odd number of PD nodes.

Finally, in a PD cluster, a node with a leader role provides stateless services to the outside world. All operations are triggered passively. Even if the PD node goes down, with the help of PD's elect mechanism, the newly elected PD leader can immediately serve the outside world without considering any intermediate state.

For the sake of later introduction, we need to synchronize the following nouns:

- Store
Store in PD refers to a storage node in a cluster, that is, a TiKV instance. Note that the 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 disk, these instances will correspond to different Stores.

- Region/Peer/Raft Group
Each region is responsible for maintaining a continuous segment of the cluster's data (an average of about 96 MB by default). Each replica stores multiple copies of the data in different stores (the default configuration is 3 replicas), each of which is called a peer. Multiple peers in the same Region synchronize data via the raft protocol, so peers are also used to refer to members of a raft instance. TiKV uses multi-raft mode to manage data, that is, each region corresponds to a raft instance that runs independently. We also call such a raft instance a Raft Group.

- Leader/Follower/Learner
They correspond to each of the three roles of Peer. The Leader is responsible for responding to the client's reads and writes request; the Follower passively synchronizes data from the Leader, and elects a new Leader when the Leader fails; Learner is a special role that only participates in synchronizing raft logs and does not participate in voting, and only exists briefly in the current implement to add Intermediate step of the replica.

- Region Split
Regions in a TiKV cluster are not divided at the beginning, but are generated gradually as data is written. The process of splitting is called Region Split.
The mechanism is that when the cluster is initialized, an initial Region is built to cover the entire keyspace, and then a new Region is generated by Split every time the Region data reaches a certain amount during the run.

- Pending/Down
Pending and Down are two special states that a peer may experience. Pending indicates that there is a large gap between the follower or learner's raft log and the leader, and the follower in the Pending state cannot be elect as a leader. Down means that the Leader has not received messages from the corresponding peer for a long time, which usually means that the corresponding node is down or isolated from the network.