MySQL数据库，当innodb表空间损坏时候，尝试启动数据库不成功，可以使用innodb_force_recovery参数进行强制启动
在主配置文件my.cnf中添加
innodb_force_recovery=6
-------------------------------------------
innodb_force_recovery参数解释：
innodb_force_recovery影响整个InnoDB存储引擎的恢复状况，默认值为0，表示当需要恢复时执行所有的恢复操作。
当不能进行有效的恢复操作时，mysql有可能无法启动，并记录下错误日志。
innodb_force_recovery可以设置为1-6,大的数字包含前面所有数字的影响。
当设置参数值大于0后，可以对表进行select,create,drop操作,但insert,update或者delete这类操作是不允许的。
1(SRV_FORCE_IGNORE_CORRUPT):忽略检查到的corrupt页
2(SRV_FORCE_NO_BACKGROUND):阻止主线程的运行，如主线程需要执行full purge操作，会导致crash
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):不执行前滚的操作。
-------------------------------------------------------------------
修复表空间受损的表：
数据起来后，innodb类型的表不能写操作，但可以读，此时对表做check，查找到异常的表，读取出来，导入到myisam表里面，drop原表
然后在my.cnf中去掉innodb_force_recovery的设置，重启mysql
把myisam表转成innodb表；
----------------------------------------------------------------------------------------------
innodb_force_recovery对mysql 宕机恢复影响
在关闭时，参数innodb_fast_shutdown影响着表的存储引擎为InnoDB的行为。
该参数取值为0、1、2
0 代表党MySql关闭时，InnoDB需要完成所有的full purge 和 merge insert buffer操作，这会需要一些时间。1 代表不需要完成上述的full purge ,merge insert buffer操作，但是在缓冲池的一些数据脏页还是会刷新到磁盘。2 代表不完成full purge ,merge insert buffer操作，也 不将缓冲池中的数据脏页写回磁盘，而是将日志都写入日志文件。这样不会有任何事物会丢失，但是Mysql数据库下次启动时，会执行recovery
参数Innodb_force_recovery影响了整个InnoDB存储引擎的恢复状况。默认0
测试：
环境：innodb_fast_shutdown = 2
innodb_flush_log_at_trx_commit = 2
sync_binlog = 0
innodb_force_recovery影响整个InnoDB存储引擎的恢复状况。默认为0，表示当需要恢复时执行所有的
恢复操作。当不能进行有效的恢复操作时，mysql有可能无法启动，并记录下错误日志。
innodb_force_recovery可以设置为1-6,大的数字包含前面所有数字的影响。
当设置参数值大于0后，可以对表进行select,create,drop操作,但insert,update或者delete这类操作
是不允许的。
1(SRV_FORCE_IGNORE_CORRUPT):忽略检查到的corrupt页。
2(SRV_FORCE_NO_BACKGROUND):阻止主线程的运行，如主线程需要执行full purge操作，会导致crash。
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):不执行前滚的操作。
测试一
破坏xbb5.ibd表
删除了数据页
innodb_force_recovery = 1-3 表不可用 报ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysqld.sock' 错误 innodb_force_recovery = 4-6 select * 可用，select count(*） 不准确 报ERROR 2013 (HY000): Lost connection to MySQL server during query错误
测试二
创建事务，不提交
root@test 04:32:32>begin; Query OK, 0 rows affected (0.01 sec) root@test 04:33:14>update test set b = b+100; Query OK, 9999 rows affected (0.18 sec) Rows matched: 9999 Changed: 9999 Warnings: 0
innodb_force_recovery =0 要检查回滚操作
130626 16:32:20 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... InnoDB: 1 transaction(s) which must be rolled back or cleaned up InnoDB: in total 9999 row operations to undo InnoDB: Trx id counter is 0 12544 InnoDB: Last MySQL binlog file position 0 920753, file name /vobiledata/mysqllog/mysql-bin.000245 InnoDB: Starting in background the rollback of uncommitted transactions 130626 16:32:21 InnoDB: Rolling back trx with id 0 12032, 9999 rows to undo InnoDB: Progress in percents: 1130626 16:32:21 InnoDB: Started; log sequence number 0 4330016 130626 16:32:21 [Note] Recovering after a crash using /vobiledata/mysqllog/mysql-bin 130626 16:32:21 [Note] Starting crash recovery... 130626 16:32:21 [Note] Crash recovery finished. 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97130626 16:32:21 [Note] Event Scheduler: Loaded 0 events 130626 16:32:21 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.1.57-log' socket: '/tmp/mysqld.sock' port: 3306 MySQL Community Server (GPL) 98 99 100 InnoDB: Rolling back of trx id 0 12032 completed 130626 16:32:21 InnoDB: Rollback of non-prepared transactions completed
如果回滚数据多，恢复就相对的慢
innodb_force_recovery =2 阻止主线程的运行，如主线程需要执行full purge操作，会导致crash。
InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... InnoDB: 1 transaction(s) which must be rolled back or cleaned up InnoDB: in total 9999 row operations to undo InnoDB: Trx id counter is 0 15616 InnoDB: Last MySQL binlog file position 0 920753, file name /vobiledata/mysqllog/mysql-bin.000245 InnoDB: Starting in background the rollback of uncommitted transactions 130626 17:05:53 InnoDB: Rolling back trx with id 0 15104, 9999 rows to undo InnoDB: Progress in percents: 1130626 17:05:53 InnoDB: Started; log sequence number 0 13016158 InnoDB: !!! innodb_force_recovery is set to 2 !!! 130626 17:05:53 [Note] Recovering after a crash using /vobiledata/mysqllog/mysql-bin 130626 17:05:53 [Note] Starting crash recovery... 130626 17:05:53 [Note] Crash recovery finished. 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85130626 17:05:53 [Note] Event Scheduler: Loaded 0 events 130626 17:05:53 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.1.57-log' socket: '/tmp/mysqld.sock' port: 3306 MySQL Community Server (GPL) 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 InnoDB: Rolling back of trx id 0 15104 completed 130626 17:05:53 InnoDB: Rollback of non-prepared transactions completed
innodb_force_recovery =3 不执行回滚操作
130626 16:33:53 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... InnoDB: 1 transaction(s) which must be rolled back or cleaned up InnoDB: in total 9999 row operations to undo InnoDB: Trx id counter is 0 13056 InnoDB: Last MySQL binlog file position 0 920753, file name /vobiledata/mysqllog/mysql-bin.000245 130626 16:33:53 InnoDB: Started; log sequence number 0 6497918 InnoDB: !!! innodb_force_recovery is set to 3 !!! 130626 16:33:53 [Note] Recovering after a crash using /vobiledata/mysqllog/mysql-bin 130626 16:33:53 [Note] Starting crash recovery... 130626 16:33:53 [Note] Crash recovery finished. 130626 16:33:53 [Note] Event Scheduler: Loaded 0 events 130626 16:33:53 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.1.57-log' socket: '/tmp/mysqld.sock' port: 3306 MySQL Community Server (GPL)
innodb_force_recovery =5 不查看重做日志，innodb存储引擎会将未提交的事务事务已经提交
此时数据已经被update
+----+------+------+------+ | a | b | c | d | +----+------+------+------+ | 1 | 101 | 1 | 1 | | 2 | 102 | 2 | 2 | | 3 | 103 | 3 | 3 | | 4 | 104 | 4 | 4 | | 5 | 105 | 5 | 5 | | 6 | 106 | 6 | 6 | | 7 | 107 | 7 | 7 | | 8 | 108 | 8 | 8 | | 9 | 109 | 9 | 9 | | 10 | 110 | 10 | 10 | +----+------+------+------+
innodb_force_recovery =6 不执行前滚操作，但是恢复的时候有回滚操作
+----+------+------+------+ | a | b | c | d | +----+------+------+------+ | 1 | 101 | 1 | 1 | | 2 | 102 | 2 | 2 | | 3 | 103 | 3 | 3 | | 4 | 104 | 4 | 4 | | 5 | 105 | 5 | 5 | | 6 | 106 | 6 | 6 | | 7 | 107 | 7 | 7 | | 8 | 108 | 8 | 8 | | 9 | 109 | 9 | 9 | | 10 | 110 | 10 | 10 | +----+------+------+------+
130626 16:44:29 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... InnoDB: Doing recovery: scanned up to log sequence number 0 8680656 InnoDB: 1 transaction(s) which must be rolled back or cleaned up InnoDB: in total 9999 row operations to undo InnoDB: Trx id counter is 0 14080 InnoDB: Last MySQL binlog file position 0 920753, file name /vobiledata/mysqllog/mysql-bin.000245 InnoDB: Starting in background the rollback of uncommitted transactions 130626 16:44:29 InnoDB: Rolling back trx with id 0 13057, 9999 rows to undo InnoDB: Progress in percents: 1130626 16:44:29 InnoDB: Started; log sequence number 0 8680656 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79130626 16:44:29 [Note] Event Scheduler: Loaded 0 events 130626 16:44:29 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.1.57-log' socket: '/tmp/mysqld.sock' port: 3306 MySQL Community Server (GPL) 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 InnoDB: Rolling back of trx id 0 13057 completed 130626 16:44:29 InnoDB: Rollback of non-prepared transactions completed 130626 16:45:08 mysqld_safe Starting mysqld daemon with databases from /vobiledata/mysqldata 130626 16:45:08 [Note] Plugin 'FEDERATED' is disabled. 130626 16:45:08 InnoDB: Initializing buffer pool, size = 2.0G 130626 16:45:08 InnoDB: Completed initialization of buffer pool InnoDB: The user has set SRV_FORCE_NO_LOG_REDO on InnoDB: Skipping log redo 130626 16:45:08 InnoDB: Started; log sequence number 0 0 InnoDB: !!! innodb_force_recovery is set to 6 !!! 130626 16:45:08 [Note] Recovering after a crash using /vobiledata/mysqllog/mysql-bin 130626 16:45:08 [Note] Starting crash recovery... 130626 16:45:08 [Note] Crash recovery finished. 130626 16:45:08 [Note] Event Scheduler: Loaded 0 events 130626 16:45:08 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.1.57-log' socket: '/tmp/mysqld.sock' port: 3306 MySQL Community Server (GPL) 130626 16:45:14 InnoDB: error: space object of table test/test, InnoDB: space id 3 did not exist in memory. Retrying an open.
-+------+------+------+ | 1 | 101 | 1 | 1 | | 2 | 102 | 2 | 2 | | 3 | 103 | 3 | 3 | | 4 | 104 | 4 | 4 | | 5 | 105 | 5 | 5 | | 6 | 106 | 6 | 6 | | 7 | 107 | 7 | 7 | | 8 | 108 | 8 | 8 | | 9 | 109 | 9 | 9 | | 10 | 110 | 10 | 10 | +----+------+------+------+
130626 16:44:29 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... InnoDB: Doing recovery: scanned up to log sequence number 0 8680656 InnoDB: 1 transaction(s) which must be rolled back or cleaned up InnoDB: in total 9999 row operations to undo InnoDB: Trx id counter is 0 14080 InnoDB: Last MySQL binlog file position 0 920753, file name /vobiledata/mysqllog/mysql-bin.000245 InnoDB: Starting in background the rollback of uncommitted transactions 130626 16:44:29 InnoDB: Rolling back trx with id 0 13057, 9999 rows to undo InnoDB: Progress in percents: 1130626 16:44:29 InnoDB: Started; log sequence number 0 8680656 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79130626 16:44:29 [Note] Event Scheduler: Loaded 0 events 130626 16:44:29 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.1.57-log' socket: '/tmp/mysqld.sock' port: 3306 MySQL Community Server (GPL) 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 InnoDB: Rolling back of trx id 0 13057 completed 130626 16:44:29 InnoDB: Rollback of non-prepared transactions completed 130626 16:45:08 mysqld_safe Starting mysqld daemon with databases from /vobiledata/mysqldata 130626 16:45:08 [Note] Plugin 'FEDERATED' is disabled. 130626 16:45:08 InnoDB: Initializing buffer pool, size = 2.0G 130626 16:45:08 InnoDB: Completed initialization of buffer pool InnoDB: The user has set SRV_FORCE_NO_LOG_REDO on InnoDB: Skipping log redo 130626 16:45:08 InnoDB: Started; log sequence number 0 0 InnoDB: !!! innodb_force_recovery is set to 6 !!! 130626 16:45:08 [Note] Recovering after a crash using /vobiledata/mysqllog/mysql-bin 130626 16:45:08 [Note] Starting crash recovery... 130626 16:45:08 [Note] Crash recovery finished. 130626 16:45:08 [Note] Event Scheduler: Loaded 0 events 130626 16:45:08 [Note] /usr/local/mysql/bin/mysqld: ready for connections. Version: '5.1.57-log' socket: '/tmp/mysqld.sock' port: 3306 MySQL Community Server (GPL) 130626 16:45:14 InnoDB: error: space object of table test/test, InnoDB: space id 3 did not exist in memory. Retrying an open.
相关推荐
总结起来，`innodb_force_recovery`是一个在MySQL遇到严重崩溃时的应急工具，可以帮助数据库在某些情况下恢复服务，但并不能保证数据的完整性和一致性。因此，对于任何涉及数据恢复的操作，都需要谨慎行事，同时保持...
`innodb_force_recovery`是MySQL中的一个服务器系统变量，其目的是在InnoDB引擎遇到问题时，尽可能地让数据库启动并允许用户备份数据。该参数有6个不同的级别（0-5），每个级别代表一种更激进的恢复策略。随着级别的...
在MySQL数据库中，InnoDB存储引擎的表损坏是一种常见的问题，尤其当系统出现异常关机、硬件故障或软件错误时。不同于MyISAM存储引擎，InnoDB表的损坏通常不能简单地通过`REPAIR TABLE`命令来修复。下面将详细介绍...
总结来说，管理MySQL的启动、关闭和恢复涉及多个参数，如`innodb_fast_shutdown`用于控制关闭时的清理级别，`innodb_force_recovery`用于在异常情况下强制恢复数据库。理解这些参数的含义和用法，能帮助我们更有效地...
在实际操作中，修复MySQL数据库时应谨慎使用`innodb_force_recovery`，因为它是为了应急而设计的，并不保证完全恢复数据的完整性。在尝试设置此参数之前，最好先备份重要的数据，以防止不可逆的损失。同时，分析错误...
2. 在 [mysqld] 段中增加：innodb_force_recovery = 4 3. 在另外的地方建立新的数据库，并用原表的结构创建表 4. 将上一步中建立的 .frm 表文件拷贝到准备恢复的数据库中 5. 启动数据库 6. 停止数据库，注释掉 ...
* innodb_force_recovery：在 Innodb 的自动恢复失败后，从崩溃中强制启动，有 1-6 个级别，数值越低恢复的方式也保守，默认为 4 Log 的参数： * log：查询日志，记录所有的 MySQL 的命令操作，在跟踪数据库运行时...
- **修复InnoDB表空间**：如果问题是由于表空间损坏导致的，可以尝试使用`mysqlcheck`工具进行修复，或者使用`innodb_force_recovery`参数设置不同的恢复级别。 - **检查权限和配置**：确保MySQL服务有足够的权限...
用了innodb_force_recovery=6也无效，于是前往查看。 排查过程： 最早的启动信息里面，没有任何报错，只有一行[ERROR] Aborting提示，如下： 接着同事用了innodb_force_recovery＝6的方式，才多出现了如下的错误...
在去除`innodb_force_recovery`参数后，重新启动MySQL，然后从备份导入数据。如果在导入过程中遇到表已存在的错误，可能是因为InnoDB在启动过程中创建了新的表文件，需要手动删除这些文件后再导入。 6. **检查并...
1. **修改配置文件**：编辑MySQL的配置文件`my.ini`，添加或修改`innodb_force_recovery`参数。 - **配置项**： ```ini [mysqld] innodb_force_recovery = 1 ``` - **说明**：该参数用于指定InnoDB如何处理...
3. **InnoDB初始化信息**：接下来的一系列`[Note]`消息记录了InnoDB存储引擎在启动过程中的状态，如使用原子操作管理缓冲池页面、内存堆的禁用、使用Windows原生互斥函数等。 4. **非正常关机提示**：“Database ...
- 修改配置文件`my.ini`，将`innodb_force_recovery`设置为6，这允许在不完全正常启动的情况下访问InnoDB表。 - 重启MySQL服务`net start mysql`，尝试使用`desc songlyric`查看表结构。虽然会显示错误，但表结构...
6. 再次关闭MySQL服务，然后注释掉`my.cnf`中的`innodb_force_recovery = 6`设置。 7. 重新启动MySQL服务。 恢复InnoDB表数据的步骤： 1. 首先确保已经完成了表结构的恢复。 2. 使用`ALTER TABLE`语句丢弃表空间，...
使用 DBRECOVER 对于 MYSQL ，即使使用 innodb_force_recovery 也可以从无法读取的表中恢复数据。 该软件旨在用于实时数据库服务器未主动使用的 ibdata 文件。 一般而言，该工具通过从整体 ibdata 文件和/或独立 ...
### MySQL OCP 实战整理题库知识点解析 #### 题目一： **题目内容**： Which MySQL utility program should you use to process ...但在实际场景中，可能还需要结合其他手段如备份恢复、使用MySQL的修复命令等方法。