DM 全量加增量迁移全库报code=40070 Message: no mysql source is being handled in the worker

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:

【TiDB 版本】
TIDB v5.0.0
DM v2.0.2

【问题描述】

DM 全量加增量迁移全库,大概4G的测试环境库,从00:07:00运行到04:53:00 结束了。发现未完全成功,迹象如下:

  1. 发现有些大记录表记录未完全迁移,比如500w的只迁移了300w
  2. query-status task显示如下错:code=40070 Message: no mysql source is being handled in the worker
{
    "result": true,
    "msg": "",
    "sources": [
        {
            "result": false,
            "msg": "[code=40070:class=dm-worker:scope=internal:level=high], Message: no mysql source is being handled in the worker",
            "sourceStatus": {
                "source": "staging-mysql-slave-replica",
                "worker": "dm-10.10.52.21-8262",
                "result": {
                    "isCanceled": false,
                    "errors": [
                        {
                            "ErrCode": 50000,
                            "ErrClass": "not-set",
                            "ErrScope": "not-set",
                            "ErrLevel": "high",
                            "Message": "context deadline exceeded",
                            "RawCause": "",
                            "Workaround": ""
                        }
                    ],
                    "detail": null
                },
                "relayStatus": null
            },
            "subTaskStatus": [
            ]
        }
    ]
}

  1. 上游mysql数据源是正常的,都可以访问和操作。operate-source show显示数据源结果如下:
Starting component `dmctl`: /root/.tiup/components/dmctl/v2.0.2/dmctl/dmctl --master-addr 10.10.52.20:8261 operate-source show
{
    "result": true,
    "msg": "",
    "sources": [
        {
            "result": true,
            "msg": "",
            "source": "dev-a-mysql-slave-replica",
            "worker": "dm-10.10.52.20-8262"
        },
        {
            "result": false,
            "msg": "[code=38032:class=dm-master:scope=internal:level=high], Message: some error occurs in dm-worker: ErrCode:50000 ErrClass:\"not-set\" ErrScope:\"not-set\" ErrLevel:\"high\" Message:\"context deadline exceeded\" , Workaround: Please execute `query-status` to check status.",
            "source": "staging-mysql-slave-replica",
            "worker": "dm-10.10.52.21-8262"
        }
    ]
}

后面我尝试resume-task想继续任务,报

{
    "op": "Resume",
    "result": false,
    "msg": "task /data/conf/tidb/dm/saofu-staging.yaml has no source or not exist, please check the task name and status",
    "sources": [
    ]
}

又尝试stop,再start task,报

{
    "result": true,
    "msg": "",
    "sources": [
        {
            "result": false,
            "msg": "[code=38045:class=dm-master:scope=internal:level=medium], Message: fail to get expected result",
            "source": "staging-mysql-slave-replica",
            "worker": "dm-10.10.52.21-8262"
        }
    ]
}

另外dm_meta表里,syncer_checkpoint没记录,loader_checkpoint有记录,截图中是1张500w的大表(最终下游比上游漏了记录),红圈处不知道是否是异常情况

所以现在会是什么问题? 要怎么处理呢?

可以检查一下这个 worker 是否正常吗,如果您是 tiup 部署的,可以通过

tiup dm display <cluster-name>

查看。

另外帮忙上传一下该 worker 以及 master 日志,上面的命令应该会会看到数据目录

worker目前是正常,命令结果如下

从图片可以看到版本是 v2.0.1。另外需要看一下 DM-master leader(52.20 那个。如果曾经发生切换的话需要相应的 master 日志),以及 出错 worker 的日志。在上面列出的 data dir 跟 deploy dir 应该能找到

10.10.52.20、10.10.52.21、10.10.52.22以下简称为20,21,22(日志文件的后缀也是如此对应)
出问题时间应该是4.20日的04:53~04:55之间(日志文件时区问题,需要+8小时)

当时dm-master leader应该是20。任务是分配在dm-worker 21上。详细日志如下:
dm-master-20.log (12.0 KB) dm-master-21.log (6.5 KB) dm-master-22.log (3.2 KB) dm-worker-21.log (52.5 KB)

目前我这边的一些线索和推测
从dm的grafana的worker state指标 以及 dm-master-20.log的unbound the worker for source前后日志,猜测负责迁移任务saofu-staging的worker 21机器在04:53:50左右是有问题所以unbound了数据源? 之后04:55:01左右又恢复了(bound the source to worker日志)?

我的疑问是

  1. 是否如我猜测的过程
  2. 如果如我猜测是21短暂unbound了1分钟,原因是什么?负载太大导致Raft离线?那需要如何解决呢
  3. 即使真发生了unbound再bound,那在恢复后迁移任务saofu-staging不是应该继续吗?为什么停止了。
  4. 目前我要怎么操作才能让迁移任务继续呢?

日志中可以看到,写下游数据库与写 etcd 的负载都挺高,出现了慢 IO。

写下游数据库慢,可能跟下游 TiDB 配置、负载有关,这个等社区专家来看一下。
写 etcd 慢,是由于 master 跟 worker 部署在了一起,worker 在 dump 数据的时候会写磁盘,干扰了 etcd 写入,从而干扰了基于 etcd 的 worker keepalive / bound。疑问 3 的原因是 worker 在恢复 bound 的时候,读取 etcd 超时了,所以恢复失败

恢复任务的话,可以将 master 跟 worker 分开部署,在下游清理导入数据后 stop-task、start-task --remove-meta 重做任务。


有可能是<=v2.0.1 DM的bug,我更新DM为v2.0.2之后,跑同样数据量的同步任务,中途又出现了,不过这次它继续处理了且成功了(无人工介入)

  1. 如果可以再测试下,看看是否 DM 2.0.2 可以每次都恢复
  2. 是什么环境?公有云,还是自己IDC里的物理机,上游是MySQL吗?MySQL的binlog会保存多久?

环境是线下环境,自建机房中的虚拟机。上游是Mysql,binlog多久不清楚,但是至少超过3天吧

好的,多谢。标记一下,看看有没有其他人有类似问题。