Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.Original topic: Tikv Follower Read
|
username: TiDBer_NGmQDBXo
TiKV version 6.0
What is the principle of TiKV Follower Read?
When the client sends a request, it asks the PD for the Region leader information. If it is a Follower Read, does the PD randomly give the client the TiKV node address?
What is the Follower Read process?
The video lesson explains it in great detail, highly recommended to watch.
By default, TiDB adopts the “strong leader” strategy, where read and write requests for a Region are handled by the Leader. However, when there are hot Regions in TiDB, the Leader can become a bottleneck. Follower Read refers to using the Follower replicas of a Region to handle read tasks while ensuring linear consistency, thereby improving the read throughput of the TiDB cluster and reducing the Leader’s load. Follower Read includes a series of load balancing mechanisms that offload TiKV read loads from the Region Leader replica to the follower replicas (sending read requests for a Region to Follower nodes based on load balancing strategies). To enable the Follower Read feature in TiDB, set the SESSION variable tidb_replica_read to either follower or leader-and-follower.
10:00: User A initiates a COMMIT command with commit_ts at 10:00. Its raft log is 1-95, which is only persisted in raftdb and not yet applied to kvdb. The COMMIT can only return after 1-95 is successfully applied to kvdb.
10:05: The raftdb log increases to 1-97, and the kvdb log is applied up to 1-93. User A’s COMMIT has not yet returned.
10:08: The kvdb applies the log up to 1-95, i.e., ApplyIndex is 1-95, and User A’s COMMIT operation successfully returns.
10:00: In raftdb, the log has already committed up to 1-96, consistent with the Leader replica node, but the apply is slower than on the Leader.
10:05: User B initiates a Follower Read, requesting the latest log in raftdb from the Leader replica node, which is 1-97, i.e., CommitIndex is 1-97.
10:10: The CommitIndex log is applied in the kvdb of the Follower replica, and User B starts reading data from kvdb.
In fact, Follower Read can be faster than reading from the leader by default because reading from the leader requires waiting for the kvdb to apply up to the ReadIndex, meaning all COMMIT operations initiated before the read must be completed. If the Follower node’s performance is good enough and applies quickly, it might apply up to the CommitIndex before the leader completes its COMMIT, allowing Follower Read to start reading data from kvdb earlier without breaking linear consistency.
|
username: 
|
username: 
|
username: 
|
username: