OMS迁移MySQL ，报 binlog 找不到

OceanBase 技术问题
#1

【 使用环境 】生产环境
【 OB or 其他组件 】OMS
【 使用版本 】版本号: 4.2.7_CE
【问题描述】 oms 全量+增量迁移MySQL数据
【复现路径】 报找不到日志 mysql-bin.022246
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)

【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！

错误码：
STORE-MYSQL-MODEL-EXTRA-000106
等级：
FATAL
错误信息：
定位 binlog 拉取起点失败
错误原因：
定位 binlog 拉取起点失败，错误信息： Error occurred while seeking start timestamp in binlog file: mysql-bin.022246，原因：Error occurred while seeking start timestamp in binlog file: mysql-bin.022246
解决方案：
请根据错误信息自行排查原因。如果无法解决，请联系 OMS 技术支持人员。

我想知道 mysql-bin.022246 这个信息 是从哪里获取的？我这个链路是新建的

#3

根据文档库中的信息，OMS 社区版会基于全量迁移任务，读取 MySQL 数据库的 Binlog，实时同步增量数据至目标端。使用 OMS 社区版迁移 MySQL 数据库的增量数据前，请先在 MySQL 数据库中开启 Binlog。如果在预检查环节遇到相关报错，您需要确保 MySQL 的 Binlog 已正确开启和配置（来源：OMS 社区版 MySQL Binlog 开启）。

针对您的问题，mysql-bin.022246 是 MySQL 生成的二进制日志文件名的一部分，OMS 在进行增量数据迁移时会依赖这些 binlog 文件来获取自全量迁移之后的数据变更。当 OMS 报告找不到特定的 binlog 文件（如 mysql-bin.022246），这通常意味着以下几种情况之一：

  1. MySQL 没有正确配置 binlog：

    • 确认 MySQL 是否已经开启了 binlog 功能，并且设置了合适的过期时间以保留足够长的历史记录。
    • 可以通过查询 MySQL 的系统变量 show variables like 'log_bin'; 来确认是否启用了 binlog。
    • 如果没有启用，请按照官方文档指导开启 binlog 并重启 MySQL 服务。

  2. Binlog 文件已被清理：

    • 如果 MySQL 的 binlog 过期策略设置得太短，可能会导致旧的 binlog 文件被删除，从而使得 OMS 无法找到指定的 binlog 文件。
    • 您可以检查 MySQL 的 binlog 过期天数设置 (expire_logs_days)，并适当延长该值以确保 binlog 文件不会过早被清除。

  3. Binlog 文件路径或权限问题：

    • 确保 OMS 能够访问到 MySQL 的 binlog 文件所在目录，并且具有读取权限。
    • 检查 MySQL 配置文件中关于 binlog 文件存储位置的设置 (log_bin_basename)，保证与实际路径一致。

  4. 新建链路时的起点选择问题：

    • 对于新建的数据迁移链路，OMS 需要确定一个合适的 binlog 文件作为增量同步的起点。
    • 如果是在创建新任务时首次尝试连接 MySQL，则可能是因为 MySQL 当前可用的最早 binlog 文件编号比 mysql-bin.022246 更大，或者根本不存在这个编号的文件。
    • 建议您查看 MySQL 当前最新的 binlog 文件编号，可以通过命令 show master logs; 获取当前所有 binlog 文件列表，然后对比 OMS 报告的缺失文件编号。

综上所述，为了进一步排查问题，请首先确认 MySQL 的 binlog 是否已正确配置并且存在相应的 binlog 文件。如果仍然无法解决问题，建议收集更多诊断信息，例如使用 obdiag 工具收集 MySQL 和 OMS 的日志，以便更深入地分析问题原因。同时也可以联系 OMS 技术支持人员获取专业帮助。

详情请参考:

  1. 为 MySQL 数据库开启 Binlog
  2. 如何处理 Failed to fetch 报错
  3. OMS 社区版错误码
  4. 迁移 MySQL 数据库的数据至 OceanBase 社区版
  5. OMS 社区版问题排查手册
  6. 新建 MySQL 数据源
  7. 系统和网络要求
