记一次一波三折的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;
由于之前从库数据已经同步完成，此时主库同步速度很快就完成了。
复制