OMS同步时Incr-Sync延时一直在增长

不会写SQL · 2024 年8 月 12 日 18:21

【使用环境】测试环境
【 OB or 其他组件】OMS
【使用版本】feature_4.2.3_ce
【问题描述】同步上游为OceanBase4.3.1，同步下游为5.7。之前同步正常，但是周末的时候OMS服务器磁盘空间满导致同步停止，在启动过程中修改过一次同步位置点，启动完成后，Store和Incr-Sync都是启动成功，其中Store组件的延时为1，当前位置点持续更新。但是Incr-Sync组件的延时很大且一直在增加，位点一直没有变化，如图：

Incr-Sync组件的日志如下：
connector.log (110.6 KB)

【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)
【备注】基于开源文档检索的论坛助手开放试用！如需论坛小助手参与答复，请输入 [@论坛小助手]

论坛小助手 · 2024 年8 月 12 日 18:22

根据您的描述，您遇到了OMS在同步OceanBase到MySQL的过程中，Incr-Sync组件的延时持续增加且位点未发生变化的问题。这个问题可能与数据同步过程中的网络状况、数据量大小、同步配置或是源端与目标端的状态有关。

虽然obdiag当前没有直接针对OMS同步问题的日志采集或根因分析场景，但是我们可以从集群基础信息和潜在的性能瓶颈方面入手进行排查。首先，我们可以通过采集集群的基础信息来了解整体环境的状态，其次可以关注是否有CPU或IO方面的性能问题，因为这些问题都可能导致数据同步延迟。

日志采集场景: 集群基础信息

日志采集命令:

obdiag gather scene run --scene=observer.base

这个命令会帮助我们收集集群的基本配置和状态信息，这对于理解整个集群的运行环境非常有帮助。

日志采集场景: CPU高

日志采集命令:

obdiag gather scene run --scene=observer.cpu_high

这个命令可以帮助我们判断是否由于CPU使用率过高导致的数据同步延迟。

日志采集场景: IO问题

日志采集命令:

obdiag gather scene run --scene=observer.io

这个命令可以帮助我们检查是否有IO性能瓶颈影响了数据同步的速度。

接下来，请您执行上述命令并将生成的日志文件发送给我们，以便我们进一步分析问题的原因。

为了更准确地定位问题，请您提供以下信息：

同步任务的具体配置：例如同步频率、同步的数据表大小等。
源端OceanBase和目标端MySQL的版本信息：这有助于我们了解是否存在兼容性问题。
网络状况：同步过程中是否有网络抖动或丢包的情况？
同步任务的日志：OMS同步任务的日志中是否有任何错误或警告信息？
最近是否有对同步配置或数据库进行过变更：例如增加了新的同步任务或是调整了同步策略等？

具体信息可参考以下文档:

OceanBase 迁移服务（OMS）

附上敏捷诊断工具 obdiag 使用帮助链接

淇铭 · 2024 年8 月 13 日 10:27

查一下组件监控截个图看一下你这个是商业版还是社区版

不会写SQL · 2024 年8 月 14 日 10:07

社区版

论坛小助手 · 2024 年8 月 14 日 10:12

再向您确认几个问题:

同步任务的具体配置是什么例如同步频率同步的数据表大小等
源端OceanBase和目标端MySQL的确切版本信息是什么
同步过程中是否有网络抖动或丢包的情况
最近是否有对同步配置或数据库进行过变更例如增加了新的同步任务或是调整了同步策略等

不会写SQL · 2024 年8 月 14 日 10:13

现在报这个错，我应该怎么修改同步的时间点？

论坛小助手 · 2024 年8 月 14 日 10:14

根据您提供的信息，您在尝试同步时遇到了一个错误，错误信息显示为找不到可行的存储（com.oceanbase.oms.store.client.HttpBadResponseException: CmBaseException(oldErrorCode=0, errMsg=Found no feasible stores for name [OB_MYSQL_CE_np_Sw2mqna171fk_reverse_Sw8uu3xajjr4-1-0] and checkpoint [1723272534], data range available: from [1723511990] to [1723601402], reason=null, relativeDocs=null)）。这通常意味着OMS在尝试从指定的检查点（checkpoint）开始同步数据时，未能找到有效的存储位置。

解决方案：

检查同步任务的状态：确保同步任务没有被意外中断或停止，并且同步任务的配置正确无误。
检查源端和目标端的版本兼容性：确认源端OceanBase和目标端MySQL的版本是否兼容。
检查同步任务的配置：确认同步任务的配置是否正确，特别是关于同步时间点的设置。
重新设置同步时间点：如果上述步骤均未解决问题，您可以尝试重新设置同步时间点。通常，您可以通过OMS的管理界面或者命令行工具来重置同步时间点。

重置同步时间点的方法：

通过OMS管理界面：如果您使用的是OMS的图形化界面，可以在相应的同步任务页面中找到重置同步时间点的选项。
通过命令行工具：如果您使用的是命令行工具，可以使用类似于以下命令来重置同步时间点：
```
obmsctl reset-sync-position <任务ID> <新的时间点>
```
具体的命令格式和参数请参照OMS的官方文档。