Are the TSO allocated by PD and the timestamps used during TiKV GC the same thing?

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

Original topic: PD 分配的TSO 和 tikv gc 时 依据的时间戳 时一回事么?

| username: TiDBer_9hpPRMwf

[TiDB Usage Environment] Testing
[TiDB Version] 6.5.0
[Encountered Issue: Problem Phenomenon and Impact]
Hello experts, I have a question. When TiServer writes data to TiKV, it gets the timestamp from PD, but PD returns a timestamp that is 3 seconds in the future. When multiple TiServers request timestamps from PD, the timestamps can only ensure incrementality but cannot correspond to the actual time. For example, if t1 and t2 request TSO from PD in a short period, t1 gets the TSO for the time now() + 3 seconds, and t2 gets the TSO between [now() + 3, now() + 6] seconds. When t2 uses the TSO as start-ts to write to TiKV, it cannot be used as a basis for reading old snapshot data, right?

| username: Billmay表妹 | Original post link

The TSO timestamp returned by PD is incremental, but it is not a real timestamp; rather, it is a globally unique incremental sequence. This sequence is generated and allocated by PD to ensure global consistency of all transactions in the TiDB cluster.

In a TiDB cluster, each TiKV node requests a TSO timestamp from PD. When multiple TiKV nodes simultaneously request TSO timestamps from PD, PD generates a future timestamp range based on the current time and allocates this range to these TiKV nodes. This approach is designed to avoid performance bottlenecks caused by multiple TiKV nodes requesting the same TSO timestamp simultaneously.

When writing data to TiKV, TiDB uses the TSO timestamp returned by PD as the transaction’s start timestamp (start-ts). This timestamp is globally unique and ensures the execution order and consistency of all transactions in the TiDB cluster. Therefore, even if multiple TiKV nodes simultaneously request TSO timestamps from PD, the timestamp ranges they receive are different, preventing the occurrence of identical timestamps.

When reading old snapshot data, TiDB uses the snapshot’s timestamp as the transaction’s start timestamp. This timestamp is generated when reading the snapshot and is unrelated to the TSO timestamp returned by PD. Therefore, even though the TSO timestamp returned by PD is not a real timestamp, it does not affect TiDB’s ability to read old snapshot data.

| username: TI表弟 | Original post link

Is clock synchronization configured?

| username: TiDBer_9hpPRMwf | Original post link

I understand this point. However, I am not quite clear about the following scenario:

For example, at moment m1, say 00:00, there are three TiServers: t1, t2, and t3.

  • t1 requests a TSO from PD, and PD returns a time range of now+3=00:03, recording the next allocation starting point as 00:03.
  • Then, in less than 1 second, say at 00:01, t2 also requests a TSO from PD.
  • At this time, PD returns a TSO range of [now+3 (00:03), now+6 (00:06)] to t2. Can the TSO obtained by TiServer be used as an accurate time? If a query requires old snapshot data at t2, is this TSO time used for judgment?
| username: TiDBer_9hpPRMwf | Original post link

This post explains it quite clearly.

| username: system | Original post link

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