OMS迁移平台问题排查思路

GottdesKrieges2025-12-29 19:19

OMS迁移平台问题排查思路

OMS问题排查思路

  • 链路创建
    • 运维监控
      • 机器资源是否足够
      • 机器挂了
        • supervisor服务是否正常
        • 监控数据库是否正常（Influxdb）
    • 进入OMS容器
      • supervisorctl status查看组件是否Running
    • 查看Ghana异常日志：common-error.log
    • 表、视图迁移对象无法选择
      • 迁移用户权限是否足够
      • 表是否无PK、UK
      • 系统视图是否存在重名表（tables系统视图）
  • 结构迁移
    • 页面上是否有直接错误
    • 查看Ghana异常日志
      • dbcat.log
      • common-error.log
  • 全量迁移
    • 页面报错信息
    • /home/ds/run/{组件id}运行目录不存在：一般资源问题
    • 目标表不存在：可以手动建表
    • 目标表已有数据：用户确认没有问题可以直接恢复链路
    • 查看日志
    • rps低：性能瓶颈诊断专题
  • 增量迁移
    • Store组件
      • 延迟
        • 位点走得慢：需要调整Store参数
        • 位点不动：源端是否有批量数据处理
      • 异常退出
        • 查看具体Store异常日志
        • binlog没有了
        • 磁盘满了
    • 增量同步
      • 延迟
        • 确认store没有延迟
          • 性能瓶颈诊断
      • 异常退出
        • 查看具体增量日志
  • 全量校验
    • 异常
      • 查看日志
    • 数据不一致
      • 校验时增量是否有延迟
      • 确认校验结果是否正常（实际数据库中查询）
        • 只有源端有
        • 只有目标端有
        • 两边都有但值不一致
      • 源端-目标表结构是否一致
        • 影响数据唯一性的pk/uk是否一致：不一致可能是写入唯一性约束剔重了
        • pk/uk字段顺序是否一致
  • 正向切换
    • 具体错误步骤
      • 查看日志
      • 反向增量Store、增量创建失败
    • 增量位点延迟

OMS问题排查工具

OMS配置文件与日志

OMS安装配置文件为：/home/admin/conf/config.yaml。

组件 配置目录 日志目录
Ghana /home/ds/ghana/config /home/admin/logs/ghana/Ghana
CM /home/admin/conf/cm /home/admin/logs/cm/log
supervisor /home/ds/supervisor/config /home/admin/logs/supervisor
dbcat /home/ds/ghana/config /home/admin/logs/ghana/Ghana/dbcat.log
connector /home/ds/run/{组件ID}/conf /home/ds/run/{组件ID}/logs
store /home/ds/store/store{port}/conf /home/ds/store/store{port}/log
verifier /home/ds/run/{组件ID}/conf /home/ds/run/{组件ID}/logs

其中，{组件ID}和{port}可以在OMS页面数据迁移下的具体链路中，点击右上角的查看组件监控后展示的组件ID列和port列查看。

查看OMS容器内部目录挂载与宿主机目录的映射关系：

bash 复制代码 
[root@oms-host ~]# docker inspect oms -f {{.HostConfig.Binds}}
[/etc/oms_conf.yaml:/home/admin/conf/config.yaml /oceanbase/oms/oms/log:/home/admin/logs /oceanbase/oms/oms/store:/home/ds/store /oceanbase/oms/oms/writer:/home/ds/run]

查看OMS容器内部目录：

bash 复制代码 
docker exec -it oms ls /home/admin/conf
docker exec -it oms ls /home/admin/logs
docker exec -it oms ls /home/ds/

supervisord管理组件

Ghana、CM、supervisor这几个OMS组件是通过supervisord服务进行监控和管理的。supervisord配置文件所在目录：/etc/supervisor/conf.d，配置文件中可以找到用于启动组件的脚本，可以在脚本中调整jvm参数。

bash 复制代码 
[root@oms-host ~]# docker exec -it oms ls /etc/supervisor/conf.d/
drc_cm.ini  drc_supervisor.ini	oms_console.ini  oms_nginx.ini

