排查group_concat函数主从异常

收到实例主从异常告警后登录服务器查看发现是由于GROUP_CONCAT()函数导致同步异常，如图1所示。

这是超过了大小被截断触发的 warning，然 后被同步抓取到从而出现同步中断。第一想到的是对userid进行GROUP_CONCAT()后写入到tb_create_users_every_day表的时候发生截断，于是查 看tb_create_users_every_day的表定义的ids列的大小，发现是longblob列，基本排除这个猜想，如图2所示。

排查了表列截断的问题，根据业务的SQL，先将对应的select抽出来，并统计一下每一个GROUP_CONCAT(userid)的长度，发现最大的为1024，并且有个warning，如图3所示。

图1 函数同步异常

图2 发现longblob列

图3 发现长度1024和warning

图4 warning报错

图5 验证发现超过1024

查看一下warning的报错，推断应该是由于超过GROUP_CONCAT()的最大限制导致的截断，如图4所示。

为了验证这个猜想，查询一下targetTime为1415894400000的userid通过GROUP_CONCAT()后最大是多少，于是写了如下简单的SQL进行验证，发现确实超过了1024，如图5所示。

通过分析问题已经很清晰了，明显是GROUP_CONCAT()函数有限制最大为1024导致的截断，于是在服务器中搜索对应的group和concat字段的变量，人品大爆发，一下就把对应的变量揪了出来。

最后直接将主从的group_concat_max_len参数设为10240，并重启同步线程，观察slave状态。