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