Some Questions About Follower Read

Translated
1

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

Original topic: 关于Follower Read 一些问题

| username: zhanggame1

【TiDB Usage Environment】Production Environment / Testing / PoC
【TiDB Version】7.1
【Encountered Follower Read Issue: Problem Phenomenon and Impact】
Regarding Follower Read, the official documentation is as follows:
Follower Read | PingCAP Documentation Center
I have some questions:

  1. This feature looks good and can eliminate read hotspots, but why is it not enabled by default in the cluster? Are there any potential issues?
  2. If enabled, what target value is generally recommended for tidb_replica_read?
2
| username: ShawnYan | Original post link

Not entirely, it’s just that the read and write pressure are not together. The read hotspot issue (for many reasons) still exists.

3
| username: redgame | Original post link

My understanding is that it has scenario limitations and is not suitable for all situations. Follower strong consistency reads can put a lot of pressure in production.

4
| username: zhanggame1 | Original post link

Looking at the principle, follower read shouldn’t involve many mechanism adjustments.
I guess it might be that writing to 2 out of 3 replicas is considered successful, which means there will definitely be a slow follower that needs to wait. It probably sacrifices latency to improve read performance.

5
| username: zhanggame1 | Original post link

Additionally, there is an overhead of accessing the leader before the follower provides the data, which will increase the latency.

6
| username: tidb菜鸟一只 | Original post link

  1. This feature only looks good on the surface. If you currently have a TiKV node with a leader backlog and all read pressure is concentrated on this TiKV node, you can enable follower read to allow other idle TiKV nodes to share the pressure. However, if your TiKV node leaders are balanced (which is highly likely), and only a specific region or table has a read hotspot, enabling this might slightly alleviate the hotspot issue. After all, reading from one region becomes reading from three regions (with three replicas, choosing tidb_replica_read = leader-and-follower), but for the overall read pressure load, it simply adds an extra network load. Originally, they only needed to read from the leader, but now it first goes to the follower node, then accesses the leader’s latest commit index through the network, and then reads from the follower node.

  2. If you enable it, in cases where labels are used, choose closest-replicas or closest-adaptive, but not leader-and-follower. However, enabling this might reduce the overall QPS of the cluster.

7
| username: chenhanneu | Original post link

If the apply index of the follower node is applied quickly, can it avoid the issue of the follower read reading data newer than the leader’s? To ensure that the data read has been applied on the leader node, does it require at least one more network interaction to know the leader’s apply status?