【 使用环境 】测试环境
【 OB or 其他组件 】OB
【 使用版本 】4.2.0
【问题描述】系统时间跳动会影响ob服务，通过调整时间可以恢复。是否有办法判定时间是快了还是慢了。有一种场景是环境部署的时候时间就是错的，所以没法和标准时间做对比，这个情况下如果时间出现跳动是不知道对比开始的时间是快了还是慢了，是否有办法了解到这个时间差异
部署前服务器初始化有要求做时间同步，建议按部署要求步骤进行，可避免该问题出现。
https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000000220855
如果已经发生了，且时间差超过1小时，修正时间后可能出现重启不起来。
此类情况通常需要查看observer.log日志，会有类似如下报错信息，即原集群跳变前的时间。可调整时间到该时间附近（1小时内），集群启动后需要等待clog同步和校验完成后会正常启动。
[2023-03-23 11:39:41.968642] WARN [PALF] submit_log (palf_handle_impl.cpp:369) [216213][T1_FreInfoReloa][T1][YB42C0A8190A-0005F788B2BC4283-0-0] [lt=10] invalid argument(ret=-4002, palf_id=1, buf=0x7f67223fef30, buf_len=40, ref_ts_ns=1679566314222771244)
obclient [oceanbase]> select usec_to_time(1679566314222771244/1000);
+----------------------------------------+
| usec_to_time(1679566314222771244/1000) |
+----------------------------------------+
| 2023-03-23 18:11:54.222771 |
+----------------------------------------+
1 row in set (0.003 sec)
同时建议按要求部署，或者使用OCP运维平台，会对节点进行监控，同时也会有相关告警提醒，降低运维难度。
现在可以了吗，等clog同步追上，且节点之间延迟小于2s以内，应该就正常使用了。
这个倒是没有观察，我现在是担心出现时间跳动的问题影响服务所以在测试。我们有的环境这个时间不太可控，所以是在找出现后的解决办法，目前来说出现时间跳动之后把时间调回去服务就正常了，但是这个跳动的差异如果系统日志拿不到就没办法了，所以想着是否能在ob的服务上找到解决办法。
OB对时间延迟比较敏感，服务器时间不可控，可以做服务器时钟同步。OceanBase分布式数据库-海量数据 笔笔算数
正常情况下 多节点集群，有某个节点时差大于2s，会拉黑隔离这个节点，保证整个集群的可用性。
有的环境时钟同步也没有，所以比较关心恢复这块。目前看就是2种情况
- 服务安装时候的时间不确定，不能和基准时间做对比。这个情况下由于人为或是其它原因造成系统时间跳动的话，有办法找到跳动的时差么，ob层面。
- 服务没有做同步，某些节点运行一段时间后时间慢于其它节点。这个情况下是如何处理啊。
1）使用OBD或者OCP部署OB时是有时钟检查的，能保证部署阶段做拦截。
2）如果没做过ntp这种同步，部署时时间正常也是可以部署上的，后续出现时间不一致，OCP服务会有服务器时差检查，能在集群出问题之前发现时差达到阀值的告警。
我们是容器化部署的，有些客观原因没办法保证时间一定一直同步的。所以在找出现问题后的兜底办法来着。
是直接使用docker 还是k8s+ob-operator呢？
直接docker部署我们暂未承诺可上生产，目前容器化可上生产的方案是k8s+ob-operator。也会提供白屏运维操作，不过暂时没接入告警功能，后续应该会排进去。
k8s+ob-operator的方案，我们没办法强制要求环境配置ntp来着，并且也无法避免不出现人为调时间的情况。所以想着就算出现的这个问题我们有办法恢复服务。