dm同步多次中断，断点为同一个update语句

[hanson]

为提高效率，提问时请提供以下信息，问题描述清晰可优先响应。

• 【TiDB 版本】：v3.0.11 DM 1.0.3
• 【问题描述】：

上游mysql为阿里云rds，版本：5.6，近几天已发现同步中断3次，查看中断位点binlog信息，都是update 同一个表的记录，表结构中有两个字段是longtext，总共有58个字段

query-status报错信息如下：

dm-worker报错日志：

dm-worker-stderr.log

这个问题是不是表中有longtext字段的原因导致？

使用resume-task不管用，只能stop-task再start-task才能解决

[HackerlqNVmgtF (热)]

把觉得有问题的 update 语句拿出来到 tidb 中执行下，看看有问题吗？

官网有个文档

[csuzhangxc-PingCAP (Xuecheng Zhang)]

@hanson

使用resume-task不管用，只能stop-task再start-task才能解决

1.0.4 之前的版本，resume 可能不一定能成功。

DM 1.0.4 release notes: https://pingcap.com/docs-cn/stable/reference/tools/data-migration/releases/1.0.4/

修复到下游 TiDB 连接异常导致同步暂停后， resume-task 可能无法正常恢复同步的问题

[hanson]

问题定位到了，是tidb重启了。发现在重启之前，有个sql直接导致OOM，tidb节点是64G内存。刚把语句拿出来执行一下，瞬间tidb oom

表结构字段信息

只使用了最后一个字段：xx_data ,语句如下：
select xx_data
from a
group by xx_data
order by xx_data
limit 5000

表a记录数9千万，xx_data存放的记录类似json格式的数据，请问这样语句是不支持吗？

[飞与非-PingCAP (飞与非)]

1. xx_data 是 varchar(255)，TiDB 比较排序时按照二进制来比较的，会保证字典序，因此跟记录存储的内容没有关系
2. 请问 xx_data 是索引列吗？如果不是索引以上的 SQL 语名会是一个全表扫描，单算记录就会占用 9 千万 * 512 = 42 GB 内存，很容易 OOM，建议加个索引或者优化一下 SQL

[hanson]

添加索引后，观察了一晚上，没有出现oom，看监控内存使用量很少。

应该就是全表扫描导致oom了

[来了老弟]