【 使用环境 】测试环境
【 OB】
【 使用版本 】4.2.1.4
【问题描述】
1、架构：1-1-1
zone1:10.186.64.161 --》（RS Leader）
zone2:10.186.64.162
zone3:10.186.64.163
时钟源：10.186.64.160 （即，OCP节点）
2、问题描述：手动将RS Leader 和 业务租户Leader节点 （同一个节点）的系统时间调慢80s，进行写入数据的测试和集群状态观察，发现集群存在84s的读写异常，然后集群自动恢复正常（全程没有干预使其恢复时间同步，即RS Leader节点一直比标准时间落后80s），全程操作记录在文档《OB4.X-RS Leader节点时钟延迟（落后）80s测试》。
3、 查看rootservice.log存在错误码
-4638 ：RS切主或RS服务重启中
-4038 ：无主
4、问题：
4.1 根据官网资料：OceanBase分布式数据库-海量数据 笔笔算数
如果您计划部署分布式 OceanBase 集群，需要保证集群内各机器的时间同步，否则集群无法启动，服务在运行时也会出现异常。OceanBase 集群允许的时钟偏差不能超过 2s。当超过 2s 时，会出现无主情况。恢复时钟同步后，重启 OceanBase 集群，可以恢复正常。
4.2 实际测试结果：即使leader节点比标准时间和其他节点落后80s，集群发生84s的读写异常之后，自动恢复正常（全程没有干预使其恢复时间同步，即RS Leader节点一直比标准时间落后80s），表现是否符合预期？
4.3 RS Leader 或普通租户Leader 好像没有切到其他节点，查看选举记录最终还是另外2个时间正常的节点投票给了时间落后80s的节点 10.186.64.161 ，此处表现是否符合预期？具体依据是什么呢？
【复现路径】
详细步骤见附件 《OB4.X-RS Leader节点时钟延迟（落后）80s测试》
1.持续往业务租户mysql_ob插入数据
2.将RS Leader节点操作系统时间直接调慢80s
3.观察集群状态和插入数据的状态，业务租户写入存在约84s失败，select失败
4.集群恢复正常，租户可读写