下文内容主要给大家带来使用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半同步复制时发现主库报错怎么处理，如果大家还有更多需要了解的可以持续关注我们的行业推新，如需获取专业解答，可在官网联系售前售后的，希望该文章可给大家带来一定的知识更新。