[Course Issue] Core Principles and Architecture of TiDB Database [TiDB v6]: TiKV - Read/Write and Coprocessor

Translated
1

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

Original topic: 【课程问题】TiDB 数据库核心原理与架构 [TiDB v6] ：TiKV- 读写与 Coprocessor

| username: 箱子NvN

When a read request comes to Minions, does it first apply and check if there is no entry 95, then read from Raft and apply index-read? Or does it directly check Raft to see where it has committed and then wait?
How does it know it needs entries 1-95?
Why does it check Raft instead of searching in the applied KV? KV should have previous data, so without MVCC, shouldn’t it be able to read the previous data?

2
| username: MrDuin | Original post link

For this issue, here is my understanding of the image process. If there are any mistakes, please help to correct them.

  1. The green session committed the modifications corresponding to raft log index 1-95 at 10:00, but the raft KV has not yet applied to 1-95.
  2. The yellow session initiated a read request at 10:05 to obtain the content corresponding to raft log index 1-95, initiating the following process:
    1. Check the latest value (maximum value) of the raft log index at the current time and save it locally in the current read session. This raft log index is the so-called ReadIndex.
    2. In TiKV, all read and write operations are performed on the leader node, so a current leader determination will be made through a heartbeat. After receiving responses from the majority of nodes, the current node will consider itself still the leader and continue with subsequent operations.
  3. The green session waited until 10:08 for TiKV to complete the apply of the write operation’s raft log index 1-95 (persisted to RocksDB KV).
  4. The yellow session waited until 10:09 for TiKV to complete the apply of the raft log index corresponding to the local cache’s ReadIndex. At this point, it meets the conditions for linearizability read, reads the Raft KV values corresponding to 1-95, and returns the result to the client.
3
| username: MrDuin | Original post link

By the way, a friendly reminder: in the course, Teacher Dong Fei specifically emphasized that the explanation is from the Raft layer and RocksDB layer, and the MVCC mechanism is not considered here.

4
| username: ddhe9527 | Original post link
  1. Directly check in raftdb to see where the commit is.
  2. It doesn’t need to know that it needs to read 1-95, but ReadIndex Read can ensure that it will definitely read the changes from 1-95 in kvdb, ensuring that linear consistency is not broken.
5
| username: system | Original post link

This topic was automatically closed 1 minute after the last reply. No new replies are allowed.