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

OceanBase 技术问题
#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

#23

我看了下，升级有点风险，因为现在的oms集群上跑着反向增量任务。现在版本是4.2.4的，要升级两次。

#24

我看了之前 有truncate的操作 报错了 主要这个版本 truncate操作 会出现这个问题 新版 oms 4.2.6 应该是没这个问题的，建议你升级 要不然这个问题 没法绕过去