In Pessimistic Transactions & RC Isolation Level, which TiKV interfaces might be called by snapshot read select requests?

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

Original topic: 悲观事务&&RC 隔离级别下,快照读 select 请求,可能会调用 TIKV 哪些接口?

| username: ylldty

In order to better understand TiDB’s pessimistic lock, I started a TiDB service locally, and TiKV is a program where I specifically added logs.

Using the MySQL client to adjust the transaction isolation level of TiDB to RC,
and enabling pessimistic transactions, I executed a Select request.

While observing the TiKV log requests at the same time, I found something quite strange:

  • After the select snapshot read request, I couldn’t see any requests for the RC or RcCheckTs isolation level parameters in TiKV at all.
  • Even the select request does not call the TiKV interface to return data.

Currently, I suspect that TiDB has some optimizations that can reduce interactions with TiKV but still achieve RC isolation level.

Or is it that my log printing position is incorrect, causing me not to see the corresponding logs?
Is there any way to adjust the log level to directly see the TiKV request logs?

| username: xfworld | Original post link

This is related to the kv API. I think it’s best for you to study the entire course…
https://learn.pingcap.com/learner/home

There are two types of APIs for fetching data in kv:

  1. Point queries: pointGet and batchPointGet
  2. Conditional queries: DistSQL (supports pushdown and non-pushdown)…

You might be looking in the wrong place because the mapping of data structures can lead to different ways of scheduling and executing data retrieval…

| username: ylldty | Original post link

You should have studied the course. May I ask if TiDB might have a layer of cached data that can directly handle RC-level select snapshot read requests without needing to send RPC to TiKV?

| username: xfworld | Original post link

Of course, there will be caching, just like MySQL…

There is caching at the TiDB level and at the TiKV level, and the caching modes and handling methods are also different…

| username: lemonade010 | Original post link

Sometimes the cached content causes it to be invisible.

| username: gcworkerishungry | Original post link

Confirm the application cache; also check if the coprocessor cache at the TiDB layer is being accessed.

| username: ylldty | Original post link

Through debugging the code of TiDB and TiKV, it was found that:

  • The statement select * from managers where first_name='brad8'; did not hit the index, so it did not use TiDB’s pointget but rather the coprocessor. Therefore, the TiKV interface called was not batchget but coprocessor.

  • Even for RC-level snapshot reads, TiDB uses SI isolation level get/coprocessor requests for TiKV. For this, TiKV’s code specifically makes special judgments for SI-level snapshot reads, not detecting pessimistic lock conflicts, to prevent select snapshot read requests from being blocked by other pessimistic transactions (e.g., other transactions executing select for update/update/delete):

  • Even for RC-level transactions, TiKV will still fetch lock information from LOCK CF. Although it will skip after reading the pessimistic lock, this is likely to ensure that in scenarios where pessimistic and optimistic locks coexist, RC-level transactions can still read newly committed transactions with optimistic locks. If an RC-level snapshot read encounters an optimistic lock, it will also return a lock conflict and then wait for the lock and retry.

| username: ylldty | Original post link

Thank you all for your replies.

| username: system | Original post link

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