MySQL数据库页损坏怎么办，innodb_force_recovery参数帮你解决问题

有些时候，你的MySQL数据库是单机，没有主从和高可用，如果宕机，或者其它异常情况，导致你的ibd文件损坏，这个时候，你的MySQL数据库实例无法启动了，而你又需要导出MySQL数据库中关键数据，这时innodb_force_recovery参数能救你一命，首先你需要了解innodb_force_recovery作用。

innodb_force_recovery默认为0，innodb_force_recovery可以设置1到6。较大的值包括较小值所有功能。例如，3包含1和2的所有功能。

设置innodb_force_recovery值等于或小于3，MySQL数据库的表是相对安全，此时仅丢失了损坏的单个页面上的某些数据。设置成4或更大的值是非常危险的，此时可能会导致页数据永久损坏。

为保护数据，InnoDB会在innodb_force_recovery大于 0 时阻止INSERT，UPDATE或DELETE操作。innodb_force_recovery设置为 4 或更大时会将InnoDB置于只读模式。

下面来介绍一下innodb_force_recovery设置各种值的作用
innodb_force_recovery=1 ( SRV_FORCE_IGNORE_CORRUPT )
此时MySQL数据库即使检测到损坏的page也可以运行。可以尝试使SELECT * FROM tab跳过损坏的索引记录和页面，可以恢复没有损坏的业务数据。

innodb_force_recovery=2 ( SRV_FORCE_NO_BACKGROUND )
阻止master thread和任何purge threads运行。如果在purge操作期间发生崩溃，则此恢复值将阻止它。

innodb_force_recovery=3 ( SRV_FORCE_NO_TRX_UNDO )
在crash recovery之后不执行事务rollbacks。

innodb_force_recovery=4 ( SRV_FORCE_NO_IBUF_MERGE )
防止insert buffer合并操作，不计算 tablestatistics。此时可能会永久损坏数据文件，需要删除并重新创建所有二级索引。

innodb_force_recovery=5 ( SRV_FORCE_NO_UNDO_LOG_SCAN )
启动数据库时不检查undo logs：InnoDB甚至将未完成的事务都视为已提交。此值可能会永久损坏数据文件。将InnoDB设置为只读。

innodb_force_recovery=6 ( SRV_FORCE_NO_LOG_REDO )
不进行与恢复有关的redo log前滚。此值可能会永久损坏数据文件。使数据库页面处于过时状态，从而可能导致 B 树和其他数据库结构遭受更多破坏。将InnoDB设置为只读。

创建模拟表

mysql> show create table t_test\G;
*************************** 1. row ***************************Table: t_test
Create Table: CREATE TABLE `t_test` (`id` int(10) unsigned NOT NULL AUTO_INCREMENT,`k` int(12) unsigned NOT NULL DEFAULT '0',`c` char(120) NOT NULL DEFAULT '',`pad` char(60) NOT NULL DEFAULT '',`paymont` double(10,2) DEFAULT NULL,PRIMARY KEY (`id`),KEY `k_1` (`k`)
) ENGINE=InnoDB AUTO_INCREMENT=10002 DEFAULT CHARSET=utf8 MAX_ROWS=1000000
1 row in set (0.00 sec)mysql> select * from t_test;
+----+---------+-------------+-------------+-----------+
| id | k       | c           | pad         | paymont   |
+----+---------+-------------+-------------+-----------+
|  1 | 4992833 | 83868641912 | 67847967377 | 200000.00 |
|  2 | 5019684 | 38014276128 | 23183251411 |      NULL |
|  3 | 5042604 | 33973744704 | 38615512647 |      NULL |
|  4 | 5020133 | 37002370280 | 63947013338 |      NULL |
|  5 | 4998122 | 44257470806 | 34551750492 |      NULL |
|  6 | 5005844 | 37216201353 | 05161542529 |      NULL |
|  7 | 5013709 | 33071042495 | 91798303270 |      NULL |
|  8 | 4999376 | 73754818686 | 76460662325 |      NULL |
|  9 | 5272683 | 26482547570 | 30508501104 |      NULL |
| 10 | 5033749 | 05677017559 | 29489382504 |      NULL |
| 11 | 5495590 | 69916792160 | 87387995487 |      NULL |
| 12 | 4877585 | 06636928111 | 89292458800 |      NULL |
+----+---------+-------------+-------------+-----------+
12 rows in set (0.00 sec)

模拟表的页损坏
要模拟t_test表页损坏，其实很简单，可以通过vi工具，在t_test.ibd文件开始行添加N个！就可以

重启MySQL服务
模拟损坏之后，就重启MySQL数据库实例，同时看MySQL数据库错误日志

