排坑日记之批量从库IO进程停止处理

最新推荐文章于 2023-03-20 10:25:49 发布

gjc592

最新推荐文章于 2023-03-20 10:25:49 发布

阅读量873

点赞数

本文链接：https://blog.csdn.net/gjc592/article/details/106543118

版权

早上刚睁眼，看到了一堆数据库告警的短信,其中一个内容如下：

Problem started at 05:02:58 on 2019.10.12Problem name: Slave is stopped on 192.168.56.31:3306Host: 192.168.56.31Severity: High

眼看这是刚从其他DBA交接过来的数据库,不敢怠慢,立马起来查看从库日志信息如下：

2019-10-12T05:01:16.506540+08:00 1 [Note] Slave I/O thread killed while reading event for channel ''2019-10-12T05:01:16.506605+08:00 1 [Note] Slave I/O thread exiting for channel '', read up to log 'mybinlog.001265', position 388024306
即非正常停止。

再登录主库机器查看主库错误日志，信息如下

2019-10-12T05:01:59.414412+08:00 373818 [Note] Aborted connection 373818 to db: 'unconnected' user: 'repl' host: '192.168.56.31' (failed on flush_net())2019-10-12T05:01:59.414424+08:00 407536 [Note] Aborted connection 407536 to db: 'unconnected' user: 'repl' host: '192.168.56.49' (failed on flush_net())
从主库日志可以看出，2个从库是主库主动断开的,而给出的信息也指出了原因failed on flush_net()。另外还有很多 Got timeout reading communication packets 的信息。

因为mysqld是一个多线程的C/S架构的网络应用，主从同步及数据的读取是通过网络来读写数据，所以可能会出现写数据失败的情况。如果mysql的错误日志中出现failed on flush_net()这类的错误时，即说明主库的mysqld在向客户端发送网络包时失败导致的。在主从这种复制场景下则说明是复制过程中master向slave推送binlog写网络数据包失败。
出现此类问题的可能是TCP拥堵等情况造成的,因此建议生产环境的操作系统参数进行调整。可参考如下方式修改

/**  在 /etc/sysctl.conf 文件目录末尾增加如下参数 */


kernel.sem=250 32000 100 128
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30


/** 使参数生效  */
sysctl -p

生产环境涉及MySQL数据的操作系统部分参数需要根据情况进行调整,同时MySQL参数也需要根据操作系统的配置情况及实际网络情况进行调整，这样数据库才能稳定、高效的运行。

本次优化的参数在之前MySQL部署时有提及,需要了解的同学可以回看，也可以与我沟通，谢谢。

精彩推荐：