【十四】记一次MySQL宕机恢复过程,MySQL INNODB 损坏恢复

记一次MySQL宕机恢复过程

**简介:**一个业务数据库疏于运维管理,突然在今天崩溃宕机了,真是让人抓狂,上面也不知道积累了多久的数据,平时也没有定期做好备份,这下岂不是瞎了啊,经过不断的收集信息和尝试最终处理好了,在此记录一下。

处理过程

1、发现数据库登录不上,开始对数据库服务进行排查,报错信息如下

查询服务器状态,发现服务没有启动

systemctl status mysqld

尝试重启服务,还是起不来

systemctl restart mysqld

2、服务还是起不来于是想了是不是到数据目录把损坏的库删掉就好了

然后开始报如下错误: ​​​​​​​

Cannot open datafile for read-only: './dxh_sys/vendorUser.ibd' OS error: 71

Could not find a valid tablespace file for 'mysql/innodb_index_stats'

3、删除损坏方库还是无法重启,然后想着重新恢复该库文件

于是把数据库数据目录切换到新目录mysql2,使用systemctl restart mysqld把服务启动起来,在该空间建立损坏的数据库,使用cp -r /mysqldata/mysql2/数据库目录 /mysqldata/mysql/,把正常的库文件复制到原来的库目录到my.cnf中把数据库目录切换回来,再进行重启,结果发现还是不太行,到这里感觉有点崩溃了,感觉理论上没啥问题啊!

4、冷静一会之后在日志继续找一下有用的信息,发现了:

找到了关键的一句:mysql Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB

到这里开始认识了 innodb_force_recovery 参数,有1-6个级别,分别描述如下:

Mode 1 当发现一个损坏的数据页时不让MYSQL实例自动崩溃

Mode 2 不启用后台操作

Mode 3 不尝试 回滚事务

Mode 4 不计算状态也不应用buffer change

Mode 5 在启动过程中不去关心undo log

Mode 6 在启动过程中不关心重做日志ib_logfiles, 不去做前滚

这里级别越高,数据丢失可能性越高,于是我从第一级别开始尝试,当设置innodb_force_recovery=2的时候,mysql服务启动起来了,但这个模式下数据无法操作,于是我结合mysqldump命令对数据库进行备份,使用这种方式把正常运行的服务都备份下来,然后修改配置文件切换数据库空间,服务正常启动之后,恢复服务器账号和使用备份下来的sql逐个恢复数据库。

**总结:**这次庆幸的是问题发生在业务库,最终数据也全部恢复了,这里敲响一个警钟就是数据库一定要定期做好全量备份,这样才能在事故发生的时候能够及时恢复服务不影响业务运行,另外就是处理问题不要依托现有经验先入为主,这样可能导致走很多弯路,而应该直接定位到问题主要原因之后再根据经验解决问题。

相关推荐
KellenKellenHao4 小时前
MySQL数据库主从复制
数据库·mysql
一只fish5 小时前
MySQL 8.0 OCP 1Z0-908 题目解析(16)
数据库·mysql
叁沐6 小时前
MySQL 07 行锁功过:怎么减少行锁对性能的影响?
mysql
Java烘焙师7 小时前
架构师必备:业务扩展模式选型
mysql·elasticsearch·架构·hbase·多维度查询
飞翔的佩奇7 小时前
Java项目:基于SSM框架实现的忘忧小区物业管理系统【ssm+B/S架构+源码+数据库+毕业论文+开题报告】
java·数据库·mysql·vue·毕业设计·ssm框架·小区物业管理系统
@Ryan Ding7 小时前
MySQL主从复制与读写分离概述
android·mysql·adb
feifeigo12314 小时前
升级到MySQL 8.4,MySQL启动报错:io_setup() failed with EAGAIN
数据库·mysql·adb
A__tao19 小时前
一键将 SQL 转为 Java 实体类,全面支持 MySQL / PostgreSQL / Oracle!
java·sql·mysql
一只fish19 小时前
MySQL 8.0 OCP 1Z0-908 题目解析(17)
数据库·mysql
叁沐21 小时前
MySQL 06 全局锁和表锁:给表加个字段怎么有这么多阻碍?
mysql