OMS 全量迁移中，如何处理目标表非空异常

培训 & 考证 实战分享
#1

OMS 全量迁移中，如何处理目标表非空异常？
A. 恢复任务继续运行
B. 清空目标表数据
C. 创建链路时，目标端对象存在记录时处理策略 选择 忽略
D. 忽略非空字段

#2

在使用 OMS 进行全量迁移时，如果遇到目标表非空异常，可以通过以下几种方式进行处理。这些方法基于 OceanBase 官方文档中关于 OMS 社区版的任务配置与预检查机制：

:white_check_mark: 正确的处理办法包括：

B. 清空目标表数据

  • 说明：这是最直接且安全的做法。当目标端表已存在数据时，为避免数据冲突或重复插入，建议在启动迁移任务前手动清空目标表。
  • 适用场景：适用于可以接受目标表被覆盖、且无需保留原有数据的迁移场景。
  • 注意事项：
    • 确保清空前已备份重要数据；
    • 若目标表有外键约束，需先禁用或处理依赖关系；
    • 推荐使用 TRUNCATE TABLE 而非 DELETE FROM 以提高效率并重置自增列（如适用）。

来源参考：创建任务 → 请求参数说明

C. 创建链路时，目标端对象存在记录时处理策略选择“忽略”

  • 核心参数：allowDestTableNotEmpty
  • 配置说明：
    • 设置为 true：表示允许目标表非空，OMS 将采用忽略或覆盖的方式写入数据。仅当目标端为 MySQL 数据库或 OceanBase 社区版时支持覆盖。
    • 设置为 false（默认）：表示不允许目标表非空，一旦检测到数据即报错并停止迁移。
  • 注意警告：

选择“忽略”后，全量校验将使用 IN 模式拉取数据，无法发现目标端存在而源端没有的数据（即多余数据），且校验性能会有所下降。

  • 配置路径：在创建数据迁移任务时，在“全量传输配置”中设置该策略。

来源参考：创建任务 → fullTransferConfig 配置

:warning: 其他选项分析

A. 恢复任务继续运行

  • 文档中提及：“如果出错后单击恢复，OMS 社区版将忽略该配置选项，继续迁移表数据，请谨慎操作。”
  • 这意味着即使原本设置了不允许非空表，也可以通过点击“恢复”跳过检查。
  • 但此操作属于应急手段，并不推荐作为常规解决方案，因为它绕过了预检查的安全机制，可能导致数据混乱。

来源参考：创建任务 → allowDestTableNotEmpty 参数说明

D. 忽略非空字段

  • 错误理解：该选项存在概念混淆。“非空异常”指的是目标表整体非空（即已有数据），而不是指某个字段的 NOT NULL 约束。
  • OMS 并未提供“忽略非空字段”的功能，相关参数均围绕表级数据存在性进行控制。
  • 因此该选项不成立。

:wrench: 补充：框架层预检查参数 checkDstTableEmpty

  • 功能：控制是否在任务首次启动时检查目标表是否为空。
  • 默认值：true
  • 行为逻辑：
    • 若为 true，且目标表非空，则任务报错中断；
    • 若为 false，则跳过此检查，允许非空表存在。
  • 支持版本：OMS 社区版 V4.0.0-CE 及以上
  • 建议用途：用于自动化部署或测试环境中临时跳过检查。

来源参考：Coordinator 框架层 checkDstTableEmpty 参数说明

:white_check_mark: 总结与建议

选项 是否有效 说明
A :warning:（非常规） “恢复”可跳过异常，但属高风险操作
B :white_check_mark: 推荐做法，确保干净的目标环境
C :white_check_mark: 标准配置项，适合允许覆盖的场景
D :x: 概念错误，无此功能

推荐实践顺序：

  1. 在任务设计阶段，明确目标端是否允许非空；
  2. 如允许，配置 allowDestTableNotEmpty = true；
  3. 如不允许，确保目标表清空后再启动任务；
  4. 生产环境慎用“恢复”跳过检查功能。
#3

可以，学习了

#4

那正确答案是BC?