【TIDB DM】同步的worker日志里有错误

#1

execute sql failed by connection error
RawCause: context deadline exceeded"

现在我这边碰到2个问题

  1. 当任务启动到一定数量时，很难再提交新的任务，看master的日志，也是 context deadline exceeded
  2. 已经提交的某个任务，不再同步任务，看worker日志，里面也是 context deadline exceeded
    总感觉都是跟数据库连接相关的原因引起的
    但是手工用命令行登录数据库都是OK的。 这个问题到底要如何解决啊？
1赞
#2

上游mysql binlog_format配置的是什么？

1赞
#3

MySQL [(none)]> show variables like ‘binlog_format’;
±--------------±------+
| Variable_name | Value |
±--------------±------+
| binlog_format | ROW |
±--------------±------+
1 row in set (0.01 sec)

1赞
#4

https://github.com/pingcap/tiflow/pull/4432
https://github.com/pingcap/tiflow/pull/4438

看看这两个，是不是中标了？

1赞
#5

页面打不开啊

1赞
#6

场景是这样：
我这里有5个IP的mysql数据库 和 10个IP的mysql数据库
一共15个源
其中 5个IP的mysql数据库中，做了分库分表，每个IP上面10个分库10个分表， 一共50个分库50个分表
其中10个IP的mysql数据库中，也做了分库分表，每个IP上面10个分库10个分表，一共100个分库，100个分表

我现在要做分库分表的实时同步，使用TIDB DM工具。
其中 50个分库50个分表那个， 我一共配置了17个同步任务， 每张表对应一个配置文件
100个分库100个分表的那个， 我配置了9个同步任务，每张表对应一个配置文件
昨天下午18:00的时候，一切都是好的。 在 DM可视化监控界面上，可以看到运行中的任务数 175个

然后今天凌晨1点左右收到了告警， 具体看了一下， 是某一个任务， binlog同步落后了

今天白天的时候，反复搞，最终发现， 我把任务停止后， 要再次启动，就非常困难了。 大概只能启动60个任务， 之后就会提示 RawCause: context deadline exceeded"
重新启动那个binlog落后的任务， 我看worker日志里，也是有出现 RawCause: context deadline exceeded"的字眼

1赞
#7

现在是我们使用TIDB DM的测试阶段，如果稳定运行一个月没问题，我们就正式用了。
我不想把dm_meta表都删除重新弄， 就是想通过运行期间出现过的一些故障，来快速演练一下故障恢复。
毕竟我们想把DM用来做业务库实时同步到TIDB，后续用来做实时数仓的ODS层。 因为是实时的，所以时效性要求比较高， 没出故障的时候，的确很爽，同步延迟都在1秒内， 但是一旦出现故障， 故障如果不能快速处理的话， 那么对后续的实时处理链条就会有较大影响，就不放心使用了

1赞
#8

翻墙看一下~

#9

这里显示 connection error，是数据库连接的问题，可以看下：

  1. 每个 dmworker 所在的物理机是否能连上 TiDB
  2. 在 TiDB 上检查 max_connections 变量，以及 show processlist 查看同步过程中，该 TiDB 实例消耗的连接数，连接数耗尽也可能出现这样的问题（大量的任务会占用大量的连接）
  3. 您的上游分表不知道是否存在 primary key，在没有主键的情况下，dm 会把所有列作为条件连接到一起，以准确定位到您修改的行。这种情况下很有可能让 TiDB 执行延迟太大，导致 DM 的同步进度大大落后于上游
  4. 楼上提到的 issue 是多个 dml 合并到一个再进行同步时执行错误（导致无法得知是哪个 dml 错误）。根本问题还是，dml 无法成功同步到下游。

p.s. 您的日志中有业务内容，请谨慎分享。

1赞