- 1.问题描述
在使用公共云DTS做云下IDC数据迁移到云上DRDS过程中数据全量初始化的过程中任务卡住数据迁移无法正常完成；
重启多次都会卡住，影响正式迁移的进度和时间安排；
- 2.问题分析
经过确认一直都是如下图的表出现卡住迁移已经完成大部分的动作，但是任务卡住无法继续；
反馈阿里同学排查是怀疑max_statement_time参数设置太短，碰到写大字段超时报错，dts侧可以通过暂时降低batch提交的大小绕过；
针对max_statement_time在drds层面控制台没有该参数的设置，从命令行查询有该参数但是设置为0，代表不限制；
从drds下挂的rds查看该参数如下图所示，同样没有限制；
下图是DTS的log反馈报错的情况是drds侧的报错；
所以需要排查一下当时什么原因导致DTS在写数据的时候连接中断了。很可能是DRDS写RDS时某个参数超时了，导致连接中断，然后DRDS中断了与DTS的连接；
经过排查drds下的log日志发现有一些max packet limit的报错
检查云上drds的max_allowed_packet参数设置是16M的大小；
对应挂载的rds该参数设置是1024M；
因此怀疑是drds层面该参数设置过小，但又存在大字段，batch提交超过16M导致DTS内部报错，导致任务卡住无法继续；
然后就查询了卡住表的结构和一部分数据内容；
确实存在有longblob，text等大字段，存在有大的日志内容在longblob字段当中，和客户确认这是一张日志表主要存在关键业务的报文日志，主要是报文的大小无法确定，每个报文大小跟具体的实际业务有关系，所以确实可能会存在大报文的情况存在导致超过max_allowed_packet的设置大小；
如下是从rds中查到的表的一条记录的平均大小，大概在3-4k左右；
- 3.问题解决
通过调整max_allowed_packet参数到最大2G以后，重启dts任务以后问题解决；
通过和阿里DTS同学交流确定，出错的时候其实大部分数据已经迁完了，应该有不多的较长的行导致写失败了，从平均行长看3、4K一行，DTS这边一批次写入一般会256~1024条，对应max_allowed_packet 16MB应该没有问题，但这张有问题的表可能有为数不多的几条数据，每条会有接近16MB的样子，这就很可能一个写入批次超过16MB的阈值导致写入失败；
并且结合和客户应用同学确定会存在有大报文的情况出现，证明这个解释也很合理；
