ITPub博客

首页 > 数据库 > MySQL > 记一次一波三折的Mysql故障处理

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

原创 MySQL 作者:chenoracle 时间:2021-10-28 12:51:34 1 删除 编辑

环境:

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#####


来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/29785807/viewspace-2839459/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
Oracle ACE、OCMU 用户组成员、Oracle 11g OCM、微信公众号"IT小Chen"

注册时间:2014-08-05

  • 博文量
    642
  • 访问量
    1633108