mysql5.7 X protocol_MySQL 5.7slave_compressed_protocol参数导致复制bug

使用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还不是很成熟啊.....)