常用的OMS组件管理命令:

  • 状态查看：supervisorctl status
  • 停止组件：supervisorctl stop nginx/oms_console/oms_drc_cm/oms_drc_supervisor/sshd
  • 启动组件：supervisorctl start nginx/oms_console/oms_drc_cm/oms_drc_supervisor/sshd
  • 重启组件：supervisorctl restart nginx/oms_console/oms_drc_cm/oms_drc_supervisor/sshd

查看OMS组件状态：

bash 复制代码 
[root@oms-host ~]# docker exec -it oms supervisorctl status
nginx                            RUNNING   pid 3169, uptime 15 days, 22:00:35
oms_console                      RUNNING   pid 3172, uptime 15 days, 22:00:25
oms_drc_cm                       RUNNING   pid 3202, uptime 15 days, 22:00:15
oms_drc_supervisor               RUNNING   pid 3461, uptime 15 days, 22:00:05

OMS各组件默认端口：

组件 默认端口
Nginx 8089
Ghana 8090
CM 8088
supervisor 9000
sshd 2023

OMS性能问题

⭐️ 并发、JVM内存、每个分片记录数可以解决大部分性能问题。

  • 并发：

    • 源端并发source.workerNum，目标端并发sink.workerNum。通常全量迁移时，源端并发和目标端并发的设置相同，增量同步Source中无需设置。
    • 并发度和机器CPU核数量相关，最大可以设置为CPU*4，同时需要查看机器中是否存在其他迁移任务在执行。

  • JVM内存 ：coordinator.connectorJvmParam。主要调整-Xms8g（初始内存）、-Xmx8g（最大内存）和-Xmn4g（新增的内存），调整规则如下:

    • 初始内存 = 最大内存
    • 新增的内存 = 最大内存 - 4GB
    • 通常一个并发对应1GB内存。例如：32并发，最大内存设置32GB。

  • 每个分片记录数 ：source.sliceBatchSize，默认值为600。

    • 对于大表通常10000即可，如果设置太大会消耗内存较多。
    • 可以根据logs/msg/metrics.log中的slice_queue决定是否需要修改。如果是0，则需要增加每个分片的记录数，原因是Source Worker线程会从slice_queue拉取分片，0表示没有分片，Source Worker便会等待空转。

OMS常见问题分析

安装阶段

Problem 1：OMS页面弹出Failed to fetch。

SOLUTION：检查系统参数tcp_tw_recycle的值，并设置为0。

bash 复制代码 
sysctl -a | grep tcp_tw_recycle
sysctl -w net.ipv4.tcp_tw_recycle=0

链路创建阶段

Problem 2：选择迁移对象时，无法找到需要迁移的表。

SOLUTION：检查数据源使用的迁移用户权限。

Problem 3: MySQL 8数据源连接失败，报错Public Key Retrieval is not allowed。

SOLUTION：修改MySQL用户的认证插件为mysql_native_password。

sql 复制代码 
alter user oms_user@'%' identified by mysql_native_password by 'xxxxxx';

Problem 4：全量、增量、Store没有创建成功。

OMS对资源有防御性检测，CPU、内存、磁盘超出**80%**就无法创建。OMS机器资源情况在运维监控-机器中可以看到。

  • Step 1：查看OMS管控相关的组件是否存在fullgc情况：
bash 复制代码 
[root@oms-host ~]# docker exec -it oms bash  # 进入OMS容器
[root@oms-host ~]# ps -ef | grep java   # 获取JAVA进程的PID

# 假设要查看GC情况的进程PID为3478
[root@oms-host ~]# /opt/alibaba/java/bin/jstat -gcutil 3478 1s
  S0     S1     E      O      M     CCS    YGC     YGCT    FGC    FGCT     GCT   
 50.00   0.00  20.66  73.45  89.42  84.04  91883  526.799     6    0.688  527.487
 50.00   0.00  27.05  73.45  89.42  84.04  91883  526.799     6    0.688  527.487
 50.00   0.00  27.06  73.45  89.42  84.04  91883  526.799     6    0.688  527.487
 50.00   0.00  27.06  73.45  89.42  84.04  91883  526.799     6    0.688  527.487
 50.00   0.00  27.07  73.45  89.42  84.04  91883  526.799     6    0.688  527.487
