tidb之dm集群跳过某个事务实践

被动跳过 SQL 语句,参考官方文档

https://docs.pingcap.com/zh/tidb-data-migration/v1.0/skip-or-replace-abnormal-sql-statements

假设业务上可以接受下游 TiDB 不执行此 DDL 语句(即继续保持原有的表结构),则可以通过使用 sql-skip 命令跳过该 DDL 语句以恢复迁移任务。操作步骤如下:

一:使用 query-error 获取迁移出错的 binlog event 的 position 信息。

position 信息可直接由 query-error 返回的 failedBinlogPosition 获得。

本示例中的 position 为 mysql-bin|000001.000003:34642。

二:使用 sql-skip 预设一个 binlog event 跳过操作,该操作将在使用 resume-task 后迁移该 binlog event 到下游时生效。

» sql-skip --worker=127.0.0.1:8262 --binlog-pos=mysql-bin|000001.000003:34642 test

{ "result": true, "msg": "", "workers": [ { "result": true, "worker": "", "msg": "" } ]}

二:对应 DM-worker 节点中也可以看到类似如下日志:

2018/12/28 11:17:51 operator.go:121: [info] [sql-operator] set a new operatoruuid: 6bfcf30f-2841-4d70-9a34-28d7082bdbd7, pos: (mysql-bin|000001.000003, 34642), op: SKIP, args:on replication unit

三:使用 resume-task 恢复之前出错中断的迁移任务。

» resume-task --worker=127.0.0.1:8262 test

{ "op": "Resume", "result": true, "msg": "", "workers": [ { "op": "Resume", "result": true, "worker": "127.0.0.1:8262", "msg": "" } ]}

四:对应 DM-worker 节点中也可以看到类似如下日志:

2018/12/28 11:27:46 operator.go:158: [info] [sql-operator] binlog-pos (mysql-bin|000001.000003, 34642) matched,applying operator uuid: 6bfcf30f-2841-4d70-9a34-28d7082bdbd7, pos: (mysql-bin|000001.000003, 34642), op: SKIP, args:

五:使用 query-status 确认该任务的 stage 已经转为 Running。

» query-status --worker=127.0.0.1:8262 test

六:使用 query-error 确认原错误信息已不再存在。

»query-error --worker=127.0.0.1:8262 test

具体案例

首先模拟出主键冲突的报错,注意模拟的时候一定注意等你task运行一段时间后,再模拟,因为safe-mode: false # 设置为 true,则将来自上游的 `INSERT` 改写为 `REPLACE`,将 `UPDATE` 改写为 `DELETE` 与 `REPLACE`,保证在表结构中存在主键或唯一索引的条件下迁移数据时可以重复导入 DML。在启动或恢复增量复制任务的前 5 分钟内 TiDB DM 会自动启动 safe mode,这是这个原因所以当你启动某个task_mode 为all的任务的时候,当全量同步完成后,切换到增量的前5分钟内是safe-mode:true,这样就不会有主键冲突的问题!所以需要过5分钟后再模拟主键冲突!

然后通过 query-error查看报错的binlog点位!如下红色部分所示:failedBinlogPosition": "binlog|000001.000025:166513224"

[tidb@tidb-monitor-01 kv]$ dmctl --master-addr 11.28.11.143:8261 query-error liuwenhe