#4

oms组件监控查看一下

#5 
2025-03-03 17:41:29 [NOTICE] [StoreCommandsProcessor.cpp:112 746746,427804416] Request params: content = {"level":"FATAL","gmt":1740994889,"code":"113","message":"An error occurred on the MySQL server.","reason":"The following error occurred within the MySQL server. Error code: 1236. Error message: ErrPacket{code=1236, sqlState='HY000', msg='Could not open log file'}. Cause: Maybe the failure was caused by the specify binlog file, position or GTID does not exist.","proposal":"Contact OMS Technical Support.","context":{"errorCode":"1236","cause":" Cause: Maybe the failure was caused by the specify binlog file, position or GTID does not exist.","errorMsg":"ErrPacket{code=1236, sqlState='HY000', msg='Could not open log file'}"},"extraContext":{}}
215
2025-03-03 17:41:29 [NOTICE] [StoreCommandsProcessor.cpp:107 746746,1115674368] Get Request POST /error/report HTTP/1.1
216
2025-03-03 17:41:29 [NOTICE] [StoreCommandsProcessor.cpp:112 746746,1115674368] Request params: content = {"level":"FATAL","gmt":1740994889,"code":"106","message":"Failed to locate the start point for pulling binlogs.","reason":"Failed to locate the start point for pulling binlogs. Error message: Error occurred while seeking start timestamp in binlog file: mysql-bin.022246. Cause: Error occurred while seeking start timestamp in binlog file: mysql-bin.022246.","proposal":"Perform troubleshooting based on the error message. If the fault persists, contact OMS Technical Support.","context":{"errorCause":"Error occurred while seeking start timestamp in binlog file: mysql-bin.022246","errorMsg":"Error occurred while seeking start timestamp in binlog file: mysql-bin.022246"},"extraContext":{}}
217
2025-03-03 17:41:30 [ERROR] [deliver2store.cpp:383 746746,754947840] sub reader is exited, we should terminate
218
2025-03-03 17:41:30 [NOTICE] [deliver2store.cpp:201 746746,788518656] deliver2store cleanupDrcPack() called
219
2025-03-03 17:41:30 [NOTICE] [deliver2store.cpp:175 746746,788518656] deliver2store cleanupModule() called
220
2025-03-03 17:41:30 [NOTICE] [deliver2store.cpp:185 746746,788518656] after deliver2store cleanupModule() called
#6

根据您提供的日志信息，OMS 在尝试从 MySQL 拉取 binlog 时遇到了错误。具体来说，OMS 报告了两个关键问题：

  1. MySQL 服务器内部错误：

    • 错误代码：1236
    • 错误信息：Could not open log file
    • 原因：可能是指定的 binlog 文件、位置或 GTID 不存在。

  2. 无法定位 binlog 拉取起点：

    • 错误信息：Failed to locate the start point for pulling binlogs
    • 具体错误：Error occurred while seeking start timestamp in binlog file: mysql-bin.022246

分析与解决方案

1. 确认 MySQL Binlog 配置

确保 MySQL 已正确配置并启用了 binlog 功能。可以通过以下命令检查：

SHOW VARIABLES LIKE 'log_bin';

如果 log_bin 的值为 OFF，则需要在 MySQL 配置文件中启用 binlog 并重启 MySQL 服务。例如，在 my.cnf 或 my.ini 中添加或修改以下配置：

[mysqld]
log_bin = /path/to/binlog/mysql-bin
expire_logs_days = 7  # 根据需要调整过期天数
server_id = 1         # 必须唯一
binlog_format = ROW   # 推荐使用 ROW 格式

2. 检查 Binlog 文件是否存在

确认 MySQL 当前可用的 binlog 文件列表，并检查是否包含 mysql-bin.022246 文件。可以使用以下命令查看当前所有 binlog 文件：

