排查group_concat函數(shù)主從異常

收到實(shí)例主從異常告警后登錄服務(wù)器查看發(fā)現(xiàn)是由于GROUP_CONCAT()函數(shù)導(dǎo)致同步異常，如圖1所示。

這是超過了大小被截?cái)嘤|發(fā)的 warning，然 后被同步抓取到從而出現(xiàn)同步中斷。第一想到的是對(duì)userid進(jìn)行GROUP_CONCAT()后寫入到tb_create_users_every_day表的時(shí)候發(fā)生截?cái)啵谑遣?看tb_create_users_every_day的表定義的ids列的大小，發(fā)現(xiàn)是longblob列，基本排除這個(gè)猜想，如圖2所示。

排查了表列截?cái)嗟膯栴}，根據(jù)業(yè)務(wù)的SQL，先將對(duì)應(yīng)的select抽出來，并統(tǒng)計(jì)一下每一個(gè)GROUP_CONCAT(userid)的長(zhǎng)度，發(fā)現(xiàn)最大的為1024，并且有個(gè)warning，如圖3所示。

圖1 函數(shù)同步異常

圖2 發(fā)現(xiàn)longblob列

圖3 發(fā)現(xiàn)長(zhǎng)度1024和warning

圖4 warning報(bào)錯(cuò)

圖5 驗(yàn)證發(fā)現(xiàn)超過1024

查看一下warning的報(bào)錯(cuò)，推斷應(yīng)該是由于超過GROUP_CONCAT()的最大限制導(dǎo)致的截?cái)啵鐖D4所示。

為了驗(yàn)證這個(gè)猜想，查詢一下targetTime為1415894400000的userid通過GROUP_CONCAT()后最大是多少，于是寫了如下簡(jiǎn)單的SQL進(jìn)行驗(yàn)證，發(fā)現(xiàn)確實(shí)超過了1024，如圖5所示。

通過分析問題已經(jīng)很清晰了，明顯是GROUP_CONCAT()函數(shù)有限制最大為1024導(dǎo)致的截?cái)啵谑窃诜?wù)器中搜索對(duì)應(yīng)的group和concat字段的變量，人品大爆發(fā)，一下就把對(duì)應(yīng)的變量揪了出來。

最后直接將主從的group_concat_max_len參數(shù)設(shè)為10240，并重啟同步線程，觀察slave狀態(tài)。