Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.
Original topic: lease read的线性一致问题
[TiDB Usage Environment] Poc
[TiDB Version] 5.1.0
[Reproduction Path] -
[Encountered Problem: Phenomenon and Impact]
Is the lease read implemented by TiKV strongly consistent? If the following execution order is followed, is there an issue?
- client put (k,v), returns timeout (for example, due to some reasons, it takes too long to apply to rocksdb)
- client get (k), lease read directly fetches data from rocksdb, returns not found
- apply completes, write is successful.
In this case, does TiKV define 1 and 2 as concurrent read and write with an indeterminate order? However, from the client’s perspective, 1 and 2 have a causal relationship. Does this violate linearizability? Is this case only solvable using read index?
[Resource Configuration] Go to TiDB Dashboard - Cluster Info - Hosts and take a screenshot of this page
[Attachments: Screenshots/Logs/Monitoring]
The role of logs is indispensable.
I don’t understand what this has to do with logs.
The lease read implemented by TiKV is strongly consistent. According to TiKV’s official documentation, TiKV uses the lease read mechanism to ensure strong consistency. In lease read, TiKV renews the leader’s lease by recording timestamps to ensure data consistency. Even in cases of timeouts or other issues, TiKV guarantees data consistency [1].
In the scenario you described, if the client performs the following operations:
- The client executes a
put (k,v) operation, but it times out.
- The client executes a
get (k) operation, and the lease read directly fetches data from RocksDB, but it returns as nonexistent.
- The apply is eventually completed, and the write is successful.
From TiKV’s perspective, there is indeed a concurrent read-write situation in this case because, in step 2, the data might not have been successfully written yet, leading to a failure to read the data. However, from the client’s perspective, these two operations have a causal relationship, and the client expects to be able to read the corresponding data after a successful write.
To address this situation, TiKV provides the ReadIndex solution. By using ReadIndex, the client can ensure that the latest write operations are considered when reading data, thereby avoiding similar concurrent read-write issues. Therefore, if you are concerned about linear consistency, you can consider using ReadIndex to resolve this situation.
This is an AI response fed with TiDB materials 
It must be strongly consistent, see the answer to the first question for details.
|
username: Destiny池鱼
|
username: 
|
username: 
|
username: 
|
username: 
|
username: