Chinaunix首页 | 论坛 | 博客
  • 博客访问: 7177944
  • 博文数量: 368
  • 博客积分: 9600
  • 博客等级: 上校
  • 技术积分: 18875
  • 用 户 组: 普通用户
  • 注册时间: 2009-01-01 00:00
文章分类

全部博文(368)

文章存档

2017年(9)

2016年(19)

2015年(3)

2014年(6)

2013年(8)

2012年(78)

2011年(66)

2010年(135)

2009年(44)

分类: Mysql/postgreSQL

2014-12-01 23:08:56

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()的最大限制导致的截断。

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

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

 

问题解决

找到问题之后就好解决了,直接将主从的group_concat_max_len参数设置为10240,并重启同步线程,如下图所示:

观察slave的状态彻底OK了。

阅读(8279) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

woaini20002112015-05-15 11:37:40

为啥图片都看不到了