OMS数据同步表名大小写问题

OceanBase 技术问题
#1

【 使用环境 】生产环境
【 OB or 其他组件 】OMS
【 使用版本 】
【问题描述】在mysql到ob同步任务中的反向增量阶段时，发现表名中同时有大小写的情况，会将表名变为全小写，导致报错表不存在：

[2024-10-28 09:54:20.635] [ERROR] [sinkTask-5] [Fatal exception oms record [meta[ncms_gd.ncms_gd-rpt_prv_ele_keyindicator_yf,1729864241,DDL,1729864241]post[Struct{ddl(VAR_CHAR_STRING)=TRUNCATE TABLE `rpt_prv_ele_keyindicator_yf`,env(VAR_CHAR_STRING)=1729864241623040,ddlType(VAR_STRING)=TRUNCATE_TABLE,srcDatabase(VAR_STRING)=ncms_gd.ncms_gd,srcTable(VAR_STRING)=rpt_prv_ele_keyindicator_yf,destDatabase(VAR_STRING)=ncms_gd,destTable(VAR_STRING)=rpt_prv_ele_keyindicator_yf,originalDDL(VAR_STRING)=truncate table rpt_prv_ele_keyindicator_YF,affectObjects(LIST)={"db":"ncms_gd","table":"rpt_prv_ele_keyindicator_yf"}}]], exception message [com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Table 'ncms_gd.rpt_prv_ele_keyindicator_yf' doesn't exist], errorCode [1146], sqlState [42S02]]

而实际同步的DDL语句为：

[2024-10-28 11:05:50.418] [forward_slot0-(ETLProcessor)-queue_slot1] receive ddl:truncate table rpt_prv_rent_basesite_YF, checkpoint[1729942837]

OMS将表名变更为了全小写。mysql和OB的lower_case_table_name变量都是0，就导致了同步错误被卡住的问题。

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

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

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

1 个赞
#3

根据文档库中的信息，OMS 社区版在处理表名时默认会将表名转换为小写，这是因为在迁移 OceanBase 社区版的数据至 OceanBase 社区版时，默认按照目标端参数 lower_case_table_names = 1 设置，并以小写方式创建目标端数据库对象 [1]。然而，您提到 MySQL 和 OB 的 lower_case_table_names 变量都是 0，这表明表名应该保持原样，而不是被转换为小写。

解决方案

  1. 检查 OMS 配置：

    • 确认 OMS 社区版的配置中没有强制将表名转换为小写。您可以在 OMS 控制台的配置项中检查是否有相关的设置。

  2. 手动调整表名：

    • 如果 OMS 无法正确处理表名的大小写，您可以手动在目标端创建表结构，并确保表名与源端一致。在 OMS 控制台中，您可以选择在结构迁移步骤跳过部分失败对象，然后手动创建表结构 [1]。

  3. 修改 OMS 行为：

    • 如果 OMS 确实存在将表名转换为小写的行为，您可以尝试联系 OceanBase 的技术支持团队，询问是否有方法禁用这一行为。

详细步骤

  1. 检查 OMS 配置：

    • 登录 OMS 控制台。
    • 导航到数据迁移任务的配置页面。
    • 查找与表名大小写相关的配置项，确保没有强制将表名转换为小写的设置。

  2. 手动调整表名：

    • 在目标端手动创建表结构，确保表名与源端一致。
    • 在 OMS 控制台中，创建数据迁移任务时，选择在结构迁移步骤跳过部分失败对象。
    • 手动创建表结构的 SQL 语句示例：
      CREATE TABLE `rpt_prv_ele_keyindicator_YF` (
  -- 列定义
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

  3. 修改 OMS 行为：

    • 联系 OceanBase 的技术支持团队，提供详细的错误日志和配置信息。
    • 询问是否有方法禁用 OMS 将表名转换为小写的行为。

注意事项

  • 表名大小写敏感性：确保 MySQL 和 OB 的 lower_case_table_names 变量保持一致，以避免表名大小写引起的同步问题。
  • 日志分析：收集详细的错误日志，以便更好地定位问题。

希望以上信息能帮助您解决问题。如果问题依然存在，建议联系 OceanBase 的技术支持团队获取进一步的帮助。

检索到的文档如下:

  1. 容灾双活场景的数据迁移
  2. 为 MySQL 数据库开启 Binlog
  3. 迁移 MySQL 数据库的数据至 OceanBase 社区版
  4. OceanBase 社区版之间的数据迁移
  5. 使用 OMS 从 OceanBase 数据库 MySQL 租户迁移数据到 MySQL 数据库
  6. 使用 OMS 从 MySQL 数据库迁移数据到 OceanBase 数据库 MySQL 租户
  7. 创建和更新心跳表
  8. 使用 OMS 从 PostgreSQL 数据库迁移数据到 OceanBase 数据库 MySQL 租户
1 个赞
#4

1.麻烦发下 MySQL和OB各自的版本
2.确认下两者的lower_case_table_names是否一致

OB和MySQL的参数lower_case_table_names 行为是一致的

MySQL：

image
image2096×558 213 KB

OB：

image
image1790×1012 147 KB

#5

mysql的版本是5.7.27，ob的版本是4.3.2.1，两者的lower_case_table_names是一致的，都是0。mysql和ob的表名大小写是一样的，sql语句中的表名也是实际的表名，但是oms在同步的时候报错的表名大小写和实际的表名大小写不一样，现在怀疑是oms的问题，变更了sql语句中的表名大小写，

#6

根据您提供的信息，MySQL 和 OB 的 lower_case_table_names 变量都是 0，这意味着表名应该是大小写敏感的。然而，OMS 在同步过程中将表名转换为了小写，导致同步失败。这确实可能是 OMS 的问题。

详细分析

  1. OMS 表名处理机制：

    • 根据文档，OMS 社区版默认会将表名转换为小写，即使源端和目标端的 lower_case_table_names 都是 0 也是如此 [1]。

  2. OMS 配置检查：

    • 您需要检查 OMS 的配置，确保没有强制将表名转换为小写的设置。
    • 在 OMS 控制台中，导航到数据迁移任务的配置页面，查找与表名大小写相关的配置项。

  3. 手动调整表名：

    • 如果 OMS 无法正确处理表名的大小写，您可以手动在目标端创建表结构，并确保表名与源端一致。
    • 在 OMS 控制台中，创建数据迁移任务时，选择在结构迁移步骤跳过部分失败对象，然后手动创建表结构。

解决方案

  1. 检查 OMS 配置：

    • 登录 OMS 控制台。
    • 导航到数据迁移任务的配置页面。
    • 查找与表名大小写相关的配置项，确保没有强制将表名转换为小写的设置。

  2. 手动调整表名：

    • 在目标端手动创建表结构，确保表名与源端一致。
    • 在 OMS 控制台中，创建数据迁移任务时，选择在结构迁移步骤跳过部分失败对象。
    • 手动创建表结构的 SQL 语句示例：
      CREATE TABLE `rpt_prv_ele_keyindicator_YF` (
  -- 列定义
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

  3. 联系技术支持：

    • 如果上述方法无法解决问题，建议联系 OceanBase 的技术支持团队，提供详细的错误日志和配置信息，询问是否有方法禁用 OMS 将表名转换为小写的行为。

详细步骤

  1. 检查 OMS 配置：

    • 登录 OMS 控制台。
    • 导航到数据迁移任务的配置页面。
    • 查找与表名大小写相关的配置项，确保没有强制将表名转换为小写的设置。

  2. 手动调整表名：

    • 在目标端手动创建表结构，确保表名与源端一致。
    • 在 OMS 控制台中，创建数据迁移任务时，选择在结构迁移步骤跳过部分失败对象。
    • 手动创建表结构的 SQL 语句示例：
      CREATE TABLE `rpt_prv_ele_keyindicator_YF` (
  -- 列定义
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

  3. 联系技术支持：

    • 联系 OceanBase 的技术支持团队，提供详细的错误日志和配置信息。
    • 询问是否有方法禁用 OMS 将表名转换为小写的行为。

注意事项

  • 表名大小写敏感性：确保 MySQL 和 OB 的 lower_case_table_names 变量保持一致，以避免表名大小写引起的同步问题。
  • 日志分析：收集详细的错误日志，以便更好地定位问题。

希望以上信息能帮助您解决问题。如果问题依然存在，建议联系 OceanBase 的技术支持团队获取进一步的帮助。

检索到的文档如下:

  1. 容灾双活场景的数据迁移
  2. 为 MySQL 数据库开启 Binlog
  3. 迁移 MySQL 数据库的数据至 OceanBase 社区版
  4. OceanBase 社区版之间的数据迁移
  5. 使用 OMS 从 OceanBase 数据库 MySQL 租户迁移数据到 MySQL 数据库
  6. 使用 OMS 从 MySQL 数据库迁移数据到 OceanBase 数据库 MySQL 租户
  7. 创建和更新心跳表
  8. 使用 OMS 从 PostgreSQL 数据库迁移数据到 OceanBase 数据库 MySQL 租户

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

  1. lower_case_table_names
  2. 迁移 MySQL 数据库的数据至 OceanBase 社区版
  3. 按表恢复相关参数介绍
  4. 创建 OceanBase 社区版至 Kafka 的数据同步任务
  5. Schema 规范
  6. 配置迁移对象的匹配规则
  7. 创建 OceanBase 社区版至 RocketMQ 的数据同步任务
  8. 执行计划管理

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

#7

麻烦发下OMS的版本，我沟通这块的老师确认下这个问题

#8

OMS:feature_4.2.4_ce

#10

两边的服务器系统都是一样的吧 发一下具体的服务器系统版本

#11

lower_case_table_names都是一样的，不然OMS同步预检查无法通过。
操作系统版本都是用的中国移动的BClinux8.2。

#12

下面的截图的日志 你发一下 看看具体的问题

image
image795×366 15.4 KB

同增量数据迁移部分，只是在组件id命名上有区别，名称上带有“reverse”关键字

#13

抽取了当天的日志，但是有两个日志太大，无法上传，你们需要过滤什么信息没有，如果有，我把过滤后的日志上传吧。

#14

truncate 之外的操作会出现这种情况吗？
试了下旧版本的oms，truncate 会出现这个问题。新版 oms 4.2.6 应该是没这个问题的，您可以升级试一下

#15

尽量压缩一下 现在可以上传50M日志了 不是很好过滤 报错的信息不一样 也可以像楼上说的 升级一下oms

#16

没有发现truncat之外的类似问题。

#17

太大了 最大了压缩完都是1.5G，不压缩有16G，切成50M，要切好几百个压缩包。

#18

image
发这个 错误日志 就行了 这个应该不大吧

#19

这两个比较小。
connector_filter_msg.log (815 字节)
error (1).log (22.2 KB)

#20

看着 报错信息只有10.25号报错信息 truncate报错

image
image2890×250 114 KB

再给你确定一下 找的是这个 组件id上带有有reverse这个关键字下的日志么？

image
image735×394 55.3 KB

#21

老版本不支持truncate，用最新版本4.2.6_CE吧

#22

确定是的，在这个下面找的：
connector_v2:np_65pruvqjbdvk_reverse-incr_trans-1-0:0007000003