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

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

這是超過了大小被截斷觸發(fā)的 warning，然 后被同步抓取到從而出現(xiàn)同步中斷。第一想到的是對userid進行GROUP_CONCAT()后寫入到tb_create_users_every_day表的時候發(fā)生截斷，于是查 看tb_create_users_every_day的表定義的ids列的大小，發(fā)現(xiàn)是longblob列，基本排除這個猜想，如圖2所示。

排查了表列截斷的問題，根據(jù)業(yè)務的SQL，先將對應的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 驗證發(fā)現(xiàn)超過1024

查看一下warning的報錯，推斷應該是由于超過GROUP_CONCAT()的最大限制導致的截斷，如圖4所示。

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

通過分析問題已經(jīng)很清晰了，明顯是GROUP_CONCAT()函數(shù)有限制最大為1024導致的截斷，于是在服務器中搜索對應的group和concat字段的變量，人品大爆發(fā)，一下就把對應的變量揪了出來。

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