收到實(shí)例主從異常告警后登錄服務(wù)器查看發(fā)現(xiàn)是由于GROUP_CONCAT()函數(shù)導(dǎo)致同步異常,如圖1所示。
這是超過了大小被截斷觸發(fā)的 warning,然 后被同步抓取到從而出現(xiàn)同步中斷。第一想到的是對userid進(jìn)行GROUP_CONCAT()后寫入到tb_create_users_every_day表的時候發(fā)生截斷,于是查 看tb_create_users_every_day的表定義的ids列的大小,發(fā)現(xiàn)是longblob列,基本排除這個猜想,如圖2所示。
排查了表列截斷的問題,根據(jù)業(yè)務(wù)的SQL,先將對應(yīng)的select抽出來,并統(tǒng)計一下每一個GROUP_CONCAT(userid)的長度,發(fā)現(xiàn)最大的為1024,并且有個warning,如圖3所示。
圖1 函數(shù)同步異常
圖2 發(fā)現(xiàn)longblob列
圖3 發(fā)現(xiàn)長度1024和warning
圖4 warning報錯
圖5 驗(yàn)證發(fā)現(xiàn)超過1024
查看一下warning的報錯,推斷應(yīng)該是由于超過GROUP_CONCAT()的最大限制導(dǎo)致的截斷,如圖4所示。
為了驗(yàn)證這個猜想,查詢一下targetTime為1415894400000的userid通過GROUP_CONCAT()后最大是多少,于是寫了如下簡單的SQL進(jìn)行驗(yàn)證,發(fā)現(xiàn)確實(shí)超過了1024,如圖5所示。
通過分析問題已經(jīng)很清晰了,明顯是GROUP_CONCAT()函數(shù)有限制最大為1024導(dǎo)致的截斷,于是在服務(wù)器中搜索對應(yīng)的group和concat字段的變量,人品大爆發(fā),一下就把對應(yīng)的變量揪了出來。
最后直接將主從的group_concat_max_len參數(shù)設(shè)為10240,并重啟同步線程,觀察slave狀態(tài)。