测试环境误改系统时间，导致 TSO 停留在未来时刻，出现 GC 停滞、锁无法释放、TSO 推进极慢等问题。目前已知方案是清空数据后重置 tso_base，想问问社区：
- 现存业务数据的情况下，有没有无损修复的可行方案？
- 日常运维中，如何预防服务器时钟跳变引发 TSO 异常？
1 个赞
“重置 tso_base” 具体是个什么操作？
1 个赞
1、如果时间差距太大，除了重建集群好像没什么办法，按照整个PD都损坏的方式重建PD不知道是否可行；
2、配置时钟服务微调模式，避免时钟跳变过大，Linux增加命令限制审计吧。
2 个赞
能重置tso信息？
1 个赞
现存数据可通过 PD 手动微调 TSO 时序实现无损修复，运维部署 NTP 锁时钟、PD 开启时钟校验规避时间跳变引发 TSO 故障。
TiDB 的架构设计借鉴了 Google Spanner 和 F1 论文的思路，但做了大量简化和优化。比如 Raft 协议只用于复制，不用于全局事务协调；PD 的调度策略是启发式而非一致性算法。理解这些设计取舍对用好 TiDB 很有帮助。
1 个赞
我实际跑过的场景是 xxx TB 规模的 OLTP 业务，上线后整体稳定。需要注意的主要是慢查询监控和热点防范，这些通过 Dashboard 都可以提前发现。
从技术角度，TiDB 最大的亮点是把分布式系统的复杂逻辑封装在了底层，对应用层呈现的是 MySQL 兼容的 SQL 接口。这意味着你可以用单机数据库的经验来操作一个分布式数据库，但排障时需要理解分布式内部的交互机制。
不能重置TSO吧
集群所有节点部署 NTP/chrony 时钟同步服务，PD 开启时钟校验，限制系统时间大幅跳变并增加时钟监控告警
1 个赞
不存在原地无损重置 TSO 方案，无损修复需导出数据重建集群导入；短期应急可维持未来时钟等待 TSO 自然回落，仅适用于测试小集群。
如果系统时间跳变后，PD 的 tso_base 被推到了未来，可以通过调整 PD 的底层元数据来尝试“拉回” TSO 的起点。
无原地无损修复方案，无损需全量导出数据、重建 PD 校准时间后导入；小测试集群可维持未来时钟等待 TSO 自然回落。