rocH
2025 年6 月 20 日 17:06
#1
【 使用环境 】生产环境 or 测试环境
[2025-06-20 16:51:05.308116] ERROR issue_dba_error (ob_log.cpp:1875) [37145][LogStreaWorkThr][T0][Y8F5B0A001004-000000000060005C-0-0] [lt=23][errcode=-4388] Unexpected internal error happen, please checkout the internal errcode(errcode=0, file=“ob_log_ls_fetch_stream.cpp”, line_no=1256, info=“fetch log fail on rpc, need_switch_server”)
22[2025-06-20 16:51:05.308125] WDIAG [RPC.FRAME] async_cb (ob_req_transport.cpp:145) [37123][RpcIO][T0][Y0-0000000000000000-0-0] [lt=14][errcode=-4123] process async request fail(r=0x7f563402a448, ret=-4123, pcode=2131)
23[2025-06-20 16:51:05.308135] EDIAG [TLOG.FETCHER] handle_fetch_log_error _ (ob_log_ls_fetch_stream.cpp:1256) [37145][LogStreaWorkThr][T0][Y8F5B0A001004-000000000060005C-0-0] [lt=19][errcode=0] fetch log fail on rpc, need_switch_server(svr_=“xxx.xxx.xxx.xxx:2882”, rcode={code:-4012, msg:"fetch log rpc timeout, svr=“xxx.xxx.xxx.xxx:2882"”, warnings:[]}, fetch_stream=0x7f561de0faa0) BACKTRACE:0x18144980 0x972ba85 0x9873248 0x9872d5b 0x9872c9e 0x9872ac6 0xbff77b8 0xbff16f3 0xbff121e 0xbfea7df 0xbfe9f05 0xc2316f4 0x1846bf9e 0x184760a5 0x184721dd 0x7f5891c6aea5 0x7f5891284b0d
@论坛小助手
3 个赞
论坛小助手
2025 年6 月 20 日 17:08
#3
根据您提供的信息，OMS 构建的增量同步任务中，Store 组件拉取时间一直显示为 1970-01-01 08:00:00，并且任务设置的起始时间为 2025-06-18 09:20:00。此外，日志中出现了错误信息，提示 fetch log rpc timeout 和 need_switch_server。
以下是针对问题的分析和解决建议：
问题分析
Store 组件拉取时间显示为 1970-01-01 08:00:00，通常表示组件未能成功获取到有效的位点信息。
这可能是因为：
源端数据库的增量日志（如归档日志或 redo log）已经过期，无法回溯到指定的时间点。
Store 组件未能正确连接到源端数据库，导致无法获取位点信息。
错误信息 fetch log rpc timeout 和 need_switch_server 表明：
Store 组件在尝试从源端数据库拉取增量日志时超时。
可能需要切换到其他可用的服务器以继续拉取日志。
解决建议
确认源端数据库的增量日志是否覆盖了任务起始时间 2025-06-18 09:20:00。
如果增量日志已过期，请调整任务起始时间为增量日志的有效范围内。
根据文档片段 4 的描述，启动一个新的 Store 回拉数据：
登录 OMS 社区版控制台。
在左侧导航栏，单击 数据迁移 。
找到目标任务并进入详情页面。
单击页面右上角的 查看组件监控 。
找到对应的 Store，复制其 Topic。
根据复制的 Topic，启动新的 Store：
在 OMS 社区版控制台的左侧导航栏，单击 运维监控 > 组件 。
单击页面右上角的 新增 。
配置各项参数，包括 Subtopic、Node 和 Timestamp。
Timestamp ：选择回拉的时间起点，确保该起点覆盖到下游请求的位点。
返回数据迁移任务页面，修改参数：
修改增量数据保留时间参数 store.clearer.outdated，确保数据保留时间能够覆盖到下游请求的位点。
修改完成后，单击 更新 。
根据文档片段 1 的描述，排查 Store 和 Connector 组件的日志：
如果 Store 延迟过大，请查看 Store 组件的日志，排查是否有错误或异常信息。
如果 Store 的位点基本实时，但 Connector 延迟过大，请查看 Connector 组件的日志。
如果以上步骤仍无法解决问题，请将异常现象和组件日志反馈至 OMS 社区版的技术服务人员，由技术服务人员进一步处理。
总结
根据文档库中的信息，建议您按照以下步骤操作：
检查源端数据库的增量日志是否覆盖任务起始时间。
启动一个新的 Store 回拉数据，并调整相关参数。
检查 Store 连接超时时间和网络连接状态。
查看组件日志，定位具体问题。
如果仍有疑问，请提供更多详细信息，我们将进一步协助您解决问题。
具体信息可参考以下文档:
oms_sync_delay 同步任务延迟 设置增量同步位点 全量/增量数据迁移性能调优 Store 没有下游请求位点的数据 更新集群级备份配置 StoreSource 迁移 HBase 数据库的数据至 OBKV 设置 Server 级配置 设置集群级备份配置 查看数据同步任务的详情
2 个赞
可以重新发起一次迁移，并做增量同步，如果还是失败，就按照社区小助手的排错过程，逐个排查！
1 个赞
刘彻
2025 年6 月 23 日 10:26
#6
上述问题一般是oms版本低，自带的cdc库的版本低于ob版号
rocH
2025 年6 月 23 日 11:56
#7
@论坛小助手
论坛小助手
2025 年6 月 23 日 11:57
#8
根据文档库中的信息，OMS 增量拉取日志的速度可能受到多种因素的影响，包括网络带宽、源端数据库的性能、OMS 配置参数等。以下是一些加速增量日志拉取速度的方法：
检查当前带宽使用情况
根据文档片段 3 和 4 的描述，OceanBase 提供了两个配置项用于限制备库与主库之间的日志同步带宽：
standby_fetch_log_bandwidth_limit：集群级总带宽限制。
_server_standby_fetch_log_bandwidth_limit：单个 OBServer 节点的带宽限制。
登录到目标租户的 sys 租户。
执行以下命令查看当前带宽限制：SHOW PARAMETERS LIKE 'standby_fetch_log_bandwidth_limit';
SHOW PARAMETERS LIKE '_server_standby_fetch_log_bandwidth_limit';
如果带宽限制设置过低，可能会导致日志拉取速度无法跑满带宽。
默认值为 0，表示不限制带宽。如果设置了较低的限速值，请适当调高。
调整 OMS 系统参数
根据文档片段 2 的描述，可以通过调整 OMS 社区版的系统参数来优化增量日志拉取速度。以下是关键参数的调整建议：
参数名称：limitator.platform.threads.number
描述：支持并发的线程数。
修改方法：
登录 OMS 社区版控制台。
在左侧导航栏，单击 系统管理 > 系统参数 。
编辑目标参数 migration.checker.params.*（根据迁移任务的档位选择）。
将 limitator.platform.threads.number 的值调大（例如从默认值 16 调整为 32 或更高）。
参数名称：limitator.select.batch.max
描述：每次查询的记录数。
修改方法：
同样在 系统参数 页面编辑目标参数。
将 limitator.select.batch.max 的值调大（例如从默认值 1000 调整为 5000 或更高）。
参数名称：task.checker_jvm_param
描述：Checker 组件的 JVM 参数配置。
修改方法：
编辑目标参数。
增加 JVM 内存分配，例如将 -Xms64g -Xmx64g 调整为更高的值。
优化网络环境
如果网络带宽是瓶颈，可以考虑以下优化措施：
确保源端和目标端之间的网络延迟较低。
使用更高带宽的网络链路。
如果跨地域部署，可以考虑使用专线或优化路由。
监控日志拉取状态
根据文档片段 1 的描述，您可以在 OMS 社区版的 同步增量日志拉取 页面查看日志拉取的状态、启动时间、结束时间、总计耗时和进度。通过这些指标，您可以进一步分析是否存在其他瓶颈。
联系技术支持
如果经过以上调整后，日志拉取速度仍然无法满足需求，请提供更多详细信息（如当前配置参数、网络带宽、日志拉取速度等），并将问题反馈至 OMS 社区版的技术支持团队以获取进一步帮助。
根据文档库中的信息，建议您按照以下步骤操作：
检查并调整 standby_fetch_log_bandwidth_limit 和 _server_standby_fetch_log_bandwidth_limit 的带宽限制。
调整 OMS 社区版的系统参数，包括并发线程数、每次查询的数据量和 JVM 内存配置。
优化网络环境，确保带宽充足且延迟较低。
监控日志拉取状态，分析是否存在其他潜在瓶颈。
如果仍有疑问，请提供更多详细信息，我们将进一步协助您解决问题。
更多信息请查看:
查看数据同步任务的详情 如何处理因存在 LOB 字段导致全量迁移失败的问题 设置日志同步限速 内存和磁盘要求 迁移 HBase 数据库的数据至 OBKV ODP 性能分析 OMS 社区版错误码 如何处理 Failed to fetch 报错
(小助手的答复已结束，如未能解决您的问题，请继续提问并等待其他同学的回复，谢谢！)
论坛小助手
2025 年6 月 23 日 11:57
#9
根据文档库中的信息，以下是一些可能的解决方案来加速 OMS 增量日志拉取速度：
检查并调整带宽限制配置
根据文档片段 1 的信息，OceanBase 数据库提供了两个配置项用于控制备库的日志同步带宽：
standby_fetch_log_bandwidth_limit：设置整个集群可用于日志同步的总带宽。
_server_standby_fetch_log_bandwidth_limit：设置单个 OBServer 节点可用于日志同步的带宽。
如果当前带宽限制较低，可以尝试提高这些配置项的值。例如：
ALTER SYSTEM SET standby_fetch_log_bandwidth_limit = '100M';
ALTER SYSTEM SET _server_standby_fetch_log_bandwidth_limit = '50M' SERVER = 'xx.xx.xx.xx:17854';
确保源端数据库配置正确
根据文档片段 6 的信息，在使用 OMS 社区版迁移 MySQL 数据库的增量数据前，需要确保在 MySQL 数据库中开启了 Binlog。此外，还需要检查 MySQL 数据库的 Binlog 配置是否正确，以保证增量数据能够被正常拉取。
优化 OMS 组件资源分配
根据文档片段 10 的信息，OMS 社区版各组件的标准资源规格建议如下：
资源类型/组件
Store
Incr-Sync
Full-Import
总计
CPU
4C
2C
2C
8C
Memory
8G
8G
4G
20G
Disk
取决于数据库端增量日志的生产速度和 OMS 社区版中增量数据的保存时间
5G
5G
>10G
确保为 OMS 各组件分配了足够的资源，特别是 Store 组件，它负责增量日志的拉取。如果当前资源不足，可以尝试增加资源分配。
检查网络状况
确保源端数据库与 OMS 之间的网络连接稳定且延迟较低。如果网络状况不佳，可能会导致增量日志拉取速度受限。可以通过网络监控工具检查网络状况，并尝试优化网络配置。
查看日志排查问题
根据文档片段 8 的信息，如果遇到故障或延时较高的情况，可以通过查看指定机器组件的日志来排查和定位问题。OceanBase 迁移服务（OMS）社区版提供安全快捷的日志查看方式，无需登录到指定机器，支持白屏查看机器日志。通过分析日志，找出可能导致增量日志拉取速度受限的原因，并采取相应措施解决。
综上所述，您可以从以下几个方面入手来加速 OMS 增量日志拉取速度：检查并调整带宽限制配置、确保源端数据库配置正确、优化 OMS 组件资源分配、检查网络状况以及查看日志排查问题。如果以上方法仍无法解决问题，建议联系 OceanBase 的人工答疑以获取更多帮助。
检索到的文档如下:
设置日志同步限速 内存和磁盘要求 迁移 HBase 数据库的数据至 OBKV 手动收集统计信息 通过 OMS 进行数据迁移和同步 为 MySQL 数据库开启 Binlog Coordinator（框架层） 查看机器日志
