vlambda博客
学习文章列表

前几天看到bug群有连续的问题，就感觉不对劲，第一反应是不是数据库有延迟，可没收到报警，监控系统上的Seconds_Behind_Master指标也没有问题。

后来同事给了sql语句，每台副库登陆查询了下，发现有一台数据查询不全，仔细看才发现Slave_IO_Running和Slave_SQL_Running指标都显示No，也就是说副库的同步进程没有开启。

start slave启动后解决问题，思考了下为什么会出现问题。查看mysqld的错误日志：

2022-09-26 12:08:44 17934 [Warning] Neither --relay-log nor --relay-log-index were used; so replication may break when this MySQL server acts as a slave and has his hostname changed!! Please use '--relay-log=xx-relay-bin' to avoid this problem.

也就是说mysqld被重启了，在这个过程中启动副库同步失败了。

那为什么mysqld被重启了呢？原因先不说，mysqld因为有mysqld_safe，在停止后自动重启了。

mysqld错误日志中也没有其它信息，比如mysqld怎么停止的，查看/var/log/message，显示：

slave1 kernel: mysqld invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0

说明mysqld因为内存问题，被内核杀了，其实内存是足够的。。。

通过另外一个指标发现，出现问题那个时间点服务器负载比较高，但瞬间负载就下来了。

通过这些问题，教训一就是需要通过多个指标衡量服务可用性；第二就是关键监控指标必须时刻通过IM提醒；第三就是监控指标阈值调高一点反而让人更关注，因为报警太多容易忽略；第四就是mysqld_safe和mysqld的错误日志是相通的。

参考：

• https://dev.mysql.com/doc/refman/5.6/en/error-log-unix.html

• https://dev.mysql.com/doc/refman/5.7/en/replication-howto-additionalslaves.html-

• https://www.digitalocean.com/community/tutorials/how-to-use-systemctl-to-manage-systemd-services-and-units