【 使用环境 】测试环境
【 OB or 其他组件 】OB
【 使用版本 】4.2
【问题描述】业务系统和OB合设在一台服务器上，因技术人员调整服务器时间，误把今天的时间调整到下个月，此时发现问题后将时间再改回后，发现OB运行异常。
请问是否有办法解决，查看前期4.0有此问题，现在4.2版本是否有规避办法？
2 个赞
可以看一下这个帖子。改时区这个操作影响非常大，OB部署完成后通常不会修改的。时间可以向前变快，向后不行。
你把今天时间调到下个月是可以的，但是把时间回退肯定会出问题
OceanBaseV4.0.0 系统时间变更问题1658mh3_gaODE3NDYwNDc5LjE3MjU0MTQ3MzI._ga_T35KTM57DZ*MTczMjI2NTY1MS4yODMuMS4xNzMyMjY2Nzk2LjE4LjAuMA…
2 个赞
你好可以帖一下相关连接和ob报错么
需要确认下向后调一个月时候ob数据库当时是否处于关闭状态
当时处于运行状态，因为我们是一个产品，不是纯数据库运营，那产品的话必然会涉及到新上线的时候改时间的问题，改时间就会涉及误操作，这个概率性也太大了。
往后调一个月这需要重新搭建了，相当于ob的SCN号后调一个月，时间再调回去，但SCN是无法回调。
ob是分布式集群，一致性数据需要SCN 对时钟同步很敏感
也就是说如果是产品化的东西，不太适合使用OB数据库了？然后MYSQL就没有这个问题。还是有其他方案，单产品只必须要集成一种数据库
目前暂时不行，这种需求在明年会做出来，425bp2之后的版本可以
解决方案
- 重启OceanBase服务：
- 重启OceanBase服务可以重新初始化数据库的时间戳，通常能够解决因时间调整导致的问题。
- 可以使用
obd cluster restart <cluster_name>命令来重启整个集群。
- 检查日志文件：
- 使用
obdiag工具收集诊断信息，特别是关注observer.log文件，查找与时间相关的错误信息，以便进一步分析问题原因。
- 验证系统时间同步：
- 确保服务器的时间同步服务（如NTP）正常工作，避免再次发生时间突变的情况。
- 配置NTP服务：
- 在所有运行OceanBase的服务器上配置NTP服务，确保系统时间始终与标准时间保持同步。
- 限制非授权时间调整：
- 通过操作系统权限管理，限制非授权用户对系统时间的修改权限，减少意外调整时间的风险。
OceanBase 4.2版本的规避办法
- 增强时间校验机制：OceanBase 4.2版本可能在内部增强了时间校验机制，以减少因系统时间突变导致的问题。但具体是否有针对性的改进或修复，需要查阅OceanBase 4.2版本的官方文档或更新日志。
- 最佳实践：遵循OceanBase的最佳实践，不要在运行OceanBase的服务器上随意调整系统时间。如果确实需要调整时间，请确保在调整前已经备份了数据库，并且了解可能带来的风险。
你好，麻烦提供一下observer日志