DM 7.1.1在load阶段，报`batch write rows reach max retry 3 and still failed: invalid connection`

[dba-kit (张天师)]

DM 7.1.1在load阶段，报batch write rows reach max retry 3 and still failed: invalid connection。在执行resume-task后，也没有自动恢复。
详细报错日志是：

[2023/08/28 19:13:47.391 +08:00] [ERROR] [chunk_process.go:476] ["write to data engine failed"] [task=test_mysql_task] [unit=lightning-load] [table=`test`.`serviced_page`] [engineNumber=0] [fileIndex=0] [path=test.serviced_page.0000000000000.sql:0] [task=deliver] [error="[`test`.`serviced_page`] batch write rows reach max retry 3 and still failed: invalid connection"]

看日志好像是因为执行SQL失败，失败的SQL包含，业务把图片BASE64编码后存放的字段

[有猫万事足]

我的经验是，如果是sql执行失败，应该是有错误码，也会有具体的sql。
至少我这边dm如果出现这个invalid connection，基本都是连不上下游的tidb。可能是task文件中设置的tidb配置有问题。弄个mysql client连接一下tidb试试看。

[xfworld (魔幻之翼)]

BASE64编码后存放的字段 有多大？
估计你又遇到bug了

[dba-kit (张天师)]

看了下，是两个json字段，最长的字段是11M。应该是6.5之后导入逻辑改成使用tidb-lightning来导入导致的，6.1时候，这个表的导入还没有问题

[dba-kit (张天师)]

手动在dm-work的dump文件中删除这两条记录后，同步正常了。难道是某个地方的长度用了uint16，导致不支持大于65535的字段？

[dba-kit (张天师)]

额，不是BUG，是下游数据库参数配置问题。在测试用DM同步是不是可以做到MySQL → MySQL的同步，就临时用docker镜像起了一个，默认配置的max_allowed_packet是4194304，而这两条记录都是超过4M的，所以插入失败了。
调整max_allowed_packet到1GB后，这个表也能导入成功了

[dba-kit (张天师)]

不过奇怪的是，返回的报错没有错误码，只是告诉重试失败