【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】7.1
【遇到的Follower Read 问题：问题现象及影响】
关于Follower Read ，官方文档如下：
Follower Read | PingCAP 文档中心
有一些疑问：
1、这个功能看起来不错可以消除读热点，但是集群默认为什么不开，有什么潜在问题吗？
1、如果开，一般推荐tidb_replica_read哪种目标值设置
并不全是，只是读写压力不在一起，读热点问题（好多原因）仍存在
我的理解，它有场景限制，并不是所有场合都好用。Follower 强一致读，这里在生产中，会有很大压力
看原理follower read应该没有多少机制调整。
我猜测可能3副本写两个就算成功，那肯定有慢的follower需要等待，应该牺牲了延时提高读性能。
另外follower提供数据前还有一次访问
leader的开销，延时会增大
1 个赞
1.这个功能只是看起来不错，如果你现在有一个tikv节点leader堆积，读压力全部积压在这个tikv节点上，可以开启follower read 来让其他空闲的tikv节点来分担这个tikv的压力，但假如你的tikv节点leader均衡（极大概率情况），只是某一个region或者表有读热点，你开启这个，可能对这个热点问题略有缓解，毕竟从1个region读变成3个redion读（3副本，选tidb_replica_read =leader-and-follower情况），但是对整体的读压力负载来说，就是单纯的增加了一次网络负载罢了，本身他们只需要读leader就可以了，现在变成了先去follower节点，然后通过网络再访问一下 leader 最新 commit index 后，再来读follower节点。
2.开的话，有打label的情况选closest-replicas或者closest-adaptive，没有选 leader-and-follower这个吧，但是这个开了有可能会降低整个集群的qps
1 个赞
follower节点的apply index应用的快的情况下，能避免follower read读到的比leader的数据新的问题吗？要确保读到的数据都在leader节点上apply过了，是不是至少要再多一次网络交互知道leader的apply情况