使用MySQL5.7半同步復制時發現主庫報錯怎么處理

下文內容主要給大家帶來使用MySQL5.7半同步復制時發現主庫報錯怎么處理，這里所講到的知識，與書籍略有不同，都是億速云專業技術人員在與用戶接觸過程中，總結出來的，具有一定的經驗分享價值，希望給廣大讀者帶來幫助。

使用MySQL5.7的半同步復制時，發現主庫一個簡單的寫操作會執行1s，通過show profile分析是半同步導致。
查看主從日志，發現報錯如下：
主庫報錯：

2018-05-21T05:34:06.955592Z 0 [ERROR] /usr/local/mysql-5.7.21-linux-glibc2.12-x86_64/bin/mysqld: Got an error reading communication packets
2018-05-21T05:34:06.967776Z 21 [Note] While initializing dump thread for slave with UUID <26b1280d-2125-11e8-b5a8-005056ac3676>, found a zombie dump thread with the same UUID. Master is killing the zombie dump thread(20).
2018-05-21T05:34:06.967864Z 20 [Note] Stop semi-sync binlog_dump to slave (server_id: 12233306)
2018-05-21T05:34:06.967954Z 21 [Note] Start binlog_dump to master_thread_id(21) slave_server(12233306), pos(mysql-bin.000004, 484)
2018-05-21T05:34:07.957450Z 21 [Note] Start semi-sync binlog_dump to slave (server_id: 12233306), pos(mysql-bin.000004, 484)

從庫報錯

2018-05-21T05:54:29.787788Z 4 [ERROR] Error reading packet from server for channel '': Lost connection to MySQL server during query (server_errno=2013)
2018-05-21T05:54:29.787880Z 4 [Note] Slave I/O thread: Failed reading log event, reconnecting to retry, log 'mysql-bin.000004' at position 484 for channel ''
2018-05-21T05:54:29.787908Z 4 [Warning] Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the 'START SLAVE Syntax' in the MySQL Manual for more information.

經過初步分析，只有半同步才會觸發該問題，那么應該是從庫返回的ACK包出現bug，主庫無法解析，最后經過調整參數，確認半同步下，只有從庫開啟參數slave_compressed_protocol才會出現該問題，官方默認參數為OFF。
即出問題的條件，a.5.7   b.從庫slave_compressed_protocol=1 c.主從半同步
該問題確認為5.7bug，已經有人提了，不過網上的案例還是很少。
https://bugs.mysql.com/bug.php?id=85382

上實驗圖：
正常

觸發bug

解決辦法：從庫設置slave_compressed_protocol=0

對于以上關于使用MySQL5.7半同步復制時發現主庫報錯怎么處理，如果大家還有更多需要了解的可以持續關注我們億速云的行業推新，如需獲取專業解答，可在官網聯系售前售后的，希望該文章可給大家帶來一定的知識更新。