...
# FGC = Full GC次数
# FGCT = Full GC总耗时（秒）
  • Step 2：如果存在fullgc，则编辑对应启动脚本中的jvm内存配置（/etc/supervisor/conf.d中的配置文件可以找到对应的启动脚本）。
bash 复制代码 
[root@oms-host ~]# docker exec -it oms bash
[root@oms-host ~]# ls /etc/supervisor/conf.d
drc_cm.ini  drc_supervisor.ini  oms_console.ini  oms_nginx.ini

[root@oms-host ~]# cat /etc/supervisor/conf.d/drc_supervisor.ini | grep sh
command = bash /home/ds/supervisor/service.sh start foreground

[root@oms-host ~]# cat /home/ds/supervisor/service.sh | grep JAVA_OPTIONS
    JAVA_OPTIONS="-server -Xms2g -Xmx2g -Xmn1g -Xss1024k \
# 考虑将 -Xms2g -Xmx2g -Xmn1g 扩容为 -Xms4g -Xmx4g -Xmn3g
  • Step 3：重启存在fullgc情况的OMS组件：
    • 查看组件名：supervisorctl status
    • 重启：supervisorctl restart 组件名
bash 复制代码 
[root@oms-host ~]# docker exec -it oms supervisorctl status
nginx                            RUNNING   pid 3169, uptime 35 days, 21:48:41
oms_console                      RUNNING   pid 3172, uptime 35 days, 21:48:31
oms_drc_cm                       RUNNING   pid 3202, uptime 35 days, 21:48:21
oms_drc_supervisor               RUNNING   pid 3461, uptime 35 days, 21:48:11

[root@oms-host ~]# docker exec -it oms supervisorct restart oms_drc_supervisor

Problem 5：链路状态时而正常时而异常，链路组件本身无异常；或者链路状态一直异常，但是组件运行正常。

OMS链路状态是由supervisor组件采集汇报管控的。

SOLUTION：大多数可能是supervisor等组件内存不足导致，参照上面Problem 4检查supervisor组件的fullgc情况，并针对性的修改其JVM配置。

如果OMS是4.2.10以下版本，可以把配置文件/home/ds/supervisor/config/drc.properties中的max-http-header-size参数修改为1MB。

bash 复制代码 
server.max-http-header-size=1MB

Problem 6：全量+增量链路，在全量初始化的数据量非常大的情况下，全量迁移耗费很长时间，增量启动时候发现增量store数据已经不存在。

  • 全量迁移的并发速度设置为快速 或者自定义较大的并发+jvm内存，缩短全量迁移所需时间。
  • 创建链路时store的保留周期（增量记录保存时间）请选择足够的时间。
  • 链路已经建好发现全量迁移需要很长时间时，修改store的store.clearer.outdated参数（单位是秒）。

全量迁移阶段

Problem 7：全量迁移时符合下面三个条件的表迁移速度很慢：

  • 源端表记录数超过10亿；
  • 源端主键字段为单字段数字型；
  • 源端主键字段值不是自增连续的数字，不同记录之间存在比较较大的空隙的大。

对于主键是数字型并且记录数超过10亿的表，OMS全量迁移时状认会使用min-max方式分片迁移，由于id不连续导致大多分片是空数据多分片是空数据。

min-max 分片方式：OMS查询表中最小值和最大值，将最小值和最大值之间分成若干sliceBatchSize大小分片。

Solution 1：

  • 使用表中数值连续 并且存在索引的其他数字型字段作为分片字段；
  • 通过配置项设置指定分片索引字段：source.sliceIndex={"库名.表名":"索引名:otherid"}。

