When backing up, is the backup of the region's leader or follower?

This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: br 备份的时候,备份的是region的leader还是follower

| username: Raymond

May I ask, when using BR for backup, does it back up the region’s leader or follower?

| username: 啦啦啦啦啦 | Original post link

It should be the leader because the data on the leader node is the most up-to-date, while the data on the follower node may lag behind the leader node.

| username: Raymond | Original post link

It is the leader, but isn’t there a follower that keeps in sync with the leader?

| username: TiDBer_jYQINSnf | Original post link

Since there are writes happening all the time, let’s assume there are three replicas: A, B, and C. A is the leader, so A is definitely the most up-to-date, but B and C might take turns being the most up-to-date.

If you want to back up from B or C, you would need to use follower read or something similar, which complicates things. Why not just get it directly from the leader to make it simpler?

If the goal is to reduce the leader’s load, then there might be a misunderstanding of the leader distribution in TiKV. Each TiKV node has both leaders and followers, meaning you can’t find a machine without a leader. Unlike MySQL replicas, you can’t just mess around with them freely.

| username: Raymond | Original post link

Hi there, I have a question I’d like to ask. Suppose there are three replicas, A, B, and C, with A being the leader. If the leader has already committed the raft log and subsequently applied it, can the leader directly respond to the client without waiting for the followers to also apply the raft log?

| username: TiDBer_jYQINSnf | Original post link

The prerequisite for raft log commit is receiving confirmation from the majority of nodes.
The write process is roughly as follows:

  1. The leader proposes a raft log, assuming the index is 1, and this index will increment.
  2. The leader appends this message locally and then broadcasts it out, without changing the committed status.
  3. After receiving the message, the follower appends it, updates the local committed status, and returns it to the leader.
  4. After the leader receives the committed index from the majority of nodes, it updates their commit index according to the followers’ replies, using a structure that records each peer’s commit progress.
  5. The leader updates the local committed status based on the majority commit progress of the peers. For example, if the progress is [2,2,2,5,5], it becomes 2; if it is [2,2,5,5,5], it becomes 5.
  6. The raft process is then completed, and the leader applies the changes and returns.

The above process is a main flow roughly derived from the code, and there are many exception handling processes. It is for reference only. For detailed understanding, you should look at the raft process:

| username: Raymond | Original post link

Great job, master!

| username: zhanggame1 | Original post link

According to the documentation, all reads and writes can only access the leader.

| username: system | Original post link

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.