DM 2.0.1 数据同步故障

🪐 TiDB 技术问题 备份&数据迁移
1

为提高效率，提问时请提供以下信息，问题描述清晰可优先响应。

  • 【TiDB 版本】：tidb 4.0.9
  • 【问题描述】：DM 2.0.1 数据同步故障
    “ErrCode”: 44007,
    “ErrClass”: “schema-tracker”,
    “ErrScope”: “downstream”,
    “ErrLevel”: “medium”,
    “Message”: “startLocation: [position: (3301-binlog.000004, 1224291), gtid-set: ], endLocation: [position: (3301-binlog.000004, 1224875), gtid-set: ]: cannot fetch downstream table schema of h3_job.xxl_job_qrtz_triggers to initialize upstream schema h3_job.xxl_job_qrtz_triggers in schema tracker”,
    “RawCause”: “Error 1146: Table ‘h3_job.xxl_job_qrtz_triggers’ doesn’t exist”,
    “Workaround”: “”

同样的表在tidb 3.0.12+dm 1.0.4上同步正常的。
该表xxl_job_qrtz_triggers是有外键， 这个问题改怎么处理，同步到TIDB可以不使用外键。 怎么跳过外键？？

Create Table: CREATE TABLE xxl_job_qrtz_triggers (
SCHED_NAME varchar(120) NOT NULL,
TRIGGER_NAME varchar(200) NOT NULL,
TRIGGER_GROUP varchar(200) NOT NULL,
JOB_NAME varchar(200) NOT NULL,
JOB_GROUP varchar(200) NOT NULL,
DESCRIPTION varchar(250) DEFAULT NULL,
NEXT_FIRE_TIME bigint(13) DEFAULT NULL,
PREV_FIRE_TIME bigint(13) DEFAULT NULL,
PRIORITY int(11) DEFAULT NULL,
TRIGGER_STATE varchar(16) NOT NULL,
TRIGGER_TYPE varchar(8) NOT NULL,
START_TIME bigint(13) NOT NULL,
END_TIME bigint(13) DEFAULT NULL,
CALENDAR_NAME varchar(200) DEFAULT NULL,
MISFIRE_INSTR smallint(2) DEFAULT NULL,
JOB_DATA blob,
PRIMARY KEY (SCHED_NAME,TRIGGER_NAME,TRIGGER_GROUP) USING BTREE,
KEY SCHED_NAME (SCHED_NAME,JOB_NAME,JOB_GROUP) USING BTREE,
CONSTRAINT XXL_JOB_QRTZ_TRIGGERS_ibfk_1 FOREIGN KEY (SCHED_NAME, JOB_NAME, JOB_GROUP) REFERENCES xxl_job_qrtz_job_details (SCHED_NAME, JOB_NAME, JOB_GROUP)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 ROW_FORMAT=DYNAMIC

还有一个表结构没什么异常，同步也报错表不存在

                            "Message": "startLocation: [position: (3303-binlog.000002, 2223), gtid-set: ], endLocation: [position: (3303-binlog.000002, 2866), gtid-set: ]: cannot fetch downstream table schema of `activiti`.`act_re_deployment` to initialize upstream schema `activiti`.`act_re_deployment` in schema tracker",
                            "RawCause": "Error 1146: Table 'activiti.act_re_deployment' doesn't exist",
2

请问现在 DM 数据同步是在Syncer 阶段吗？
是否是在上游 MySQL 操作了 有关外键的 DDL 操作？
如果是 可以考虑通过 binlog-event-filter功能针对此类 DDL 进行过滤

https://docs.pingcap.com/zh/tidb-data-migration/stable/key-features#binlog-event-filter

还一个 也需要关注下TiDB 的 SQL Mode 是否一致 4.0.9 与 3.0.12
同时还要比对下 DM 1.0.4 与 2.0.1 的 task 中 是否有针对此类 event 设置了 filter 。

3

请问现在 DM 数据同步是在Syncer 阶段吗？
—在TIDB 4.0.9是使用mysql 导入SQL备份文件的，同步是处于sync阶段。

是否是在上游 MySQL 操作了 有关外键的 DDL 操作？
–mysql 上游就是导入mysql备份

还一个 也需要关注下TiDB 的 SQL Mode 是否一致 4.0.9 与 3.0.12
–sql_mode也不至于导出表都创建不成功吧 ， 查看了sql_mode 是一样的。

image
image1804×167 6.01 KB

image
image1859×270 21.2 KB

同时还要比对下 DM 1.0.4 与 2.0.1 的 task 中 是否有针对此类 event 设置了 filter 。
–都没有设置event filter

4

如果是 在 load 阶段 可以按照如下步骤进行操作
1.清理准备导入的数据库表
2.手动创建对应的表，并将外教约束去除
3.dmctl stop task
4.dmctl start task --remove-meta

1 个赞
5

我是直接在TIDB中创建了表，然后重启任务。

但是没有主外键的表也出现这种情况，这不应该吧。

这种报错是DM不完善吗？？

6

目前使用并未有类似报错。
如果按照上述操作，先在tidb 下游创建对应的 schema ，DM 在数据 load 期间会自动判定 schema 是否已经存在，如果已经存在会自动跳过对应 schema 创建

如想要进一步排查问题，请将完整的 task.yaml与 对应的 DM-worker 上传下。一遍查看具体问题