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

请问一下,br 备份的时候,备份的是region的leader还是follower

应该是leader,因为leader节点上的数据是最新的,而follower节点上的数据可能会滞后于leader节点。

是leader,
但是不是说有个follower 会和leader 保持一致吗

https://docs.pingcap.com/zh/tidb/stable/br-snapshot-architecture#备份流程

因为每时每刻都有写入,假设有ABC 3个副本,A是leader,那A肯定是最新的,但是B\C可能轮流是最新的。
如果要从B\C 备份,还需要走follower read之类的,何必那么复杂,直接从leader拿岂不是省事儿?

如果说想减轻leader的压力,那对tikv的leader分布理解还不太到位,每个tikv上都有leader和follower,也就是说找不到一个机器上没有leader,不存在mysql那样的从库,可以随便折腾的。

大佬,这边想请教1个问题,假设有ABC 3个副本,A是leader,如果这个时候leader 已经将raft log commit了,并且随后也将这个raft log apply了,那么是不是这个leader 可以直接回复客户端,并不需要等待follower 也apply raft log了

raft log commit的前提是收到了大多数节点的确认。
写流程大概是这样的:

  1. leader proposal 一条 raftlog,假设index是1,这个index会递增
  2. leader 本地append这个消息,然后广播出去,leader没有更改committed
  3. follower 收到消息后,append,更改本地的committed,并返回给leader
  4. leader 收到大多数节点的 committed index后, leader里面有记录每个peer的commit进度的结构,按照follower的回复更新他们的commit index。
  5. leader 根据peer中大多数提交的进度,假如是[2,2,2,5,5],这时候就是2,假如是[2,2,5,5,5] 这时候就是5,更新本地的committed。
  6. 然后raft这边就走完了,leader apply以后就返回了。

上面的流程是看着代码大概捋出来的一个主流程,还有很多异常处理的流程。仅供参考,详细了解的话还是看看raft的流程:
http://www.kailing.pub/raft/index.html

大佬强

按文档说法所有读写都只能访问leader