硬核讨论：PD 系统时间被调至未来，TSO 漂移后如何修复？

🪐 TiDB 技术问题
1

测试环境误改系统时间，导致 TSO 停留在未来时刻，出现 GC 停滞、锁无法释放、TSO 推进极慢等问题。目前已知方案是清空数据后重置 tso_base，想问问社区：

  1. 现存业务数据的情况下，有没有无损修复的可行方案？
  2. 日常运维中，如何预防服务器时钟跳变引发 TSO 异常？
1 个赞
2

“重置 tso_base” 具体是个什么操作？

1 个赞
3

1、如果时间差距太大，除了重建集群好像没什么办法，按照整个PD都损坏的方式重建PD不知道是否可行；
2、配置时钟服务微调模式，避免时钟跳变过大，Linux增加命令限制审计吧。

1 个赞
4

能重置tso信息？

1 个赞
5

现存数据可通过 PD 手动微调 TSO 时序实现无损修复，运维部署 NTP 锁时钟、PD 开启时钟校验规避时间跳变引发 TSO 故障。

6

TiDB 的架构设计借鉴了 Google Spanner 和 F1 论文的思路，但做了大量简化和优化。比如 Raft 协议只用于复制，不用于全局事务协调；PD 的调度策略是启发式而非一致性算法。理解这些设计取舍对用好 TiDB 很有帮助。

1 个赞
7

我实际跑过的场景是 xxx TB 规模的 OLTP 业务，上线后整体稳定。需要注意的主要是慢查询监控和热点防范，这些通过 Dashboard 都可以提前发现。

8

从技术角度，TiDB 最大的亮点是把分布式系统的复杂逻辑封装在了底层，对应用层呈现的是 MySQL 兼容的 SQL 接口。这意味着你可以用单机数据库的经验来操作一个分布式数据库，但排障时需要理解分布式内部的交互机制。

10

不能重置TSO吧