Current TSO Corresponding System Time

Translated
1

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

Original topic: 当前TSO对应的系统时间

| username: HACK

【TiDB Usage Environment】Production Environment or Test Environment or POC
【TiDB Version】
From the Grafana interface, you can see the current TSO

%E5%BE%AE%E4%BF%A1%E5%9B%BE%E7%89%87_20220714135436
%E5%BE%AE%E4%BF%A1%E5%9B%BE%E7%89%87_202207141354361332×998 380 KB

  1. Why is the system time corresponding to this TSO 1970-01-01 08:00:06 when I check it through the PD tool?

  2. Is this TSO different from the TSO corresponding to the GC safepoint? I see that the number for the GC safepoint is much larger than this value.

【Encountered Issues】
【Reproduction Path】What operations were performed that caused the issue
【Problem Phenomenon and Impact】

【Attachments】

Please provide the version information of each component, such as cdc/tikv, which can be obtained by executing cdc version/tikv-server --version.

2
| username: db_user | Original post link

Monitoring’s *Current TSO: The physical timestamp part of the currently allocated TSO, which is what we normally understand as a timestamp.

The explanation of the TSO corresponding to the GC’s safepoint is as follows:

image
image1338×1000 251 KB

3
| username: HACK | Original post link

Question 1:
Control’s * Current TSO: The physical timestamp part of the currently allocated TSO, which is what we normally understand as a timestamp.
So can I use this TSO to check the physical time it represents?

Question 2:

111
1111064×809 336 KB

What does this logic represent?

4
| username: Gin | Original post link

Time to TSO (take the first logical value)

select conv(concat(bin(unix_timestamp('2022-01-13 17:19:32')*1000),'000000000000000001'),2,10);

TSO to time (many-to-one)

select from_unixtime(conv(left(bin('430457637306368001'),41),2,10)/1000);
select from_unixtime(conv(left(bin('430457637459197954'),41),2,10)/1000);
5
| username: db_user | Original post link

Logic refers to logical time, which is the logical clock part in the diagram above. The conversion of the physical timestamp above can be done in this way.

6
| username: Gin | Original post link

TSO consists of 46 physical bits and 18 logical bits, meaning that one physical time corresponds to 2^18 TSOs. In pd-ctl, the logic is the value of these 18 bits converted to decimal.

7
| username: ddhe9527 | Original post link

In version v5.4.0, the title has been changed to “Current TSO Physical” to avoid misunderstandings. This time is the high 46 bits in the TSO and cannot be directly converted using pd-ctl tso. To put it simply, you first convert the “Current TSO Physical” value to binary format, then pad 18 zeros at the end, and convert it back to decimal format. You can then use pd-ctl tso to view the value.
Dingtalk_20220714143425

8
| username: HACK | Original post link

The time that comes out of this needs to be +8, right?

9
| username: Gin | Original post link

There is no need for that. The timezone used when the TSO is generated will be the same timezone when it is converted.

10
| username: HACK | Original post link

Well, it should be related to the time zone of the cluster.

mysql> select @@global.time_zone, @@global.system_time_zone;
±-------------------±--------------------------+
| @@global.time_zone | @@global.system_time_zone |
±-------------------±--------------------------+
| UTC | Asia/Shanghai |
±-------------------±--------------------------+
1 row in set (0.00 sec)

mysql>

11
| username: system | Original post link

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