突发！某大厂机房掉电，MySQL数据库无法启动，紧急恢复过程...

作者：IT邦德
中国DBA联盟(ACDU)成员，10余年DBA工作经验，
Oracle、PostgreSQL ACE
CSDN博客专家及B站知名UP主，全网粉丝10万+
擅长主流Oracle、MySQL、PG、高斯及Greenplum备份恢复，
安装迁移，性能优化、故障应急处理
微信:jem_db
QQ交流群:587159446
公众号：IT邦德

前言

本次故障发生在机房掉电，服务器异常关机，影响了监控系统的后台的MariaDB及MySQL无法启动。

📣 1.故障现象

由于异常断电或者系统异常重启时MySQL
没有正常退出导致MySQL无法启动，启动时报错如下：

Version: ‘5.5.64-MariaDB’ socket: 
‘/var/lib/mysql/mysql.sock’ port: 3306 MariaDB Server
InnoDB: Failing assertion: addr.page == FIL_NULL || addr.boffset >= FIL_PAGE_DATA
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
20240527 10:54:24 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
To report this bug, see http://kb.askmonty.org/en/reporting-bugs
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

📣 2.故障分析

报错中给出了强制恢复数据的方式，
参考MySQL官网链接即可
http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html

通过设置innodb_force_recovery
参数不进行回滚才启动数据库。
因为监控数据，可以允许部分数据丢失，所以此种方式可行
innodb_force_recovery = 1

innodb_force_recovery的6个值含义如下：

1 (SRV_FORCE_IGNORE_CORRUPT)
即使服务器检测到损坏的页仍让它运行。
试图使SELECT* FROM tbl_name跳过损坏的索引记录和页，
这样有助于转储表。

2 (SRV_FORCE_NO_BACKGROUND)
阻止主线程和任何清除线程的运行。
如果崩溃会在清除操作中发生，该恢复值会阻止它。

3 (SRV_FORCE_NO_TRX_UNDO)
不要在崩溃恢复后运行事务回滚。

4 (SRV_FORCE_NO_IBUF_MERGE)
阻止插入缓冲合并操作。如果它们会导致崩溃，
不要做这些。不计算表统计。这个值可以永久损坏数据文件。
使用这个值后，准备号删除并重建所有辅助索引。

5 (SRV_FORCE_NO_UNDO_LOG_SCAN)
在启动数据库时不查看撤消日志：InnoDB将即使未完成的事务也作为已提交。
这个值可以永久损坏数据文件。

6 (SRV_FORCE_NO_LOG_REDO)
不要通过恢复对重做日志进行前滚。这个值可能永久损坏数据文件。
数据库页被留在一个陈旧的状态，
这反过来又可能带给B-trees和其它数据库结构更多的损坏。

📣 3.处理过程

✨ 3.1 设置恢复模式启动

vim /etc/my.cnf
添加配置项：
innodb_force_recovery = 1
innodb_purge_thread=0
注意：其中innodb_force_recovery后面的值设置为1
如果1还是不能启动，就再逐步增加为2/3/4等。
直到能启动mysql为止！！！
本次恢复我设置为3后才重启OK

启动成功后测试数据库连接：
mysql -uroot -proot;

✨ 3.2 备份全库数据

mysqldump -uroot -proot
–all-databases > all_mysql_backup.sql

✨ 3.3 删除mysql数据

删除mysql数据之前务必先stop mysql服务
systemctl stop mariadb
cp -r /var/lib/mysql/ /var/lib/mysql.bak
rm -rf /var/lib/mysql/*
重启mysql服务：
正常模式在启动mysql：
vim /etc/my.cnf
注释配置项：
#innodb_force_recovery = 1
#innodb_purge_thread=0
再重启：
systemctl restart mariadb

✨ 3.4.恢复数据

记住一定要先重置下密码：
mysqladmin -u root password root
使用之间备份的sql文件恢复数据：
mysql -uroot -proot
source /root/all_mysql_backup.sql
查看恢复好的数据，搞定~！

📣 4.技能拓展

✨ 4.1 忘记root密码的处理

systemctl stop mariadb
mysqld_safe --skip-grant-tables &
mysql -u root
FLUSH PRIVILEGES;
SET PASSWORD FOR ‘root’@‘%’ = PASSWORD(‘root’);

✨ 4.2 运维常用命令

查询所有数据的大小：
mysql> select concat(round(sum(data_length/1024/1024),2),‘MB’)
as data from information_schema.tables;

当前数据库实例的所有数据库及其容量大小：
select a.SCHEMA_NAME, a.DEFAULT_CHARACTER_SET_NAME,a.DEFAULT_COLLATION_NAME,
sum(table_rows) as ‘记录数’,
sum(truncate(data_length/1024/1024, 2)) as ‘数据容量(MB)’,
sum(truncate(index_length/1024/1024, 2)) as ‘索引容量(MB)’,
sum(truncate((data_length+index_length)/1024/1024, 2)) as ‘总大小(MB)’,
sum(truncate(max_data_length/1024/1024, 2)) as ‘最大值(MB)’,
sum(truncate(data_free/1024/1024, 2)) as ‘空闲空间(MB)’
from INFORMATION_SCHEMA.SCHEMATA a
left outer join information_schema.tables b
on a.SCHEMA_NAME=b.TABLE_SCHEMA
group by a.SCHEMA_NAME, a.DEFAULT_CHARACTER_SET_NAME,a.DEFAULT_COLLATION_NAME
order by sum(data_length) desc, sum(index_length) desc;

📣 5.总结

如果数据库服务器突然断电，尚未保存到磁盘的数据将会丢失。这可能包括尚未提交的事务、缓存中的数据以及正在进行的写操作。当服务器重新启动时，这些数据将无法恢复，可能导致数据不一致或数据丢失的情况,本次的紧急恢复过程，希望能帮助到大家