SHOW MASTER LOGS;

如果 mysql-bin.022246 文件不存在，可能是因为它已经被清理或从未生成。您可以查看最新的 binlog 文件编号，并确保 OMS 使用的是一个存在的 binlog 文件作为增量同步的起点。

3. 调整 Binlog 过期策略

如果 MySQL 的 binlog 过期策略设置得太短，可能会导致旧的 binlog 文件被删除。建议适当延长 expire_logs_days 的值以确保 binlog 文件不会过早被清除。例如：

expire_logs_days = 14  # 保留 14 天的 binlog 文件

4. 确认 Binlog 文件路径和权限

确保 OMS 能够访问到 MySQL 的 binlog 文件所在目录，并且具有读取权限。检查 MySQL 配置文件中关于 binlog 文件存储位置的设置 (log_bin_basename)，保证与实际路径一致。

5. 新建链路时的起点选择

对于新建的数据迁移链路，OMS 需要确定一个合适的 binlog 文件作为增量同步的起点。如果是在创建新任务时首次尝试连接 MySQL，则可能是因为 MySQL 当前可用的最早 binlog 文件编号比 mysql-bin.022246 更大，或者根本不存在这个编号的文件。建议您：

  • 查看 MySQL 当前最新的 binlog 文件编号。
  • 在 OMS 中重新配置增量同步的起点，确保使用一个存在的 binlog 文件。

6. 检查 MySQL 服务器状态

确保 MySQL 服务器正常运行，没有其他潜在问题影响 binlog 文件的访问。可以尝试重启 MySQL 服务并观察是否有新的 binlog 文件生成。

总结

为了进一步排查和解决问题，请按照上述步骤逐一检查 MySQL 的 binlog 配置、文件存在性、过期策略、路径权限以及 OMS 的增量同步起点配置。如果仍然无法解决问题，建议收集更多诊断信息（如使用 obdiag 工具）并联系 OMS 技术支持人员获取专业帮助。

希望这些信息能帮助您解决遇到的问题。如果有任何进一步的问题或需要更多帮助，请随时告知。

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

  1. 查看数据迁移任务的详情
  2. OBKV-Table 常见问题
  3. Switchover
  4. oceanbase.CDB_OB_IMPORT_TABLE_JOBS

(小助手的答复已结束，如未能解决您的问题，请继续提问并等待其他同学的回复，谢谢！)

#7

根据任务配置的增量开始时间去源端获取的。
看看源端MySQL里面是不是这个日志已经不存在了？

#8

SHOW BINARY LOGS
看一下
mysql-bin.022246 文件应该在列表中，是否是自己清理过binlog文件了

#9

是不存在了，这个binlog文件是过期的

#10

是的，过期的binlog文件

#11

全量迁移也要扫描 过期的binlog 吗

#12

你说的是 全量+增量迁移 呢，如果不要增量去掉重试下。

#14

没有增量迁移，所以很奇怪

#15

选了全量+增量，全量启动前会先启动增量store组件。

1 个赞
#16

嗯嗯，没选增量迁移也会启动store组件是吗?

#17

没选择增量迁移不会起store，你这个链路选增量了没

#19

了解了，链路只要有增量迁移就会启动store组件，目前迁移任务已经换datax迁移

#20

请教一下，我们的binlog已经是过期的(几个小时之前的)，store组件还会抓这个binlog，这个组件抓取binlog的时间范围有说明吗

#22

show binary logs 程序会遍历这些日志文件，目的是找到位点，如果是自己删除了binlog，不是使用mysql工具删除，就会出现这种情况。

1 个赞
#23

嗯嗯，这种遍历日志能理解，但是遍历之前过期很久的日志感觉没有必要，这个建议在后续版本可以考虑改进一下

#24

store通过show binary logs 查询binlog文件，遍历寻找位点的。这个情况应该不是store去遍历过期的日志，可能是binlog被手动删除了但mysql未更新binlog列表，store获取到了被删除的binlog导致报错。