使用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
（5.7還不是很成熟啊.....）