难道没解了吗？
1 个赞
应该也好处理，找个维护窗口同步一下，ntpd同步总归是要修的
时间慢于当前时间可以正常调整吧，时间快于当前时间不好弄吧，尤其是有时间戳的数据
时间落后，调前还好。
时间超前往回调就麻烦一些，而且超前越多越难办。停服和不停服操作，业务可能都会受影响，只能说哪个影响更小一点了。
那应该如何解决
楼主解决了吗？
1 个赞
结论是时间调整不会导致TSO回退，TSO会一直递增往前持续下去，这个是没问题的。
但有可能引发一些逻辑问题，比如依赖本地时钟而获取的关键时间，比如GC推进时间、周边工具BR或TiCDC等在pd 注册的GC safe point 等时间点会有逻辑问题，进而引发其他使用问题。
起码TSO不会回退就保证了数据不会错乱的情况，其他工具使用问题目前可以想到的办法是具体问题具体分析，一般能通过手动校准解决。总体来说还是比较麻烦的，平时巡检时做好时钟同步检查就可以最大程度避免了。
1 个赞
学习了
1 个赞
学到了
学习了
也就是说引发业务数据的逻辑错乱问题，可以这样理解把
整个集群以相同的服务器做时钟同步，生产上也只会有很小的机率出现时间调整。
如果时间差异不大，建议用ntp服务慢慢同步时间，不要一次性调整
时间不同步会造成数据传输异常甚至失败
基础监控，都有时间同步偏差的告警。到了数据库层出问题再处理，麻烦多了。如果没有，赶紧加上吧！
我经历过的应该是客户端跟服务器时钟差异落后5分钟，导致监控也落后5分钟。总体感觉是好久才看到测试现象。延迟满足的感觉非常不好。
所以P.S.正义会迟到，但从不缺席，这句话我异常反感。
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。