Solution 2：

  • 关闭min-max分片方式：source.sliceByMinMax=false，关闭min-max后OMS会使用分页方式查询表进行分片，速度上也可能比较慢，优先使用第一种方法。

Problem 8：源表字段和目标表字段不一致。

Solution 1：修改目标表字段，使其与源端一致。

Solution 2：忽略不一致的字段，不同步该字段。

bash 复制代码 
#忽略不一致的字段
sink.ignoreRedunantColumnsReplicate=true

Problem 9：目标表非空异常报错。

恢复任务可以继续运行，但需要用户自行判断目标表表中已经有数据了是否正常。

在新建链路配置迁移选项时，也可以配置目标端对象存在记录时的处理策略（忽略/停止迁移）。

Problem 10：源端OceanBase有额外字段OMS_PK_INCRMT导致迁移失败。

当源端是OceanBase数据库时，当表中出现OMS_PK_INCRMT保留字段名，说明源端表之前是从其他库迁移而来，并且是无主键和唯一键的表。一般这种情况下在OMS中做了正向切换步骤时会自动删除OMS_PK_INCRMT字段。

Solution：在当前源端库中手动删除OMS_PK_INCRMT字段。

增量迁移阶段

Problem 11：OB store由于数据库版本比CDC高导致的失败，部分版本的在日志中报check_observer_version_valid_fail关键错误信息。

Solution：升级OMS到最新版本或者热更CDC包。

升级参考文档：https://www.oceanbase.com/docs/community-oms-cn-1000000002947274

Problem 12：OB store clog中无数据字典信息，通常会报start Isn locate fail或者-4016。

Solution 1：缩短数据字典dump时间，等待1小时后再次启动store。

sql 复制代码 
alter system set dump_data_dictionary_to_log_interval='1h';

Solution 2：手动触发CALL DBMS_DATA_DICT.TRIGGER_DUMP()。

⚠️ 出现-4016错误码时也可能是clog磁盘不够被清理了，4.x可以通过下面的sql来判断clog是否被清理了。

sql 复制代码 
WITH palf_log_stat AS (
  SELECT
  tenant_id,
  MAX(begin_scn) AS palf_available_start_scn,
  MIN(end_scn) AS palf_available_latest_scn,
  SCN_TO_TIMESTAMP(MAX(begin_scn)) AS palf_available_start_scn_display, 
  SCN_TO_TIMESTAMP(MIN(end_scn)) AS palf_available_latest_scn_display
  FROM GV$OB_LOG_STAT
  WHERE tenant_id & 0x01 = 0 or tenant_id = 1
  GROUP BY tenant_id
),
archivelog_stat AS (
  SELECT
  a.tenant_id AS tenant_id,
  MIN(b.start_scn) AS archive_start_scn,
  a.checkpoint_scn AS archive_latest_scn,
  a.checkpoint_scn_display AS archive_available_latest_scn_display
  FROM CDB_OB_ARCHIVELOG a
  LEFT JOIN CDB_OB_ARCHIVELOG_PIECE_FILES b
  ON a.tenant_id = b.tenant_id AND a.round_id = b.round_id
  AND b.file_status != 'DELETED' AND a.STATUS = 'DOING'
  GROUP BY a.tenant_id
)
SELECT
  pls.tenant_id,
  pls.palf_available_start_scn,
  pls.palf_available_latest_scn,
  pls.palf_available_start_scn_display AS palf_available_start_scn_display,
  pls.palf_available_latest_scn_display AS palf_available_latest_scn_display,
  als.archive_start_scn AS archive_available_start_scn,
  als.archive_latest_scn AS archive_available_latest_scn,
  CASE WHEN als.archive_start_scn IS NOT NULL THEN SCN_TO_TIMESTAMP(als.archive_start_scn) ELSE NULL END AS archive_available_start_scn_dispalay,
  als.archive_available_latest_scn_display
FROM palf_log_stat pls
LEFT JOIN archivelog_stat als ON pls.tenant_id = als.tenant_id
GROUP BY pls.tenant_id, pls.palf_available_start_scn;

Problem 13：binlog没有更新提示，store位点不再前进。

