系统时间被调整到了五年后，如何恢复

🪐 TiDB 技术问题
,
1

【TiDB 使用环境】测试环境
【TiDB 版本】v8.5.4
【部署方式】物理机
【特别说明】不直接使用TiDB，而是直接调用txnKV API使用集群。格式为apiv1。
【问题复现路径】测试中，将PD Leader的系统时间调整到了五年后，然后又调回现实时间。已经确认TSO被留在5年后。集群出现如下现象：

  • TSO对应的物理时间为五年后某个时间的值
  • TSO推进速度显著慢于现实速度——可预期，已知PD通过这种机制来等待物理时间追上，以应对轻微的时钟不同步的情况；但我们的测试太过于激进了
  • 个别锁的生命周期似乎出现问题。个别事务遇到锁后重试20s仍然没能清掉残留锁，等待10h后，TSO推进了约2min，重新执行事务，锁得到清除
  • GC safepoint按TSO的流逝速度计算推进，也就是说，正常情况下，TSO和物理时间同步推进10min时，safepoint推进一次；在我们的集群里，同样需要TSO推进10分钟才推进一次，但现实时间可能过去了十几个乃至二十几个小时

问题如下：

【再次提醒，本集群无法使用基于SQL的TiDB的备份或导出方式，也无法使用只适用于rawKV的备份或导出方式】

  • TiKV是否有可以“洗掉”txnKV MVCC版本信息的全量导出工具？
  • 除了全量转移数据，是否有其他的修复集群状态的捷径？
  • 锁的行为会如何？这种情况下锁的TTL如何计算？
  • 计划进行一轮测试后清理tikv集群中的所有数据。若在确认没有数据后强行通过etcdctl修改系统当前TSO，是否是安全且无后遗症的？
  • 对于运行在未来时间点TSO的集群，是否会有其他已知的异常行为？
2

TSO信息应该会被影响吧,每个事务类操作都会记录这个tso啊

3

使用tikv-ctl的compact命令，有个这个命令

4

不能通过dumpling逻辑导出吗？

5

这个有结论了么？向了解怎么处理。tidb针对时钟被调整是怎么处理的 ？

6

构建新集群 + 数据重写

7

能想到最直接的办法就是重构了

8

急求一个懂锁TTL如何计算的大神💦
已经观察到异常的txn检查锁流量了

9

十分好奇这种情况怎么解决。
解决了 建议写个小作文。

10

空集群 → 强制重置 PD tso_base

12

若无有效备份且 GC 安全点已因系统时间错乱被推至未来，‌TiDB 无法恢复因 GC 清理而丢失的历史版本——此时只能依赖外部全量备份（如每日 BR 备份）恢复到最近正常时间点。

13

学到了

14

那就索性把pd leader的时间再调整到5年后，这样使用会有什么问题吗？反正，也没有业务从pd取时间戳写到数据里。

15

用 BR 把有用数据全量导出（txnKV 含 MVCC）。
停止集群 → 删除所有 TiKV data → 用 pd-recover 重置 TSO。
所有节点配置 NTP，禁止再乱改系统时间。
旧集群直接废弃，不要在上面做任何业务。