2020-09-01T12:58:25.207448Z 0 [Note] InnoDB: Loading buffer pool(s) from /u02/log/3308/iblog/ib_buffer_pool
2020-09-01T12:58:25.209575Z 0 [ERROR] InnoDB: Space ID in fsp header is 134217728, but in the page header it is 660067840.
2020-09-01T12:58:25.331762Z 0 [ERROR] [FATAL] InnoDB: Tablespace id is 48 in the data dictionary but in file ./sbtest/t_test.ibd it is 18446744073709551615!
2020-09-01 20:58:25 0x7ffb8d022700  InnoDB: Assertion failure in thread 140718379247360 in file ut0ut.cc line 942
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
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.7/en/forcing-innodb-recovery.htmlInnoDB: about forcing recovery.

看到没，此时数据库实例已经无法正常启动了，原因是因为t_test.ibd文件头部记录的Tablespace id与数据字典不一致。怎么办

设置innodb_force_recovery
因为此时t_test.ibd文件头部记录的Tablespace id与数据字典不一致，只能在my.cnf文件中添加innodb_force_recovery=4，然后启动MySQL数据库实例

mysql> show tables;
+------------------+
| Tables_in_sbtest |
+------------------+
| sbtest1          |
| t_pay_test       |
| t_test           |
+------------------+
3 rows in set (0.00 sec)mysql> select * from t_test;
ERROR 1812 (HY000): Tablespace is missing for table `sbtest`.`t_test`.
mysql>
mysql> drop table t_test;Query OK, 0 rows affected (0.02 sec)

由于此时已经无法识别t_test.ibd文件了，此时只能drop掉t_test表了。
如果只是损坏了页数据，可以用下面的sql语句恢复业务数据

insert ignore into t_test_recovery select * from t_test limit 5;
insert ignore into t_test_recovery select * from t_test limit 10;

MySQL数据库页损坏怎么办，innodb_force_recovery参数帮你解决问题
https://mp.weixin.qq.com/s/l6KZP4glnwwuDQxU98A0Mw

MySQL数据库页损坏怎么办，innodb_force_recovery参数帮你解决问题相关推荐

什么是页损坏 mysql_MySQL数据库页损坏怎么办，innodb_force_recovery参数帮你解决问题...
有些时候,你的MySQL数据库是单机,没有主从和高可用,如果宕机,或者其它异常情况,导致你的ibd文件损坏,这个时候,你的MySQL数据库实例无法启动了,而你又需要导出MySQL数据库中关键数据,这时 ...
MySQL恢复利用innodb_force_recovery修复MySQL数据页损坏
现象:启动MySQL服务时报1067错误,服务无法启动. 查看xxx.err错误日志发现有数据页损坏信息: InnoDB: Database page corruption on disk or a ...
从删库到跑路or恢复，记一次MySQL数据库文件损坏恢复经历
一. 前言 2018年5月28日,北京晴有轻度沙尘暴. 坐上公交车走在上班的路上,想起老罗经常说起的一句话:想成盛田昭夫时代的索尼,想成乔布斯时代的苹果,于是继续研读着 <日本制造:盛田昭夫的日 ...
mysql数据库表损坏修复方法（适用虚拟主机）
1.主机控制面板修复在虚拟主机控制面板或独立控制面板中点击"数据库",用控制面板中提供的"修复数据库"功能,可以在线修复. 2.使用phpmyadmin进行修 ...
mysql数据库文件损坏的原因_MySQL数据库文件损坏如何解决
以下的文章主要是介绍MySQL数据库文件在坏掉的情况下通过二进值日志对其进行恢复的实际操作方案,本文主要是从造成MySQL数据库文件在坏掉的原理讲起的,以下就是文章的主要内容描述. 一.场景 1.你使 ...
记录一次mysql数据库文件损坏导致数据库崩溃
表现: 服务器数据库查询很慢,莫名数据库服务崩溃问题排查过程: 按照网上操作,配置my.ini ,添加error-log参数,重启mysql,查看错误日志按照错误日志内容,搜索可能的错误问题比如 ...
Linux 文件系统引起的云盘文件系统异常导致 MySQL 数据页损坏事故恢复复盘
事故的起因是因为当我访问某个数据库的某个表的时候,MySQL 立即出现崩溃并且去查看 MySQL 的错误日志出现类似信息 2019-05-09T05:52:19.232564Z 1027 [ERROR ...
linux崩溃mysql导出_Linux 文件系统引起的云盘文件系统异常导致 MySQL 数据页损坏事故恢复复盘...
事故的起因是因为当我访问某个数据库的某个表的时候,MySQL 立即出现崩溃并且去查看 MySQL 的错误日志出现类似信息 2019-05-09T05:52:19.232564Z 1027 [ERROR ...
MySQL数据库性能优化的关键参数(转)
我们在进行数据库管理和开发中经常会遇到性能问题,这就涉及到MySQL的性能优化.通过在网络上查找资料和笔者自己的尝试,我认为以下系统参数是比较关键的: 关键参数一:back_log 要求 MySQL ...

MySQL数据库页损坏怎么办，innodb_force_recovery参数帮你解决问题

MySQL数据库页损坏怎么办，innodb_force_recovery参数帮你解决问题相关推荐

最新文章

热门文章