group_concat函数导致的主从同步异常的问题总结
今天在处理一个group_concat函数导致的主从异常的问题，排查过程比较简单，不过第一次遇到这个问题记录一下排查的思路，后面如果再遇到其他的由于参数导致的主从异常就知道如何排查了。
问题现象
收到实例主从异常告警后登录服务器查看发现是由于GROUP_CONCAT()函数导致同步异常，如下截图所示：
问题分析排查
看意思是超过了大小被截断触发的warning，然后被同步抓取到从而出现同步中断。第一想到的是对userid进行GROUP_CONCAT()后写入到tb_create_users_every_day表的时候发生截断，于是查看tb_create_users_every_day的表定义的ids列的大小，发现是longblob列，基本排查这个猜想。
排查了表列截断的问题，根据业务的SQL，先将对应的select抽出来，并统计一下每一个GROUP_CONCAT(userid)的长度，发现最大的为1024，并且有个warning，如下截图所示：
查看一下warning的报错，发现应该是由于超过GROUP_CONCAT()的最大限制导致的截断。
为了验证这个猜想，查询一下targetTime为1415894400000的userid通过GROUP_CONCAT()后最大是多少，于是写了如下简单的SQL进行验证，发现确实超过了1024，如下图所示：
通过分析问题已经很清晰了，明显是GROUP_CONCAT()函数有限制最大为1024导致的截断，于是在服务器中搜索对应的group和concat字段的变量，人品大爆发，一下就把对应的变量揪了出来。
问题解决
找到问题之后就好解决了，直接将主从的group_concat_max_len参数设置为10240，并重启同步线程，如下图所示：
观察slave的状态彻底OK了。