# Pd Architecture

![left](./student-guide/diagram/04-PD-Architecture-01-01.png)
------------------------------------------------------------
PD is the central master of the TiDB database and is called the “brain” of the entire cluster. In a TiDB database cluster, it is responsible for storing metadata (mainly providing routing for TiDB Servers, etc.), assigning global IDs, transaction IDs, generation of global timestamp TSO, service discovery, collection of information such as the overall cluster topology, real-time data distribution and hot spot status, and scheduling data in TiKV nodes. At the same time, the TiDB Dashboard service is provided.

Next, let's take a look at the architecture and composition of PD. The PD itself consists of at least 3 nodes. PD supports auto failover by integrating etcd without worrying about single point of failure. At the same time, PD also uses ETCD's raft to ensure strong data consistency without worrying 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, the newly elected PD leader can immediately serve the outside world with the help of PD election mechanism, regardless of any intermediate state.

For later introduction, we need to synchronize the following terms:
- Store
  Store in PD refers to the storage node in the cluster, that is, the TiKV instance. Note that Store and TiKV instances are strictly one-to-one correspondence. Even if multiple TiKV instances are deployed on the same host or even the same disk, these instances will correspond to different Stores.

- Region/Peer/Raft Group
  Each Region maintains a contiguous piece of data for the cluster (an average of about 96 MB by default), with multiple copies of each data stored in different Stores (3 replica by default), and each replica is called a peer. Peers in the same region synchronize data via the raft protocol, so peers are also used to refer to members in the raft instance. TiKV uses a multi-raft mode to manage data, that is, each region corresponds to an independent raft instance. We also call such a raft instance a Raft Group.

- Leader/Follower/Learner
  They correspond to each of the three roles of the peer. The Leader is responsible for responding to reads and writes request from the client; the Follower passively synchronizes data from the Leader, and when the Leader fails, a new Leader is elect; the Learner is a special role that only participates in synchronizing the raft log and not voting, and only exists briefly in the current implement for adding Intermediate steps for replica.

- Region Split
  Region in a TiKV cluster are not divided at the beginning, but are generated gradually as data is written, and the splitting process is called region split.
The mechanism is to construct an initial region to cover the entire key space when the cluster is initialized, and then a new region is created through Split every time a certain amount of region data reaches a certain amount during operation.

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