{

"result": true,

"msg": "",

"workers": [

{

"result": true,

"worker": "11.28.11.147:8266",

"msg": "",

"subTaskError": [

{

"name": "liuwenhe",

"stage": "Paused",

"unit": "Sync",

"sync": {

"errors": [

{

"msg": "[code=10006:class=database:scope=not-set:level=high]execute statement failed: INSERT INTO `bre_tidb`.`bre_event_data` (`REQUEST_ID`,`BUSINESS_ID`,`SYSTEM_CODE`,`DECISION_NUM`,`LOGIN_TYPE`,`SOURCE_TYPE`,`PRODUCT_TYPE`,`CUST_CHANNEL_CODE`,`NODE_NAME`,`CUST_NO`,`PROD_NO`,`SUB_PROD_NO`,`type`,`ID_NO`,`PHONE`,`DATA_PATH`,`BLAZE_PACKAGE_NAME`,`EXPERIMENT_NO`,`BLAZE_SIGN`,`CREATE_DATE`,`CREATE_TIME`,`UPDATE_DATE`,`UPDATE_TIME`) VALUES (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?): Error 1062: Duplicate entry 'C011802110030080021' for key 'PRIMARY'",

"failedBinlogPosition": "binlog|000001.000025:166513224",

"errorSQL": "[tp: insert, sql: INSERT INTO `bre_tidb`.`bre_event_data` (`REQUEST_ID`,`BUSINESS_ID`,`SYSTEM_CODE`,`DECISION_NUM`,`LOGIN_TYPE`,`SOURCE_TYPE`,`PRODUCT_TYPE`,`CUST_CHANNEL_CODE`,`NODE_NAME`,`CUST_NO`,`PROD_NO`,`SUB_PROD_NO`,`type`,`ID_NO`,`PHONE`,`DATA_PATH`,`BLAZE_PACKAGE_NAME`,`EXPERIMENT_NO`,`BLAZE_SIGN`,`CREATE_DATE`,`CREATE_TIME`,`UPDATE_DATE`,`UPDATE_TIME`) VALUES (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?), args: [C011802110030080021 C011802110047862166 rms TransactionCheck AND001 DF bnh_product zhifubao Application 150000407304 101 \u003cnil\u003e \u003cnil\u003e 360733198610043678 18807972084 /ReportFile/2018/02/11/C011802110030080021.gz \u003cnil\u003e \u003cnil\u003e \u003cnil\u003e 20180211 181415 20180211 181415], key: C011802110030080021`bre_tidb`.`bre_event_data`, ddls: [], last_pos: (binlog|000001.000025, 166512691), current_pos: (binlog|000001.000025, 166513224), gtid:\u003cnil\u003e]"

}

]

}

}

],

"RelayError": {

"msg": ""

}

}

]

}

执行具体的sql-skip操作:

[tidb@tidb-monitor-01 kv]$ dmctl --master-addr 11.28.11.143:8261Welcome to dmctl

Release Version: v1.0.6

Git Commit Hash: eaf2683c05ab44143bfb286bfbbc3ba157c555cc

Git Branch: release-1.0

UTC Build Time: 2020-06-17 10:22:01

Go Version: go version go1.13 linux/amd64

» sql-skip --worker=11.28.11.147:8266 --binlog-pos="binlog|000001.000025:166513224" liuwenhe

{

"result": true,

"msg": "",

"workers": [

{

"result": true,

"worker": "",

"msg": ""

}

]

}

恢复处于Paused状态的task:

» resume-task liuwenhe

{

"op": "Resume",

"result": true,

"msg": "",

"workers": [

{

"meta": {

"result": true,

"worker": "11.28.11.147:8266",

"msg": ""

},

"op": "Resume",

"logID": "4736"

}

]

}

再次查看发现已经正常:

» query-status liuwenhe

{

"result": true,

"msg": "",

"workers": [

{

"result": true,

"worker": "11.28.11.147:8266",

"msg": "",

"subTaskStatus": [

{

"name": "liuwenhe",

"stage": "Running",

"unit": "Sync",

"result": null,

"unresolvedDDLLockID": "",

"sync": {

"totalEvents": "3",

"totalTps": "0",

"recentTps": "0",

"masterBinlog": "(binlog.000025, 292158424)",

"masterBinlogGtid": "78ad9491-9efa-11ea-b4dc-005056b3c9fc:1-27595888",

"syncerBinlog": "(binlog|000001.000025, 163696575)",

"syncerBinlogGtid": "",

"blockingDDLs": [

],

"unresolvedGroups": [

],

"synced": false

}

}

],

"relayStatus": {

"masterBinlog": "(binlog.000025, 292158424)",

"masterBinlogGtid": "78ad9491-9efa-11ea-b4dc-005056b3c9fc:1-27595888",

"relaySubDir": "78ad9491-9efa-11ea-b4dc-005056b3c9fc.000001",

"relayBinlog": "(binlog.000025, 292158424)",

"relayBinlogGtid": "78ad9491-9efa-11ea-b4dc-005056b3c9fc:1-27595888",

"relayCatchUpMaster": true,

"stage": "Running",

"result": null

},

"sourceID": "13-3323-8266"

}

]

}

请使用浏览器的分享功能分享到微信等