收到實(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)。