早上刚睁眼，看到了一堆数据库告警的短信,其中一个内容如下：
Problem started at 05:02:58 on 2019.10.12
Problem name: Slave is stopped on 192.168.56.31:3306
Host: 192.168.56.31
Severity: 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部署时有提及,需要了解的同学可以回看，也可以与我沟通，谢谢。
想进一步沟通或想了解其他文章的同学可以关注我的微信公众号进行交流。
