20211028-记一次一波三折的Mysql故障处理

环境：

Mysql 8.0.24 双主+keepalived

问题现象：

同事反馈某套mysql数据库连接失败，尝试重启数据库无法启动。

问题分析：

远程登录服务器，尝试检查error日志，发现cd无法进入到mysql目录，ls和df命令无返回结果，卡住不动。
检查历史命令，发现近期有调整过本地路由。

问题原因：

由于mysql目录是通过nas存储挂载到本地，由于本地路由的调整，
导致数据库服务器和NAS网络不通，
最终导致mysql目录挂载失败，无法读取到mysql对应文件。

解决方案：

联系同事改回原路由配置，并同时重启了服务器。

问题再起：

同事重启服务器后反馈数据库可以连接了，但是没数据了，库也没了？
远程登录到数据库服务器，发现当前启动的mysqld进程，
不是手动安装的mysql,而是系统自带的mysql，应该启动的是手动安装的mysql。

ps -ef|grep mysql

检查当前mysql状态

systemctl status mysqld.service

停止系统自带mysql服务

systemctl stop mysqld.service

禁用开机自启动

systemctl disable mysqld.service 

手动启动mysql

###mysqld --defaults-file=/etc/my.cnf --user=mysql &

启动keepalived

systemctl start keepalived.service

同事反馈可以正常使用了。

问题再再起：

过了一周后，同事反馈从库数据不对，少了很多新数据。
登录服务器检查发现slave进程居然没启动。

mysql> show slave status \G;

之前记得mysql启动时会自动启动salve进程的，难道8.0.24版本默认是不启动slave进程？
由于对应系统之前还没有上线，之前在启动数据库后也没有仔细检查主从同步情况。
检查my.cnf配置，发现设置了skip_slave_start，不自动启动slave。

cat /etc/my.cnf|grep skip
skip-slave-start=1

mysql -uroot -p
Enter password: 

mysql> show variables like '%skip_slave_start%';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| skip_slave_start | ON    |
+------------------+-------+

1 row in set (0.01 sec)

数据库架构是双主架构，两台mysql均没有启动slave。

解决过程如下：

虽然当前是双主架构，但vip只存在一个节点上，也就是只有一个节点对外提供服务，

使用双主+keepalived的架构主要是为了故障自动切换功能。
所以两套mysql还是区分主从的。

1.检查主从数据库binlog保留时间。
2.检查需要的binglog是否存在。
3.先恢复从库slave。
4.待从库slave正常后，在恢复主库的slave。

1.检查主从数据库binlog保留时间。
查看binlog过期时间为30天。

mysql> show variables like 'binlog_expire_logs_seconds';
+----------------------------+---------+
| Variable_name              | Value   |
+----------------------------+---------+
| binlog_expire_logs_seconds | 2592000 |
+----------------------------+---------+
1 row in set (0.01 sec)

2.检查需要的binglog是否存在。
主从都需要检查。
需要mysql-bin.000007开始的binlog日志。

mysql> show slave status\G;
...
Master_Log_File: mysql-bin.000007

检查binlog日志无丢失

ls -lrth mysql-bin.*
-rw-r----- 1 mysql mysql 129K Oct 19 09:39 mysql-bin.000007
-rw-r----- 1 mysql mysql  259 Oct 19 09:51 mysql-bin.000008
-rw-r----- 1 mysql mysql  259 Oct 19 09:53 mysql-bin.000009
-rw-r----- 1 mysql mysql  283 Oct 19 09:54 mysql-bin.000010
-rw-r----- 1 mysql mysql  259 Oct 19 09:54 mysql-bin.000011
-rw-r----- 1 mysql mysql  270 Oct 19 09:54 mysql-bin.index
-rw-r----- 1 mysql mysql 225M Oct 28 09:55 mysql-bin.000012

3.先恢复从库slave。

mysql> start slave;
mysql> show slave status\G;

观察Slave_IO_Running和Slave_SQL_Running均由No变为Yes。
并且Seconds_Behind_Master值逐渐变小。

4.待从库slave正常后，在恢复主库的slave。
待从库Seconds_Behind_Master值变为0后，开始启动主库slave。

mysql> start slave;
mysql> show slave status\G;

由于之前从库数据已经同步完成，此时主库同步速度很快就完成了。

#####chenjuchao 20211028 12:50#####
欢迎关注我的公众号《IT小Chen》