DM同步突然中断

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

DM 版本：v2.0.7
TIDB：v4.0.11
mysql：5.6.32
DM-Worker报错：

image
image1800×552 143 KB

尝试恢复:
1、pause-task 暂停任务
2、resume-task 恢复任务
还是有报错

同步已经跑了很长时间了 突然间报错。

2

可以看看实际的work 的日志

3

worker 日志一直在报如下错误：

[2022/12/20 15:01:15.429 +08:00] [WARN] [task_checker.go:393] [“backoff skip auto resume task”] [component=“task checker”] [task=vgift_account] [latestResumeTime=2022/12/20 14:58:45.429 +08:00] [duration=5m0s]
[2022/12/20 15:01:20.429 +08:00] [WARN] [task_checker.go:393] [“backoff skip auto resume task”] [component=“task checker”] [task=vgift_account] [latestResumeTime=2022/12/20 14:58:45.429 +08:00] [duration=5m0s]
[2022/12/20 15:01:20.480 +08:00] [INFO] [syncer.go:2912] [“binlog replication status”] [task=exchange_order] [unit=“binlog replication”] [total_events=488748531] [total_tps=30] [tps=0] [master_position=“(mysql-bin.000229, 792724909)”] [master_gtid=3d063b5d-ac92-11ea-8d7f-ecf4bbdee7d4:1-186586092,48230336-ac92-11ea-8d80-e4434b036590:1-933946527,538fe0da-ac92-11ea-8d80-246e966090ac:1,9efc0181-e451-11eb-be59-b4055d643320:1-1023] [checkpoint=“position: (mysql-bin.000016, 449314866), gtid-set: 3d063b5d-ac92-11ea-8d7f-ecf4bbdee7d4:1-186586092,48230336-ac92-11ea-8d80-e4434b036590:1-714173783,538fe0da-ac92-11ea-8d80-246e966090ac:1(flushed position: (mysql-bin.000016, 449314866), gtid-set: 3d063b5d-ac92-11ea-8d7f-ecf4bbdee7d4:1-186586092,48230336-ac92-11ea-8d80-e4434b036590:1-714173783,538fe0da-ac92-11ea-8d80-246e966090ac:1)”]

4

观察下上下游是否正常，把tidb的日志贴一下

5

tidb 是正常的 不光这个work 接入tidb 还有很多work的同步是正常的

6

这两个问题可以参考一下~

我记得 TiDB 是兼容 mysql 5.7 ，你可以尝试升级一下 mysql 的版本~

image
image1286×803 107 KB

https://docs.pingcap.com/zh/tidb/stable/mysql-compatibility#与-mysql-兼容性对比

7

和兼容性 应该没有关系 已经跑了很久了，而且出现问题的语句是常见DML语句 “delete”

8

TiDM worker 报context deadline exceeded错误 然后一直不同步数据 这个问题看了吗？

9

和这个问题很相似，我调整了GC时间 然后在重新开始同步，还是报这个错误。

10
  1. 每次都是卡在这个 SQL 吗？
  2. 查看 TiDB.log 是否有告警或者报错？
11

如果下游表没有主键或者唯一索引的话，删除时找到这一行会很慢，导致操作超时。可以试着将任务配置中的 batch-size 改小

12

batch-size 是指这个参数？batch 吗？ 我看这个参数任务创建后不支持动态更新，我的这个任务的数据量比较大，同步一步花的时间比较长。确实是没有主键和唯一索引，如果现在添加一个唯一索引，能否解决问题呢。

13

1、是的 每一次都是delete卡住了
2、tidb.log的日志
[2022/12/19 20:34:50.276 +08:00] [WARN] [backoff.go:329] [“tikvRPC backoffer.maxSleep 40000ms is exceeded, errors:\nsend tikv request error: wait recvLoop: context deadline exceeded, ctx: region ID: 211364173, meta: id:211364173 start_key:"t\200\000\000\000\000\000\000\025_i\200\000\000\000\000\000\000\002\003\200\000\000\000\000\000\000\021" end_key:"t\200\000\000\000\000\000\000\025_i\200\000\000\000\000\000\000\002\003\200\000\000\000\000\000\000\035" region_epoch:<conf_ver:234011 version:120 > peers:<id:317502942 store_id:55300573 > peers:<id:317505991 store_id:25638868 > peers:<id:317516391 store_id:314339911 > , peer: id:317505991 store_id:25638868 , addr: 10.92.193.92:10822, idx: 1, reqStoreType: TiKvOnly, runStoreType: tikv, try next peer later at 2022-12-19T20:34:07.481488118+08:00\nsend tikv request error: wait recvLoop: context deadline exceeded, ctx: region ID: 211364173, meta: id:211364173 start_key:"t\200\000\000\000\000\000\000\025_i\200\000\000\000\000\000\000\002\003\200\000\000\000\000\000\000\021" end_key:"t\200\000\000\000\000\000\000\025_i\200\000\000\000\000\000\000\002\003\200\000\000\000\000\000\000\035" region_epoch:<conf_ver:234011 version:120 > peers:<id:317502942 store_id:55300573 > peers:<id:317505991 store_id:25638868 > peers:<id:317516391 store_id:314339911 > , peer: id:317505991 store_id:25638868 , addr: 10.92.193.92:10822, idx: 1, reqStoreType: TiKvOnly, runStoreType: tikv, try next peer later at 2022-12-19T20:34:29.244181584+08:00\nsend tikv request error: wait recvLoop: context deadline exceeded, ctx: region ID: 211364173, meta: id:211364173 start_key:"t\200\000\000\000\000\000\000\025_i\200\000\000\000\000\000\000\002\003\200\000\000\000\000\000\000\021" end_key:"t\200\000\000\000\000\000\000\025_i\200\000\000\000\000\000\000\002\003\200\000\000\000\000\000\000\035" region_epoch:<conf_ver:234011 version:120 > peers:<id:317502942 store_id:55300573 > peers:<id:317505991 store_id:25638868 > peers:<id:317516391 store_id:314339911 > , peer: id:317505991 store_id:25638868 , addr: 10.92.193.92:10822, idx: 1, reqStoreType: TiKvOnly, runStoreType: tikv, try next peer later at 2022-12-19T20:34:50.276827373+08:00”]
[2022/12/23 18:48:18.376 +08:00] [INFO] [region_cache.go:620] [“switch region peer to next due to send request fail”] [current=“region ID: 211364173, meta: id:211364173 start_key:"t\200\000\000\000\000\000\000\025_i\200\000\000\000\000\000\000\002\003\200\000\000\000\000\000\000\021" end_key:"t\200\000\000\000\000\000\000\025_i\200\000\000\000\000\000\000\002\003\200\000\000\000\000\000\000\035" region_epoch:<conf_ver:234320 version:120 > peers:<id:318852880 store_id:55300575 > peers:<id:318852951 store_id:25638870 > peers:<id:319003158 store_id:314339911 > , peer: id:318852951 store_id:25638870 , addr: 10.92.182.75:10826, idx: 1, reqStoreType: TiKvOnly, runStoreType: tikv”] [needReload=false] [error=“wait recvLoop: context deadline exceeded”]
[2022/12/24 05:24:34.790 +08:00] [WARN] [syncer.go:150] [“[ddl] etcd-cli put kv failed”] [key=/topology/tidb/10.92.167.167:40006/ttl] [value=1671830672790451428] [error=“context deadline exceeded”] [retryCnt=0]

14

是这个 batch。添加唯一索引，应该可以改善这个问题

15

报错这时是不是有其他全量任务正在同步？如果有等待全量同步结束在观察一下任务会不会恢复正常

16

此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。