作者： navyaijm2017 原文来源：https://tidb.net/blog/967d5319

案例一

问题描述

通过 DM 同步阿里云的 RDS 到 Tidb，woker 节点部署好之后，在这个 woker 节点上新增 task，task 运行到 dump 数据这个环节就报错，报错信息如下：

[2020/07/08 13:49:07.626 +08:00] [ERROR] [mydumper.go:164] ["Couldn't acquire LOCK BINLOG FOR BACKUP, snapshots will not be consistent: Access denied; you need (at least one of) the SUPER privilege(s) for this operation"] [task=it_coa_prod] [unit=dump]

但是阿里云的 RDS 已经授权 DM 了 REPLICATION SLAVE、REPLICATION CLIENT、RELOAD、SELECT 权限了，这个是 DM 需要的权限，可以参考上游 Mysql 实例配置前检查

处理过程

1. 在 asktug 上有个帖子，和我的报错一样，我按他这个配置问题依然没有解决，帖子链接详情
   

2. 手动执行 mydumer 命令备份，发现也报错，备份不成功，报错如下：

3. 通过 pingcap 的工程师贤净指导，在上面帖子的基础上需要在 mysql-instances 区域把 mydumpers 的配置引用进来，最终的配置如下：

问题分析

1. DM task 文件添加–no-locks 参数不生效的原因：

2. mydumper 两种写法，一种是写在最外面，需要在 source-id 下面引用一下，就是我上面的那种写法；另外一种就是直接在 source-id 下面直接写规则。两种写法如下图：

1. 给用户授权了 reload 权限，mydumper 不成功的原因：

2. 阿里云 rds 我们在给用户授权 reload 权限是可以授权成功，实际没有起作用，只是授权命令执行成功了，该用户还是没有 reload 权限，

案例二

问题描述

线上有个需求，需要把生产环境 Mysql 的一个库同步到 Tidb 集群，我开始按下面操作步骤进行，这个操作步骤只是执行过十几次以上没有任何问题。

1. 编辑 DM ansible 的 inventory.ini 文件，添加新的 worker 信息

2. 部署

3. 启动服务

4. 更新 dm-master

5. 更新监控

6. 编写同步任务的 task 文件，task/coa_prod.yaml，配置文件内容如下：

7. 检查 task 文件的编写是否正确，报错配置文件里面“coa-prod”这个数据源找不到

处理排查过程

1. 根据报错提示， “coa-prod” 这个数据源不存在，涉及到数据源配置的地方有 4 个地方，分别是：

• DM ansible 的 inventory.ini 文件

• master 节点上的配置文件

• worker 节点上的配置文件

• task 的配置文件

1. 一一排查上面文件里面是否有这个数据源, 排查了一遍发都有，说明没问题

• 查看 inventory.ini 文件

• 查看 dm-master 的配置文件

• 查看 woker 节点配置

• 查看 task 配置文件

1. 排查 dm-master、dm-woker 的日志也没有发现任务异常或者报错

2. 问题排查陷入僵局的时候，微信群里 PingCAP 的同学也一直帮忙一起排查，贤净同学提出了一个疑问，为啥我新增的 woker 节点的目录里面文件的时间都不是最新的，而是很久之前的时间，我仔细一看确实不对，然后通过 dumper 生成的全量备份目录，我才意思到这个 woker 是线上另外一个库的同步任务，也就是说我这次新加的 woker 目录把线上已经存在的 woker 节点目录覆盖了

问题原因

为啥新增的 worker 节点会把线上已经运行的 worker 节点覆盖呢？根本原因是因为 DM 升级过版本，我把目录搞混了，在中控机上存在两个 DM 的 ansible 目录：dm-ansible-prod 和 dm-ansible-v1.0.5-prod，在没有新增或者改动 woker 节点之前，这两个目录的 inventory.ini 文件除了 dm_version 不一样其他都一样，后续对 inventory.ini 的操作应该在 dm-ansible-v1.0.5-prod 这个里面做，但是升级之后我在 dm-ansible-prod 里面加过一个 woker 节点，这次操作是错误的，然后这次添加 woker 节点是在 dm-ansible-v1.0.5-prod 这个里面操作的，并且这次 worker 节点的部署参数除了 source_id、mysql_host 和上次添加的不一样，其他的参数都一样，所以就把上次部署的 woker 节点目录的相关文件覆盖了

如何解决

1. 线上已经被覆盖的 woker 节点恢复

• 因为只是把配置覆盖了，但是 worker 没有重启，所以线上之前跑的 woker 节点没有影响，只需要我们编辑这个节点配置文件把 source_id、mysql_host 更新回去就行；

• 把 dm-ansible-prod 目录 inventory.ini 文件这个 worker 节点信息 copy 到 dm-ansible-v1.0.5-prod 的 inventory.ini 添加重新部署即可

1. 这次新增的 worker 节点在最新的 dm-ansible-v1.0.5-prod 的 inventory.ini 添加重新部署即可

2. 升级产生的新旧目录共存的这个情况要避免，可以把旧目录备份到一个其他目录，不要放在中控机的工作目录下