oms全量校验报错

OceanBase 技术问题
#1

【 使用环境 】生产环境
【 OB or 其他组件 】OMS
【 使用版本 】4.2.8_CE
【问题描述】
全量校验，校验不通过。如图。

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

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

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

微信截图_20250619153304
微信截图_202506191533041092×543 80 KB

1 个赞
#3

根据您提供的信息和文档库中的内容，以下是对 OMS 全量校验报错问题的分析与解决建议：

1. 问题分析

从您上传的图片和 OCR 提取的内容来看，OMS 在执行全量校验时出现了不通过的情况。具体表现为某些表的数据差异较大（如 mitatortable.diffmax），并且可能存在数据行数或值的不一致。

结合文档片段 3 和文档片段 7 的内容，OMS 社区版在发生报错时，需要按照以下步骤进行排查：

  • 确认是否存在因官网文档中提到的使用限制导致的异常。
  • 检查源端和目标端的基本信息及用户权限是否正确。
  • 查看任务配置是否有误。

此外，文档片段 2 提到，对于处于已进入全量校验阶段但未执行成功的任务，可以尝试 批量跳过全量校验 操作。但这仅适用于部分场景，且需要谨慎操作。

2. 解决步骤

步骤 1：检查任务配置

  • 登录 OMS 社区版控制台，进入 迁移任务列表 页面。
  • 找到报错的任务，检查其配置是否正确，包括：
    • 源端和目标端的连接信息（IP、端口、用户名、密码等）。
    • 数据库和表的映射关系。
    • 用户权限是否足够（例如，是否具有 SELECT、INSERT、UPDATE 等权限）。

步骤 2：查看日志

  • 使用 OceanBase 的诊断工具 obdiag 收集诊断信息，具体命令如下：
    obdiag collect log --start-time "YYYY-MM-DD HH:MM:SS" --end-time "YYYY-MM-DD HH:MM:SS" -o /path/to/output
    替换 YYYY-MM-DD HH:MM:SS 为任务运行的时间范围，并将输出路径替换为实际路径。
  • 分析日志文件，查找具体的错误原因。重点关注以下关键词：
    • datacore
    • mitatortable.diffmax
    • diff max

步骤 3：排查数据差异

根据 OCR 提取的内容，mitatortable 表存在较大的数据差异。可以通过以下 SQL 查询进一步确认：

-- 比较源端和目标端的数据行数
SELECT COUNT(*) FROM source_database.mitatortable;
SELECT COUNT(*) FROM target_database.mitatortable;

-- 比较关键字段的值
SELECT column_name, COUNT(*)
FROM source_database.mitatortable
GROUP BY column_name
ORDER BY COUNT(*) DESC;

SELECT column_name, COUNT(*)
FROM target_database.mitatortable
GROUP BY column_name
ORDER BY COUNT(*) DESC;

如果发现数据确实不一致，可能的原因包括：

  • 源端和目标端的数据同步中断。
  • 数据类型或格式不匹配。

步骤 4：尝试跳过全量校验

如果确认数据差异不影响业务逻辑，可以尝试跳过全量校验：

  1. 在 迁移任务列表 页面，选择需要跳过的任务。
  2. 单击页面下方的 更多批量操作 > 批量跳过全量校验。
  3. 在弹出对话框中，单击 确定。
  4. 等待操作完成，并检查任务状态。

注意：跳过全量校验可能会导致数据一致性问题，请务必确认差异对业务无影响后再执行此操作。

3. 后续建议

  • 如果问题仍未解决，建议联系 OceanBase 的技术支持团队，提供以下信息：
    • OMS 版本（当前为 4.2.8_CE）。
    • 迁移任务的详细配置。
    • 使用 obdiag 收集的日志文件。
  • 定期检查 OMS 的更新版本，确保使用的是最新稳定版本。

4. 总结

根据文档库中的信息，OMS 全量校验报错通常由任务配置错误、数据差异或权限问题引起。建议按照上述步骤逐一排查，并根据实际情况决定是否跳过全量校验。如果仍有疑问，请提供更多详细信息以便进一步分析。

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

  1. 如何处理 Failed to fetch 报错
  2. 批量操作数据迁移任务
  3. OMS 社区版问题排查手册
  4. 更新 Full-Verification 组件
  5. 更新 Full-Import 组件
  6. OMS 社区版错误码
  7. 如何处理用户密码被锁定的问题
  8. JDBC-Sink
#4

可以检查一下 看看那些数据不一致

image
image739×97 11.2 KB

#5

你那是不一致的太多了，超过参数设置的不一致的值了
解决办法，更改OMS的参数，改大，太多不一样的话，还是处理数据吧

#6

已经找到在Full-Verification里面对应参数修改成100000.

当前场景是tidb 4.0.15 同步到 ob 4.3.5.1。oms版本是4.2.8_CE。未使用cdc-kafka方式进行增量同步。

表大概600个左右。
数据总行数在200亿左右.
目前遇到问题如下。
1.全量迁移完成后存在大量不一致。
（疑问：全量迁移是有依据数据快照吗？全量迁移完成后如何接上增量同步）
2.大量不一致的情况下，需要大量表进行订正。是否有批量订正功能。
3.store组件，会偶尔出现延迟情况，需要重启才能再进行拉取同步

#7

根据您提供的信息和文档库中的内容，以下是对问题的详细分析与解答：

问题 1：全量迁移是否有依据数据快照？全量迁移完成后如何接上增量同步？

