硬核讨论:TiDB TSO 跳到未来时间,到底有没有无损恢复方案?

测试环境误改 PD 系统时间导致 TSO 飘到 5 年后。现象:TSO 极慢、GC 卡住、锁永生、集群基本不可用。

目前已知稳妥方案:清空数据重置 tso_base。

想问下社区:到底有没有不清空数据、无损修复 TSO 时间偏移的生产可行方案?

欢迎大佬技术对线!

2 个赞

官方无直接回退 TSO 的无损方案;可行路径仅:等真实时间追上、或用 FLASHBACK/PITR 回退到故障前,均无需清空全量数据,但非绝对无损。

1 个赞

TSO 无法直接回退,不想清数据可等待时间对齐或闪回恢复,暂无完美无损修复手段。

TSO 暂时无法直接回退。

1 个赞

TSO回退就不用想了,违背了常理啊

1 个赞

目前无法直接回退哟

1 个赞

这个问题我实际用过一段时间,从使用体验来看,TiDB 的运维确实比想象中简单,TiUP 一键部署升级,Grafana 面板一目了然。文档也比较全,大部分问题都能查到。

1 个赞

这个问题我实际用过一段时间,从使用体验来看,TiDB 的运维确实比想象中简单,TiUP 一键部署升级,Grafana 面板一目了然。文档也比较全,大部分问题都能查到。

社区无官方无损修复方案,存量数据无法直接回退 TSO,仅能清空数据重置 tso_base;保守方案为全量备份重建集群规避数据丢失。

暂停这个使用到5年后?

暂无直接回退 TSO 无损方案咯。可等时间追上或闪回恢复,清空重置才算是稳妥手段

学习了。TSO

怎么改的,有没有详细的信息可以分享下

目前并没有已知稳妥且无损的修复方案

不要尝试直接修改 PD etcd 里tso的原始 KV 键值:PD 启动会强制校验 TSO 单调递增,强行写入更小物理时间的 TSO,PD Leader 直接选举失败,TSO 服务彻底不可用

这个应该是我那个贴子构造出来的问题
构造原理很简单,直接改所有pd所在节点的系统时间

TSO 大幅跳到未来后,MVCC/GC/锁时间戳都会乱,社区和官方一般没有可靠的「不清数据回拨 TSO」生产方案;reset tso_base 或重建集群是常见做法。测试环境若必须保数据,只能评估备份还原到误操作前 + 专业支持,风险很高。预防比修复重要:NTP/chrony 统一校时、禁止手工改 PD 系统时间、监控 TSO 漂移告警。

这么久了还没关, 估计还是没合适的处理办法

分布式要求时间准确的,不用回退,直接建新集群做数据恢复吧。

  1. 重启 PD 集群
  2. 检查并清理“未来数据”