Solution：新建数据源时需要勾选心跳选项。

增量同步时，允许OMS自动向该实例写入心跳数据，以解决源端在无业务写入场景下的高延时间题。

Problem 14：增量同步过程中报错目标表字段不存在。

大多数情况下是因为链路创建时没有勾选同步DDL选项，导致源端新增字段后，目标端没有同步新增。

Solution：在Incr-Sync增量组件配置coordinator.allowRecordTypes中增加DDL。

复制代码 
coordinator.allowRecordTypes=DELETE,INSERT,UPDATE,DDL

全量校验阶段

Problem 15：该表校验结果不一致行记录数超过OMS设置的阈值。

Solution：

  • 调大limitator.table.diff.max参数（默认10000）。
  • 调大task.checker_jvm_param参数控制的jvm参数。改大limitator.table.diff.max后一般需要同时调大jvm内存。

Problem 16：数据校验不一致问题。

如果查询时一致了，一般是增量导致，重跑数据校验即可。

📖如果查询当前还是不一致：

  • 不一致的数据是增量阶段同步的数据
    • 增量同步有延迟：追平后再次校验
    • 增量同步没有延迟
      • 查看数据是否在白名单中
        • store：mysql2store.filter.conditions和liboblog.tb_white_list
        • connector：whiteCondition
      • 查看数据pk是否在msg/connector_xxx_msg.log
      • 目标库是否还有其他链路或者应用修改数据
      • dump store数据进行查看
  • 不一致的数据是全量阶段同步的数据
    • 检查源端表和目标影响唯一约束的pk和uk是否一致。数据不一致可能是被唯一约束过滤了。

⭐️不一致数据是增量数据的场景：

  • 确认表是否在store和Incr-Sync组件的白名单中。
  • Incr-Sync组件日志目录中logs/msg下面两个文件分别保存着从store读取的记录的pk和写入目标库记录的pk。
    • connector_source_msg.log：这里能找到，说明store中有数据；
    • connector_sink_msg.log：这里能找到，说明数据已经写入了目标库。
  • 当Incr-Sync组件日志中没有找到不一致数据时，就需要继续dumpstore数据。
bash 复制代码 
wget 'localhost:listeningPort/subTopic' --post-data 'filter.conditions=*.*.*&checkpoint=1667996779'

References

【1】https://www.oceanbase.com/docs/community-oms-cn-1000000002947335

【2】https://www.oceanbase.com/docs/enterprise-oms-doc-cn-1000000004022987

【3】https://www.oceanbase.com/docs/community-oms-cn-1000000002947274

相关推荐
源力祁老师2 小时前
Odoo 客户端注册表
数据库
学Linux的语莫2 小时前
Milvus向量数据库的操作（基于Langchain）
数据库·langchain·milvus
怪我冷i2 小时前
dbeaver下载数据库驱动加速
数据库·postgresql·ai编程·ai写作
星辰_mya2 小时前
redis集群
数据库·redis·缓存
编程小Y3 小时前
MySQL原理
数据库·mysql
小石头 100863 小时前
MySQL 视图：把复杂变简单的“虚拟化”艺术
数据库·mysql
安当加密3 小时前
PostgreSQL 透明数据加密（TDE）方案与应用场景详解
数据库·postgresql
怪我冷i4 小时前
dbeaver如何连接PostgreSQL数据库
数据库·ai编程·ai写作
QH_ShareHub4 小时前
如何使用 NHANES 数据库
数据库
热门推荐
01GitHub 镜像站点02从快手“12·22”直播攻击事件看：一次教科书式的业务层饱和攻击03Linux下V2Ray安装配置指南04电脑检测软件—图吧工具箱05Claude Code Skills 实用使用手册06jdk21下载、安装（Windows、Linux、macOS）07Web安全中SQL注入绕过WAF的具体手法和实战案例08UV安装并设置国内源09BongoCat - 跨平台键盘猫动画工具10SQLmap 完整使用指南：环境搭建 + 命令详解 + 实操案例