主从复制发生错误长时间未处理导致主服务器性能降低

[S4msara]

背景

前两天某项目客户反馈系统卡顿，同事开始接手处理，对 MySQL 配置进行了缓存及线程部分参数的调整，直至昨天下午仍未解决卡顿问题。昨天下午我开始介入，复盘近期该项目所作的变更及发生的事件，想起在问题发生前几天同时反馈主从复制失效，当时上服务器执行show slave status看到 Error Code: 1677 ，当时综合考虑客户系统使用情况，决定暂不处理，也并未执行stop slave暂停复制。解决卡顿问题的第一件事就是先确定问题是发生在哪个环节，由于是全面卡顿，于是用 Arthas 先 trace 了一个较复杂的接口，发现耗时 99%都是集中在数据库访问，至此已经确认问题是出现在数据库，于是尝试关闭主从复制：stop slave并修改主服务器配置文件，将主从复制相关配置注释掉（想着晚上客户停用系统了再重新配置，于是把 binlog 也通过purge删掉了），重启 MySQL ，重启项目，暴力测试并观察了半个小时，未发生卡顿问题。

今早又出现卡顿，检查发现主从复制又报错了，stop slave没一会儿就恢复了……

---

环境说明

两套系统和 MySQL(主)部署在同一台服务器(Windows Server)，同局域网还有一台服务器部署了 MySQL(从)用于数据备份。

---

疑问

翻看 MySQL Reference Manual ，里面写基于 binlog 的复制是异步的，如图：

因此我认为主从复制线程不影响读写线程。

于是我开上到网上找原因，有相关文章提到 binlog 过长占用磁盘而影响到了 IO 性能，这个可能性似乎不大，我在昨天删除 binlog 文件前还看了一下文件大小，基本在 500kb 以下。

所以想请教大家，是什么原因导致 MySQL 主从复制在发生错误时导致了对 master 的查询(Query)性能大幅下降？

[tool2d]

Error Code: 1677 ，一般来说就两个原因，一个是数据类型被改动了。另一个是非法关机，导致数据库有小部分损坏，需要手动修复一下数据库。

你说查询慢，我猜测可能是断电引起的。

[S4msara]

@tool2d 1677 的原因是 cannot be converted from type 'varchar(2000)' to 'varchar(255)'，是因为当时在主库执行建表语句的时候未指定字符集，而主服务器配置了默认的字符集是 utf8mb4 ，从服务器配置的默认字符集是 utf8 。服务器近期未断电维护。

[lvzhiqiang]

是物理还是虚拟机，先监测 IO 和 CPU 使用率看看，特别是 IO 读写耗时

[S4msara]

@lvzhiqiang 物理机，在异常发生时查看了 IO 和 CPU 负载情况，均正常。

[lvzhiqiang]

@S4msara iowait 这个这个 值，结合 io 利用率看看。