解答

  1. 全量迁移是否基于数据快照？

    • 是的，OMS 社区版在执行全量迁移时，默认会基于源端数据库的某个时间点创建快照。对于 TiDB 数据库，OMS 使用的是 TiDB 的内部机制（如 tidb_snapshot）来确保全量迁移过程中读取的数据是一致的。
    • 具体来说，OMS 在任务启动时会记录一个时间点，并在此时间点之后开始拉取全量数据。

  2. 全量迁移完成后如何接上增量同步？

    • 全量迁移完成后，OMS 会自动切换到增量同步阶段。此时，增量同步组件（Incr-Sync）会从全量迁移结束的时间点开始拉取 binlog 或变更日志。
    • 如果未使用 TiCDC-Kafka 方式进行增量同步，则 OMS 会直接通过 TiDB 的 binlog 功能获取增量数据。
    • 注意事项：
      • 确保 TiDB 的 binlog 功能已开启，并且保留时间足够长以覆盖全量迁移的时间范围。
      • 如果全量迁移耗时较长，可能会导致增量同步无法接上，需要重新调整任务配置或优化全量迁移性能。

问题 2：大量不一致的情况下，是否有批量订正功能？

解答

  1. OMS 是否支持批量订正功能？

    • 根据文档片段 9 的描述，OMS 社区版支持更新 Full-Import 组件的配置，但并未明确提到批量订正功能。
    • 不过，您可以尝试以下方法实现批量订正：
      • 手动调整 Full-Verification 参数：将 Full-Verification 的校验阈值调高（如您提到的修改为 100000），以减少校验失败的任务数量。
      • 跳过全量校验：如果确认数据差异不影响业务逻辑，可以参考文档片段 9 的建议，批量跳过全量校验。

  2. 具体操作步骤：

    • 登录 OMS 控制台，进入迁移任务列表页面。
    • 找到需要订正的任务，选择 更多批量操作 > 批量跳过全量校验。
    • 单击 确定，等待操作完成。

  3. 后续处理：

    • 如果数据一致性要求较高，建议对校验失败的表单独进行订正。可以通过以下 SQL 查询定位差异数据：
      -- 比较源端和目标端的数据行数
SELECT COUNT(*) FROM source_database.table_name;
SELECT COUNT(*) FROM target_database.table_name;

-- 比较关键字段的值
SELECT column_name, COUNT(*)
FROM source_database.table_name
GROUP BY column_name
ORDER BY COUNT(*) DESC;

SELECT column_name, COUNT(*)
FROM target_database.table_name
GROUP BY column_name
ORDER BY COUNT(*) DESC;

问题 3：Store 组件偶尔出现延迟情况，需要重启才能再进行拉取同步

解答

  1. 可能原因：

    • 根据文档片段 8 的描述，节点之间的时钟不同步可能导致增量同步的延迟时间不准确。
    • 此外，TiDB 的 binlog 功能可能存在延迟，或者 Store 组件的资源不足（如 CPU、内存等）。

  2. 解决方法：

    • 检查时钟同步：

      • 确保所有参与迁移的节点（包括 TiDB 和 OB 集群）的时钟保持一致。
      • 可以通过以下命令检查时钟偏差：
        ntpstat
        如果发现时钟偏差较大，可以使用 ntpdate 或 chrony 进行同步。

    • 优化 Store 组件性能：

      • 根据文档片段 2 的建议，调整 Store 组件的并发度和 JVM 内存参数：
        • 并发度：设置 source.workerNum 和 sink.workerNum，通常与机器 CPU 核数相关。
        • JVM 内存：调整 coordinator.connectorJvmParam 参数，例如：
          coordinator.connectorJvmParam=-Xms8g -Xmx8g -Xmn4g
      • 增加每个分片的记录数：调整 source.sliceBatchSize 参数，例如：
        source.sliceBatchSize=10000

    • 监控资源使用情况：

      • 使用 OCP 或其他监控工具，查看 Store 组件的 CPU、内存和磁盘使用情况。
      • 如果资源不足，可以考虑升级硬件或优化任务配置。

  3. 避免频繁重启：

    • 如果 Store 组件频繁出现延迟，建议先排查上述问题，而不是直接重启组件。
    • 如果必须重启，可以通过 OMS 控制台的操作界面进行重启，无需手动干预。

总结

  1. 全量迁移基于快照，完成后会自动接上增量同步，但需确保 TiDB 的 binlog 功能正常运行。
  2. 批量订正功能可通过调整校验阈值或跳过全量校验实现，但对于重要数据仍需单独订正。
  3. Store 组件延迟问题可能是由于时钟不同步或资源不足引起，建议优化配置并监控资源使用情况。

如果仍有疑问，请提供更多详细信息（如具体的错误日志或任务配置），以便进一步分析。

更多信息请查看:

  1. 迁移 OBKV 的增量数据至 HBase 数据库
  2. OMS 社区版问题排查手册
  3. 内存和磁盘要求
  4. 迁移 HBase 数据库的数据至 OBKV
  5. OMS 社区版错误码
  6. DataFlowSource
  7. 创建 OceanBase 社区版至 RocketMQ 的数据同步任务
  8. 更新 Full-Import 组件
  9. 迁移 TiDB 数据库的数据至 OceanBase 社区版

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

#8

1、使用的是clog日志 通过cdc组件实现的
2、

image
image2828×814 214 KB

这个地方重新校验不一致的表，可以把所有不一致的表都重新校验
3、具体看一下组件监控 拿一下日志 具体看看 是不是有问题