今天早上9点20分，我看了一下当时的TIDB connection count是1500个左右
然后我就开始提交DM同步任务， 提交了90个任务后， 现在TIDB connection count是2100左右
然后新的DM任务提交开始困难了，开始报错了
昨天我这边出现的若干问题，也都是报 RawCause: context deadline exceeded
我怀疑现在就是数据库连接数这块有点问题
但是按理， binlog是先拉到了本地啊， 拉binlog需要花那么多连接数吗？
我就启动了12个左右的分库分表同步任务，就要消耗600个TIDB的连接数， 是不是太多了？？？
一个分库分表任务，对应50张分表
按你们的设计， 是把上游的binlog拉到本地， 然后解析本地binlog，入到TIDB里，
所以 本地binlog入库才会消耗TIDB连接， 可600个连接数，实在想不通为什么会要使用这么多
导致我现在提交新任务，拿不到新的连接， 新的任务启动不成功。
您好，拉取上游 binlog 的确是每个上游只消耗一个连接。为了提高增量同步的并行导入效率，对于下游，每个参与任务的 dmworker 都会至少维持：
- worker-count 个连接用来同步 dml （在任务配置中可以设置，默认是16）
- 一个 ddl 连接（同步 ddl）
- 一个 checkpoint 连接（用来保存一些 metadata）
- shard group 连接（一些 shard ddl 用到）
也就是说，最后一个任务需要消耗的 TiDB 连接为：dmworker 数量 * (worker count + 4)。如果您启动了多个任务，连接数还要再乘任务数量。
建议您可以适当调整一下任务数量（多个任务合并成一个），或者为每个任务调整并行度（worker-count)。
FYI: https://docs.pingcap.com/zh/tidb/stable/task-configuration-file-full
1 个赞
感谢， 这是我见过回答最完整的答案了
现在有个问题是： 我之前同步的时候，为了方便管理，都是一个表一个任务，
我看到dm_meta库下，也都是对应一个任务有3张表
现在如果我要把多个表合并到一个任务里，那这个任务的名称得另外取吧，那就是相当于重新全量同步了
这个就比较麻烦。。。。
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。