Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.Original topic: txnLockFast读写冲突发生的场景
|
username: TiDBer_iLonNMYE
In Grafana monitoring, txnlock indicates the presence of write-write conflicts in the cluster, while txnLockFast indicates the presence of read-write conflicts in the cluster. TiDB uses MVCC to avoid read-write conflicts, so what other scenarios might cause txnLockFast?
Lock table in share/exclusive mode?
Got it.
The following description is clear and concise, thank you!
“In TiDB, when reading data, a timestamp that includes the current physical time and is globally unique and incrementing is obtained as the start_ts of the current transaction. When the transaction reads, it needs to read the latest data version of the target key whose commit_ts is less than the start_ts of this transaction. When a lock is found on the target key during reading, a read-write conflict occurs because it is impossible to know whether the transaction that locked it is in the Commit phase or the Prewrite phase.”
This topic will be automatically closed 60 days after the last reply. No new replies are allowed.
|
username: 
|
username: