网站存在原理,高校网站模板,广州网站建设工作室,wordpress 订阅号 采集记一次MySQL宕机恢复过程 简介#xff1a;一个业务数据库疏于运维管理#xff0c;突然在今天崩溃宕机了#xff0c;真是让人抓狂#xff0c;上面也不知道积累了多久的数据#xff0c;平时也没有定期做好备份#xff0c;这下岂不是瞎了啊#xff0c;经过不断的收集信息和…记一次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_recovery2的时候mysql服务启动起来了但这个模式下数据无法操作于是我结合mysqldump命令对数据库进行备份使用这种方式把正常运行的服务都备份下来然后修改配置文件切换数据库空间服务正常启动之后恢复服务器账号和使用备份下来的sql逐个恢复数据库。 总结这次庆幸的是问题发生在业务库最终数据也全部恢复了这里敲响一个警钟就是数据库一定要定期做好全量备份这样才能在事故发生的时候能够及时恢复服务不影响业务运行另外就是处理问题不要依托现有经验先入为主这样可能导致走很多弯路而应该直接定位到问题主要原因之后再根据经验解决问题。
