How to Ensure Readers Can Read the Most Recent Modifications with Linear Consistency?

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

Original topic: 线性一致性如何保证reader能读到最近的修改?

| username: TiDBer_CvDGdpUC

TiDB’s read index achieves linear consistency by reading the committed raft log with the highest number from the leader. Suppose the scenario is as follows:

  1. Thread 1 obtains commit_ts from PD and starts committing.
  2. Thread 2 obtains read_ts from PD and starts reading (commit_ts < read_ts).
  3. When thread 2 reads from the leader region, thread 1’s raft log has not yet been successfully committed (it might be in the process of replication).

In this case, wouldn’t the raft log index read by thread 2 not include the commit from thread 1? However, the read time of thread 2 is later than that of thread 1. What mechanism does TiDB have to avoid this scenario?

| username: 大鱼海棠 | Original post link

You can refer to this: TiKV 功能介绍 - Lease Read | PingCAP

| username: 裤衩儿飞上天 | Original post link

Learn about distributed transactions and MVCC.

| username: neilshen | Original post link

Recommended reading this article: Linearizability and Raft

| username: TiDBer_CvDGdpUC | Original post link

Thank you for your reply. Perhaps I didn’t describe it clearly. What I’m confused about is how a readindex operation can ensure that it includes the most recently committed log. As described in the example, the read time of thread 2 is later than that of thread 1, but if the raft log of thread 1 gets stuck during the commit process, what will thread 2 read? Even if it successfully commits later, thread 1 has already returned, wouldn’t that violate linear consistency?

| username: yilong | Original post link

The waiting state machine at least applies the Log recorded by ReadIndex, which is explained in this step.

| username: system | Original post link

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