【 TiDB 使用环境】生产环境 or 测试环境 or POC
【 TiDB 版本】4.0.11
【遇到的问题】tidb主库 waiting for global read lock
【复现路径】主库添加为数据源，从库添加了为数据源
【问题现象及影响】
添加task的时候，配置从库的数据源头，发现，会对主库waiting for global read lock 。导致主库无法CRUD。
【附件】
请提供各个组件的 version 信息，如 cdc/tikv，可通过执行 cdc version/tikv-server --version 获取。
可以看看当前数据库是否存在其它 lock 信息导致无法获取到全局读锁。
背景：有一套主从（MS），我们配置dm同步的时候添加了两个数据源，一个添加M datasource1，一个添加S datasource2，我们此时添加了一个任务task1，任务里面配置的数据源头是datasource2，任务开启，发现M库的链接数增加，而且数据无法insert。你的这个当前数据库是指哪个呢？
当前 M 库
我的任务配置的同步源头是datasource2，不应该会牵扯到M库的锁吧？
DM 之前就包含了 M datasource1，一个 S datasource2 数据源是吧？现在增加了一个 datasource2 为数据源的 task1 是吗？
是的，然后发现我们的主库无法crud了
虽然看起来没什么直接关系，但是既然 M 实例存在这个锁的问题，那还是得分析下是什么导致的锁。
这个是可以复现的是吧？可以看看出现 wait 的时候是否有一些事务没有提交，或者是否存在死锁的情况。
查看了innodb的engine没有死锁的情况，然后stop task1 M的才可以crud，所以想知道这里面是不是有其他原因呢
可以查看 task1 的状态里面的source 地址确认一下是M 还是 S ？
确认是S.
相关背景补充下
1.原本DM已有一个同步任务的同步源是M(M开启了gtid,开启了审计功能).
2.新增一个任务,配置同步源为S.并开始同步.
3.观察新同步任务,均为正常,此时M出现锁waiting for global read lock,无法crud.
4.检查同步源及同步任务配置均无异常,检查workerworker日志,任务正常dump,load,等.
5.stop新同步任务,M开始恢复正常.
这个问题我这边也遇到了，请问最后找到解决方案和原因了吗？
同问，没有答案或结论?
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。