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

前两天某项目客户反馈系统卡顿，同事开始接手处理，对 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)性能大幅下降？

MySQL

卡顿

复制

slave

5 条回复 • 2023-10-10 08:35:19 +08:00

tool2d

2023-10-09 16:03:29 +08:00

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

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

S4msara

2023-10-09 16:13:14 +08:00

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

lvzhiqiang

2023-10-09 16:31:46 +08:00

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

S4msara

2023-10-09 16:33:37 +08:00

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

lvzhiqiang

2023-10-10 08:35:19 +08:00

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