TiDB's Follower Read Feature

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

Original topic: TiDB 的 Follower Read 功能

| username: zhanggame1

【TiDB Usage Environment】Production Environment / Testing / PoC
【TiDB Version】6.5.2
【Reproduction Path】
【Encountered Problem: Problem Phenomenon and Impact】
I saw in the documentation that TiDB by default can only read data from the leader region, but it can also be configured to read from followers by modifying parameters. The questions are:

  1. Can enabling follower read improve read performance?
  2. Will follower read cause inconsistencies, and is there any difference compared to leader read?

To enable TiDB’s Follower Read feature, set the SESSION variable tidb_replica_read to follower or leader-and-follower:
set @@tidb_replica_read = ‘’;
Scope: SESSION
Default value: leader

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

  1. Enabling follower reads can definitely improve read performance. For example, if many reads could only be directed to a single leader, it could easily create a read hotspot. Now, by allowing followers to handle reads as well, it changes from reading from one leader to reading from one leader and multiple followers, which will certainly improve performance.

  2. Will follower reads cause inconsistency, and how do they differ from leader reads? Follower reads are strongly consistent reads, meaning that before reading from a follower, it ensures that the follower’s data is up-to-date with the leader. The difference from leader reads is that originally only one leader could provide read services, but now followers can also provide read services.

| username: TiDBer_jYQINSnf | Original post link

Let me add a few points:

  1. The operating principle of follower read is: when a follower node receives a read request, it goes to the leader node to get the position to which the current leader node has applied. Then, when the follower also applies to this position, it indicates that the data for the read request that reached the follower is already consistent with the leader. So the data is definitely consistent.
  2. Can follower read improve performance? For very balanced read requests, it cannot. This is because follower read involves one more read index request to the leader. Overall, it wastes the cluster’s CPU and network resources, so if the read requests to each node in the cluster are already very balanced, there should be no performance improvement.
  3. Suitable scenarios for follower read:
    Coprocessor scan requests: For this request, the time wasted on one more interaction with the leader is very small compared to the subsequent region scan, making it worthwhile. However, this also has a prerequisite: the leader is overwhelmed. If the leader can easily handle these requests, then the resources of the follower node should be left for the leaders of other regions to use. In other words, it is indeed useful during read hotspots.
    Additionally, during leader switching, the original leader becomes a follower. At this time, the client’s cache for the region has not been updated and still sends requests to the old leader. If follower read is not enabled, the original leader will reject the request, and the client will have to resend it. If follower read is enabled, it saves one round trip, which is also a small benefit.

Personal understanding, for reference only :grin:

| username: system | Original post link

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