利用innodb_force_recovery修复MySQL数据页损坏

2023-11-09 来源：花图问答

服务时报1067错误，服务无法启动。

查看xxx.err错误日志发现有数据页损坏信息：

InnoDB: Database page corruption on disk or a failed

InnoDB: file read of page 200.

出现上述现象是由于突然断电、强制关机、强制杀死MySQL进程等操作所导致的。

首先修改my.ini中的innodb_force_recovery参数(4-6)，使mysqld跳过恢复步骤，将mysqld 启动,将数据导出来然后重建数据库。

innodb_force_recovery可以设置为1-6,大的数字包含前面所有数字的影响。

　　 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):不执行前滚的操作。

　　注意

　　当设置参数值大于0后，可以对表进行select,create,drop操作,但insert,update或者delete这类操作是不允许的。

可以尝试使用MySQL的bin目录下的mysqlcheck.exe工具来尝试发现并修复MyISAM表的损坏数据页。

如果仅是MyISAM数据页损坏，修复后，删除my.ini中的innodb_force_recovery参数，尝试启动。

如果是InnoDB数据表发生了数据页损坏，需要导出数据，重新建库。

可以尝试运行

select concat(‘select 1 from ‘,table_name,‘;‘) from information_schema.tables where table_schema=‘xxx‘;查询到的结果定位哪些InnoDB出现了损坏，尝试使用冗余数据修复。

最后使用MySQL5in>mysqldump -uroot -pOSSDB123 databasename >e:xxx.sql导出表结构和数据，使用load重建建库。也可以使用SELECT INTO OUTFILE从数据库转储你的表，通常以这种方法获取的数据是完好的。

下面是网上的一篇相关的文章：

1. 表损坏的原因分析

以下原因是导致mysql 表毁坏的常见原因：

1、服务器突然断电导致数据文件损坏。

2、强制关机，没有先关闭mysql 服务。

3、 mysqld 进程在写表时被杀掉。

4、使用myisamchk 的同时，mysqld 也在操作表。　　

5、磁盘故障。

6、服务器死机。

7、 mysql 本身的bug 。

2.表损坏的症状　　　　　　　　　　

一个损坏的表的典型症状如下：

　　　　1 、当在从表中选择数据之时，你得到如下错误：

Incorrect key file for table: ‘...‘. Try to repair it

　　　　2 、查询不能在表中找到行或返回不完全的数据。

3 、Error: Table ‘p‘ is marked as crashed and should be repaired 。

4 、打开表失败： Can’t open file: ‘×××.MYI’ (errno: 145) 。

3.预防 MySQL 表损坏

　　可以采用以下手段预防mysql 表损坏：

1 、定期使用myisamchk 检查MyISAM 表（注意要关闭mysqld ），推荐使用check table 来检查表（不用关闭mysqld ）。

2 、在做过大量的更新或删除操作后，推荐使用OPTIMIZE TABLE 来优化表，这样既减少了文件碎片，又减少了表损坏的概率。

3 、关闭服务器前，先关闭mysqld （正常关闭服务，不要使用kill -9 来杀进程）。

4 、使用ups 电源，避免出现突然断电的情况。

5 、使用最新的稳定发布版mysql ，减少mysql 本身的bug 导致表损坏。

6 、对于InnoDB 引擎，你可以使用innodb_tablespace_monitor 来检查表空间文件内文件空间管理的完整性。

7 、对磁盘做raid ，减少磁盘出错并提高性能。

8 、数据库服务器最好只跑mysqld 和必要的其他服务，不要跑其他业务服务，这样减少死机导致表损坏的可能。

9 、不怕万一，只怕意外，平时做好备份是预防表损坏的有效手段。

4. MySQL 表损坏的修复

MyISAM 表可以采用以下步骤进行修复：

1、使用 reapair table 或myisamchk 来修复。

2、如果上面的方法修复无效，采用备份恢复表。

具体可以参考如下做法：

阶段1 ：检查你的表

如果你有很多时间，运行myisamchk *.MYI 或myisamchk -e *.MYI 。使用-s （沉默）选项禁止不必要的信息。

如果mysqld 服务器处于宕机状态，应使用--update-state 选项来告诉myisamchk 将表标记为‘ 检查过的‘ 。

你必须只修复那些myisamchk 报告有错误的表。对这样的表，继续到阶段2 。

如果在检查时，你得到奇怪的错误( 例如out of memory 错误) ，或如果myisamchk 崩溃，到阶段3 。

阶段2 ：简单安全的修复

注释：如果想更快地进行修复，当运行myisamchk 时，你应将sort_buffer_size 和Key_buffer_size 变量的值设置为可用内存的大约25% 。

首先，试试myisamchk -r -q tbl_name(-r -q 意味着“ 快速恢复模式”) 。这将试图不接触数据文件来修复索引文件。如果数据文件包含它应有的一切内容和指向数据文件内正确地点的删除连接，这应该管用并且表可被修复。开始修复下一张表。否则，执行下列过程：

在继续前对数据文件进行备份。

使用myisamchk -r tbl_name(-r 意味着“ 恢复模式”) 。这将从数据文件中删除不正确的记录和已被删除的记录并重建索引文件。

如果前面的步骤失败，使用myisamchk --safe-recover tbl_name 。安全恢复模式使用一个老的恢复方法，处理常规恢复模式不行的少数情况( 但是更慢) 。

如果在修复时，你得到奇怪的错误( 例如out of memory 错误) ，或如果myisamchk 崩溃，到阶段3 。

阶段3 ：困难的修复

只有在索引文件的第一个16K 块被破坏，或包含不正确的信息，或如果索引文件丢失，你才应该到这个阶段。在这种情况下，需要创建一个新的索引文件。按如下步骤操做：

把数据文件移到安全的地方。

使用表描述文件创建新的( 空) 数据文件和索引文件：

shell> mysql db_name

mysql> SET AUTOCOMMIT=1;

mysql> TRUNCATE TABLE tbl_name;

mysql> quit

如果你的MySQL 版本没有TRUNCATE TABLE ，则使用DELETE FROM tbl_name 。

将老的数据文件拷贝到新创建的数据文件之中。（不要只是将老文件移回新文件之中；你要保留一个副本以防某些东西出错。）

回到阶段2 。现在myisamchk -r -q 应该工作了。（这不应该是一个无限循环）。

你还可以使用REPAIR TABLE tbl_name USE_FRM ，将自动执行整个程序。

阶段4 ：非常困难的修复

只有.frm 描述文件也破坏了，你才应该到达这个阶段。这应该从未发生过，因为在表被创建以后，描述文件就不再改变了。

　　　　从一个备份恢复描述文件然后回到阶段3 。你也可以恢复索引文件然后回到阶段2 。对后者，你应该用myisamchk -r 启动。

如果你没有进行备份但是确切地知道表是怎样创建的，在另一个数据库中创建表的一个拷贝。删除新的数据文件，然后从其他数据库将描述文件和索引文件移到破坏的数据库中。这样提供了新的描述和索引文件，但是让.MYD 数据文件独自留下来了。回到阶段2 并且尝试重建索引文件。

InnoDB 表可以采用下面的方法修复：

如果数据库页被破坏，你可能想要用SELECT INTO OUTFILE 从从数据库转储你的表，通常以这种方法获取的大多数数据是完好的。即使这样，损坏可能导致SELECT * FROM tbl_name 或者InnoDB 后台操作崩溃或断言，或者甚至使得InnoDB 前滚恢复崩溃。尽管如此，你可以用它来强制InnoDB 存储引擎启动同时阻止后台操作运行，以便你能转储你的表。例如：你可以在重启服务器之前，在选项文件的[mysqld] 节添加如下的行：

　　　　[mysqld]innodb_force_recovery = 4innodb_force_recovery 被允许的非零值如下。一个更大的数字包含所有更小数字的预防措施。如果你能够用一个多数是4 的选项值来转储你的表，那么你是比较安全的，只有一些在损坏的单独页面上的数据会丢失。一个为6 的值更夸张，因为数据库页被留在一个陈旧的状态，这个状态反过来可以引发对B 树和其它数据库结构的更多破坏。

　　　　 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)

不要在恢复连接中做日志前滚。

　　数据库不能另外地带着这些选项中被允许的选项来使用。作为一个安全措施，当innodb_force_recovery 被设置为大于0 的值时，InnoDB 阻止用户执行INSERT, UPDATE 或DELETE 操作.

　　即使强制恢复被使用，你也可以DROP 或CREATE 表。如果你知道一个给定的表正在导致回滚崩溃，你可以移除它。你也可以用这个来停止由失败的大宗导入或失败的ALTER TABLE 导致的失控回滚。你可以杀掉mysqld 进程，然后设置innodb_force_recovery 为3 ，使得数据库被挂起而不需要回滚，然后舍弃导致失控回滚的表。

利用innodb_force_recovery修复MySQL数据页损坏

标签：

小编还为您整理了以下内容，可能对您也有帮助：

如何为 MySQL 数据库修正损坏的 InnoDB

InnoDB拥有内部恢复机制，假如数据库崩溃了，InnoDB通过从最后一个时间戳开始运行日志文件，来尝试修复数据库。大多数情况下会修复成功，而且整个过程是透明的。

假如InnoDB自行修复失败，那么数据库将不能启动。无论怎样一次又一次的尝试启动MySQL，它都只是发出一条错误信息。这也是在使用 InnoDB时，需要运行master/master的原因，只有这样才能在一个master宕掉时，还有一台冗余master做后备。

在继续操作前，先浏览下MySQL的日志文件，确定数据库是因为InnoDB表的损坏而崩溃。
有一种方法是更新InnoDB的日志文件计数器以跳过引起崩溃的查询，但是经验告诉我们这不是个好方法。这种情况下，将造成数据的不一致性而且会经常使主从复制中断。
一旦确定MySQL因为InnoDB表损坏无法启动时，就可以按照以下5步进行修复：
1.添加如下配置到/etc/my.cnf文件中
innodb_force_recovery = 4
2.这时就可以重新启动数据库了，在innodb_force_recovery配置的作用，所有的插入与更新操作将被忽略;
3.导出所有的数据表;
4.关闭数据库并删除所有数据表文件及目录，再运行 mysql_install_db来创建MySQL默认数据表;
5.在/etc/my.cnf中删除innodb_force_recovery这一行，再启动MySQL（这时MySQL正常启动）;
6.从第3步备份的文件中恢复所有的数据。

如何为 MySQL 数据库修正损坏的 InnoDB

MySQL的InnoDB数据文件损坏如何修复

因为被破坏的地方只在索引的部分，所以当使用innodb_force_recovery = 1运行InnoDB时，操作如下：
执行check，repair table 都无效
alter table email_status engine =myisam; #也报错了，因为模式是innodb_force_recovery =1。
ERROR 1025 (HY000): Error on rename of '...' to '....' (errno: -1)
建立一张表：create table email_status_bak #和原表结构一样，只是把INNODB改成了MYISAM。把数据导进去insert into email_status_bak select * from email_status;

删除掉原表：
drop table email_status;

注释掉innodb_force_recovery 之后，重启。
重命名：
rename table edm_email_status_bak to email_status;

最后该回存储引擎
alter table edm_email_status engine = innodb

总结：
这里的一个重要知识点就是对 innodb_force_recovery 参数的理解了，要是遇到数据损坏甚至是其他的损坏。可能上面的方法不行了，需要尝试另一个方法：insert into tb select * from ta limit X；甚至是mp出去，再load回来。

MySQL的InnoDB数据文件损坏如何修复

如何从MySQL/InnoDB数据文件中的恢复数据

备份能恢复真服
给二解决办：
第办：使用命令格式
shell>mysqladmin create 数据库名 -uroot -p (数据库已经存用步)
shell>mysql -uroot -p 数据库名 < backup-file.sql

第二办：更详细用mysql线手册已经给找备份恢复页面打看问题肯定搞定mysql官文手册
备份恢复页面链接：http://dev.mysql.com/doc/refman/5.1/zh/database-administration.html#disaster-prevention

如何从MySQL/InnoDB数据文件中的恢复数据

mysql数据库崩溃的原因(mysql崩溃恢复)

MySQL在崩溃恢复时，会遍历打开所有ibd文件的headerpage验证数据字典的准确性，如果MySQL中包含了大量表，这个校验过程就会比较耗时。MySQL下崩溃恢复确实和表数量有关，表总数越大，崩溃恢复时间越长。另外磁盘IOPS也会影响崩溃恢复时间，像这里开发库的HDDIOPS较低，因此面对大量的表空间，校验速度就非常缓慢。另外一个发现，MySQL8下正常启用时居然也会进行表空间校验，而故障恢复时则会额外再进行一次表空间校验，等于校验了2遍。不过MySQL8.0里多了一个特性，即表数量超过5W时，会启用多线程扫描，加快表空间校验过程。

如何跳过校验MySQL5.7下有方法可以跳过崩溃恢复时的表空间校验过程嘛？查阅了资料，方法主要有两种：

1.配置innodb_force_recovery可以使srv_force_recovery!=0，那么validate=false，即可以跳过表空间校验。实际测试的时候设置innodb_force_recovery=1，也就是强制恢复跳过坏页，就可以跳过校验，然后重启就是正常启动了。通过这种临时方式可以避免崩溃恢复后非常耗时的表空间校验过程，快速启动MySQL，个人目前暂时未发现有什么隐患。2.使用共享表空间替代表空间这样就不需要打开N个ibd文件了，只需要打开一个ibdata文件即可，大大节省了校验时间。自从听了姜老师讲过使用共享表空间替代表空间解决drop大表时性能抖动的原理后，感觉共享表空间在很多业务环境下，反而更有优势。

临时冒出另外一种解决想法，即用GDB调试崩溃恢复，通过临时修改validate变量值让MySQL跳过表空间验证过程，然后让MySQL正常关闭，重新启动就可以正常启动了。但是实际测试发现，如果以debug模式运行，确实可以临时修改validate变量，跳过表空间验证过程，但是debug模式下代码运行效率大打折扣，反而耗时更长。而以非debug模式运行，则无法修改validate变量，想法破灭。

请教Innodb 恢复的问题

- 恢复策略
前面说到未提交的事务和回滚了的事务也会记录Redo Log，因此在进行恢复时,这些事务要进行特殊的的处理.有2中不同的恢复策略：
A. 进行恢复时，只重做已经提交了的事务。
B. 进行恢复时，重做所有事务包括未提交的事务和回滚了的事务。然后通过Undo Log回滚那些未提交的事务。
- InnoDB存储引擎的恢复机制
MySQL数据库InnoDB存储引擎使用了B策略, InnoDB存储引擎中的恢复机制有几个特点：
A. 在重做Redo Log时，并不关心事务性。恢复时，没有BEGIN，也没有COMMIT,ROLLBACK的行为。也不关心每个日志是哪个事务的。尽管事务ID等事务相关的内容会记入Redo Log，这些内容只是被当作要操作的数据的一部分。

B. 使用B策略就必须要将Undo Log持久化，而且必须要在写Redo Log之前将对应的Undo Log写入磁盘。Undo和Redo Log的这种关联，使得持久化变得复杂起来。为了降低复杂度，InnoDB将Undo Log看作数据，因此记录Undo Log的操作也会记录到redo log中。这样undo log就可以象数据一样缓存起来，而不用在redo log之前写入磁盘了。

包含Undo Log操作的Redo Log，看起来是这样的：

记录1: <trx1, Undo log insert <undo_insert …>>

记录2: <trx1, insert …>

记录3: <trx2, Undo log insert <undo_update …>>

记录4: <trx2, update …>

记录5: <trx3, Undo log insert <undo_delete …>>

记录6: <trx3, delete …>

C. 到这里，还有一个问题没有弄清楚。既然Redo没有事务性，那岂不是会重新执行被回滚了的事务？确实是这样。同时Innodb也会将事务回滚时的操作也记录到redo log中。回滚操作本质上也是对数据进行修改，因此回滚时对数据的操作也会记录到Redo Log中。

一个回滚了的事务的Redo Log，看起来是这样的：

记录1: <trx1, Undo log insert <undo_insert …>>

记录2: <trx1, insert A…>

记录3: <trx1, Undo log insert <undo_update …>>

记录4: <trx1, update B…>

记录5: <trx1, Undo log insert <undo_delete …>>

记录6: <trx1, delete C…>

记录7: <trx1, insert C>

记录8: <trx1, update B to old value>

记录9: <trx1, delete A>

一个被回滚了的事务在恢复时的操作就是先redo再undo，因此不会破坏数据的一致性.
- InnoDB存储引擎中相关的函数
Redo: recv_recovery_from_checkpoint_start()
Undo: recv_recovery_rollback_active()
Undo Log的Redo Log: trx_undof_page_add_undo_rec_log()

请教Innodb 恢复的问题

mysql的innodb数据库引擎详解

一．mysql体系结构和存储引擎

1.1、数据库和实例的区别

数据库：物理操作系统或其他形式文件类型的集合。在mysql下数据库文件可以是frm，myd，myi，ibd结尾的文件。

数据库实例：由数据库后台进程/线程以及一个共享内存区组成。数据库实例才是真正用来操作数据库文件的。

mysql数据库是单进程多线程的程序，与sql server比较类似。也就是说，Mysql数据库实例在系统上的表现就是一个进程。

1.2、mysql的体系结构

mysql由连接池组件、管理服务和工具组件、sql接口组建、查询分析器组件、优化器组件、缓存组件、插件是存储引擎、物理文件。

1.3、mysql存储引擎

1.3.1、innodb存储引擎，特点支持外键、行锁、非锁定读(默认情况下读取不会产生锁)、mysql-4.1开始支持每个innodb引擎的表单独放到一个表空间里。innodb通过使用MVCC来获取高并发性，并且实现sql标准的4种隔离级别，同时使用一种被称成next-key locking的策略来避免换读(phantom)现象。除此之外innodb引擎还提供了插入缓存(insert buffer)、二次写(double write)、自适应哈西索引(adaptive hash index)、预读(read ahead)等高性能技术。

1.3.2、myisam存储引擎，myisam特点是不支持事物，适合olap应用，myisam表由MYD和MYI组成。mysql-5.0版本之前，myisam默认支持的表大小为4G，从mysql-5.0以后，myisam默认支持256T的表单数据。myisam只缓存索引数据。

1.3.3、NDB存储引擎，特点是数据放在内存中，mysql-5.1版本开始可以将非索引数据放到磁盘上。NDB之前的缺陷是join查询是mysql数据库层完成的，而不是存储引擎完成的，复杂的join查询需要巨大的网络开销，速度很慢。当前mysql cluster7.2版本中已经解决此问题，join查询效率提高了70倍。

1.3.4、memeory存储引擎，将数据放到内存中，默认使用hash索引，不支持text和blob类型，varchara是按照char的方式来存储的。mysql数据库使用memory存储引擎作为临时表还存储中间结果集(intermediate result)，如果中间集结果大于memorg表的容量设置，又或者中间结果集包含text和blog列类型字段，则mysql会把他们转换到myisam存储引擎表而放到磁盘上，会对查询产生性能影响。

1.3.5、archive存储引擎，压缩能力较强，主要用于归档存储。

1.3.6、federated存储引擎，不存储数据，他指向一台远程mysql数据库上的表。

1.3.7、maria存储引擎，myisam的后续版本,支持缓存数据和索引，行锁设计，支持mvcc，支持事务和非事务安全的选项，以及更好的BLOG字符类型的处理性能。

1.3.8、其他存储引擎，sphinx用于全文索引，infobright用于数据仓库。

1.4连接Mysql

1.4.1、TCP/IP：基于网络的连接，连接进行权限检查。

1.4.2、命名管道和共享内存：Windows系统上同一服务器上的两进程可通过命名管道连接，需在配置文件中启用--enable-named-pipe选项。

1.4.3、Unix套接字：客户端与服务端位于同一服务器时才可使用，可以在my.cnf中指定-socket=/tmp/mysql.sock，连接时指定./mysql -S/tmp/mysql.sock。

二．InnoDB存储引擎

2.2、innodb引擎架构

InnoDB的多个内存块组成了内存池，负责如下工作：

1).维护所有进程/线程需要访问的多个内部数据结构。

2).缓存磁盘上的数据，方便快速的读取，并且在对磁盘文件的数据进行修改之前在这里缓存。

3).重做日志缓存。

后台线程的主要作用是负责刷新内存池中的数据，保证缓冲池中的内存缓存是最近的数据，此外、将已经修改的数据文件刷新到磁盘文件

2.2.1、后台线程

innodb存储引擎后台有7个线程，—–4个IO线程(insert buffer thread,log thread,read thread,write thread)，1个master thread，一个lock监控线程，一个错误监控线程。

2.2.2、内存

innodb存储引擎内存由以下三个部分组成：缓冲池(buffer pool),重做日志缓存(redo log buffer),额外的内存池(additional memory pool)。可以使用 show engine innodb status来查看innodb_buffer_pool的使用情况。

innodb_buffer_pool_size：具体看，缓冲池中的数据库类型有：索引页、数据库页、undo页、插入缓存页(insert buffer)、自适应hash(adaptive hashindex)、innodb存储的锁信息(lock info)、数据字典信息(data dictionary)。

InnoDB工作方式：将数据文件按页(每页16K)读入InnoDBbuffer pool，然后按最近最少使用算法(LRU)保留缓存数据，最后通过一定频率将脏页刷新到文件。

2.3、master thread

2.3.1、master thread源码分析

2.3.2、master thread的潜在问题

1、由于硬件的发展，现在的硬件性能已经提高了很多，如果innodb每秒最大刷新100个脏页，那么效率会很低，为了解决这个问题，innodb plugin提供了一个参数innodb_io_capacity，用来表示磁盘IO的吞吐量，默认值是200，规则如下：在合并插入缓存时，合并插入缓存的数量为innodb_io_capacity的5%；在从缓冲区刷新脏页时，啥新脏页的数量为innodb_io_capacity。

2、关于innodb_max_dirty_pages_pct值的争议，如果值过大，内存也很大或者服务器压力很大，那么效率很降低，如果设置的值过小，那么硬盘的压力会增加，建议是在75-80.并且innodb plugin引进了innodb_adaptive_flushng(自适应的刷新)，该值影响每秒刷新脏页的数量。

2.4、关键特性,为innodb提高性能的技术

2.4.1、插入缓存

当一个表有非聚集索引时，对于非聚集索引的叶子节点的插入不是顺序的，这时候需要离散的访问非聚集索引页，性能就在这里降低了，这是由于b+树的原理导致的。插入缓存就是用来解决这个问题的。

对于非聚集索引的插入和更新操作，不是每一次都直接插入索引页，而是先判断插入的非聚集索引页是否在缓存中，如果在就直接插入，如果不在就放入到一个插入缓冲区中，好似欺骗数据库这个非聚集索引已经插入到叶子节点了。然后再以一定的频率插入缓存和非聚集索引页字节点的合并操作。

插入缓存的使用需要满足以下两个条件(也就是非唯一的辅助索引)：索引是辅助索引；索引不是唯一的。

2.4.2、两次写

两次写给innodb带来的是可靠性，主要用来解决部分写失败(partial page write)。在应用重做日之前，我们需要一个页的副本，当写入失效发生时，先通过页的副本来还原该页，再进行重做，这就是doublewrite。

doublewrite有两部分组成，一部分是内存中的doublewrite buffer，大小为2M，另外一部分就是物理磁盘上的共享表空间中联系的128个页，即两个区，大小同样为2M。当缓冲池的张也刷新时，并不直接写硬盘，而是回通过memcpy函数将脏页先拷贝到内存中的doublewrite buffer，之后通过doublewrite buffer再分两次写，每次写入1M到共享表空间的物理磁盘上，然后马上调用fsync函数，同步磁盘。

2.4.3、自适应哈西索引

由于innodb不支持hash索引，但是在某些情况下hash索引的效率很高，于是出现了 adaptive hash index功能，innodb存储引擎会监控对表上索引的查找，如果观察到建立hash索引可以提高性能的时候，则自动建立hash索引。

2.5、启动、关闭、恢复

innodb_fast_shutdown影响InnoDB表关闭。该参数有0、1、2三个参数。

0 MySQL关闭时完成所有的full purge和merge insertbuffer操作

1默认值只将缓冲池内的一些脏页刷新至磁盘

2将日志都写入日志文件不会有任何事务丢失但下次启动时会进行recovery

innodb_force_recovery影响整个innodb存储引擎的恢复状况，该值默认为0，表示当需要恢复时，需要执行所有的恢复操作，当不能进行有效恢复时，如数据页发生了corruption，mysql数据库可能宕机，并把错误写入错误日志中。

三．文件

3.1参数文件

Mysql实例可以不需要参数文件，这是所有的参数值取决于编译Mysql时指定的默认值和源代码中指定参数的默认值。其参数文件是Mysql.cnf。

3.1.1、什么是参数

参数是一个键/值对。可以使用show variables like命令查看，也可以通过information_schema的GLOBAL_VARIABLES视图来查找。

3.1.2、参数类型

参数文件分为两类：动态参数和静态参数。动态参数意味着你可以在Mysql实例运行中进行更改；静态参数说明在整个实例生命周期内都不得进行更改，好像是只读的。对于动态参数，又可以分为global和session关键字，表明该参数的修改是基于当前会话还是真格实例的生命周期。有些动态参数只能在会话中进行修改，如autocommit；有些参数修改完后，在整个实例生命周期中都会生效，如binlog_cache_size；而有些参数既可以在会话又可以在整个实例的生命周期内生效，如read_buffer_size。

3.2、日志文件

3.2.1、错误日志

错误日志对Mysql的启动、运行、关闭过程进行了记录。出现Mysql不能正常启动时，第一个必须查找的文件应该就是错误日志文件。使用show variables like ‘log_error’来定位文件。

3.2.2、慢查询日志

慢查询能为SQL语句的优化带来很好的帮助。设定一个阀值，将运行时间超过该值的所有SQL语句都记录到慢查询日志文件中。用参数long_query_time来设置。另一个参数log_queries_not_using_indexes，若运行的SQL语句没有使用索引，则这条SQL语句会被记录下来。

3.2.3、查询日志

查询日志记录了所有对Mysql请求的信息，不论这些请求是否得到正确的执行。默认文件名为：主机名.log。

3.2.4、二进制日志

二进制记录了对数据库执行更改的所有操作，但是不包括SELECT和SHOW操作，还包括了执行时间和更改操作时间。可用来恢复某些数据，同时也可以用来复制同步远程数据库。将binlog_format设置成row，可以支持事务隔离级别为READ COMMITTED，以获得更好的并发性。在使用MIXED格式下，mysql采用STATEMENT格式进行二进制日志文件的记录，但是有一些情况下会使用ROW格式，可能的情况如下：

1、表的存储引擎为NDB，这个时候DML操作都会以ROW格式记录。

2、使用了uuid()、user(),current_user(),found_rows(),row_count(),等不确定函数。

3、使用了insert delay语句

4、使用了用户定于的函数(UDF)

5、使用了临时表(temporary table)

注意：针对系统库mysql里面的表发生变化的处理规则如下：

1、如果采用insert，update，delete直接操作表，则日志根据binlog_format设定的格式记录。

2、如果使用grant，revoke，set password等DCL语句，那么无论如何都会使用SBR模式记录。

3、 blockhole引擎不支持row格式，ndb引擎不支持statement格式。

3.3、套件字文件

Unix系统下本地连接Mysql可以采用Unix套接字方法，需要一个套接字文件，可以使用show variableslike ‘socket’查询。

3.4、pid文件和表结构定义文件

pid文件是实例启动是记录自己进程ID号的文件，表结构定义文件是以frm为后缀名的文件，还可以用来存放视图的定义。

3.5、innodb引擎文件

3.5.1、表空间文件

默认表空间文件为ibdata1文件innodb_data_file_path存储数据，innodb_file_per_table可以按表分别产生一个表空间.db文件，但仅存该表的数据索引和插入缓冲等信息，其他信息如undo信息，系统事务信息，double write buffer等还是存放在默认表空间(ibdata1或表空间组)里。

3.5.2、重做日志文件

redo log是在实例或者介质失败的时候，用来保证数据完整性。每个innodb存储引擎至少有一个重做日志组,每个重做日志文件组下至少又2个重做日志文件，如默认的ib_logfile0、ib_logfile1.为了得到更高的可靠性，你可以设置多个重做镜像日志组。

因为重做日志条目先被写到日志缓冲中，然后根据一定条件刷新到磁盘重做日志文件中。与redo log相关的就是innodb_flush_log_at_trx_commit的值，对innodb的性能影响很大。他有0，1，2三个值，0代表提交事务时，并不同步写redo log，而是等master threas每秒写。1代表commit的时候就将redo log缓存写入磁盘，2代表commit的时候将redo log缓存异步的写入磁盘。

mysql的表坏了怎么修复啊?

1. 表损坏的原因分析
以下原因是导致mysql 表毁坏的常见原因：
1、服务器突然断电导致数据文件损坏。
2、强制关机，没有先关闭mysql 服务。
3、 mysqld 进程在写表时被杀掉。
4、使用myisamchk 的同时，mysqld 也在操作表。
5、磁盘故障。
6、服务器死机。
7、 mysql 本身的bug 。
2. 表损坏的症状
一个损坏的表的典型症状如下：
1 、当在从表中选择数据之时，你得到如下错误：
Incorrect key file for table: ’...’. Try to repair it
2 、查询不能在表中找到行或返回不完全的数据。
3 、Error: Table ’p’ is marked as crashed and should be repaired 。
4 、打开表失败： Can’t open file: ‘×××.MYI’ (errno: 145) 。
5 、
3. 预防 MySQL 表损坏
可以采用以下手段预防mysql 表损坏：
1 、定期使用myisamchk 检查MyISAM 表（注意要关闭mysqld ），推荐使用check table 来检查表（不用关闭mysqld ）。
2 、在做过大量的更新或删除操作后，推荐使用OPTIMIZE TABLE 来优化表，这样既减少了文件碎片，又减少了表损坏的概率。
3 、关闭服务器前，先关闭mysqld （正常关闭服务，不要使用kill -9 来杀进程）。
4 、使用ups 电源，避免出现突然断电的情况。
5 、使用最新的稳定发布版mysql ，减少mysql 本身的bug 导致表损坏。
6 、对于InnoDB 引擎，你可以使用innodb_tablespace_monitor 来检查表空间文件内文件空间管理的完整性。
7 、对磁盘做raid ，减少磁盘出错并提高性能。
8 、数据库服务器最好只跑mysqld 和必要的其他服务，不要跑其他业务服务，这样减少死机导致表损坏的可能。
9 、不怕万一，只怕意外，平时做好备份是预防表损坏的有效手段。
4. MySQL 表损坏的修复
MyISAM 表可以采用以下步骤进行修复：
1、使用 reapair table 或myisamchk 来修复。
2、如果上面的方法修复无效，采用备份恢复表。
具体可以参考如下做法：
阶段1 ：检查你的表
如果你有很多时间，运行myisamchk *.MYI 或myisamchk -e *.MYI 。使用-s （沉默）选项禁止不必要的信息。
如果mysqld 服务器处于宕机状态，应使用--update-state 选项来告诉myisamchk 将表标记为’ 检查过的’ 。
你必须只修复那些myisamchk 报告有错误的表。对这样的表，继续到阶段2 。
如果在检查时，你得到奇怪的错误( 例如out of memory 错误) ，或如果myisamchk 崩溃，到阶段3 。
阶段2 ：简单安全的修复
注释：如果想更快地进行修复，当运行myisamchk 时，你应将sort_buffer_size 和Key_buffer_size 变量的值设置为可用内存的大约25% 。
首先，试试myisamchk -r -q tbl_name(-r -q 意味着“ 快速恢复模式”) 。这将试图不接触数据文件来修复索引文件。如果数据文件包含它应有的一切内容和指向数据文件内正确地点的删除连接，这应该管用并且表可被修复。开始修复下一张表。否则，执行下列过程：
在继续前对数据文件进行备份。
使用myisamchk -r tbl_name(-r 意味着“ 恢复模式”) 。这将从数据文件中删除不正确的记录和已被删除的记录并重建索引文件。
如果前面的步骤失败，使用myisamchk --safe-recover tbl_name 。安全恢复模式使用一个老的恢复方法，处理常规恢复模式不行的少数情况( 但是更慢) 。
如果在修复时，你得到奇怪的错误( 例如out of memory 错误) ，或如果myisamchk 崩溃，到阶段3 。
阶段3 ：困难的修复
只有在索引文件的第一个16K 块被破坏，或包含不正确的信息，或如果索引文件丢失，你才应该到这个阶段。在这种情况下，需要创建一个新的索引文件。按如下步骤操做：
把数据文件移到安全的地方。
使用表描述文件创建新的( 空) 数据文件和索引文件：
shell> mysql db_name
mysql> SET AUTOCOMMIT=1;
mysql> TRUNCATE TABLE tbl_name;
mysql> quit
如果你的MySQL 版本没有TRUNCATE TABLE ，则使用DELETE FROM tbl_name 。
将老的数据文件拷贝到新创建的数据文件之中。（不要只是将老文件移回新文件之中；你要保留一个副本以防某些东西出错。）
回到阶段2 。现在myisamchk -r -q 应该工作了。（这不应该是一个无限循环）。
你还可以使用REPAIR TABLE tbl_name USE_FRM ，将自动执行整个程序。
阶段4 ：非常困难的修复
只有.frm 描述文件也破坏了，你才应该到达这个阶段。这应该从未发生过，因为在表被创建以后，描述文件就不再改变了。
从一个备份恢复描述文件然后回到阶段3 。你也可以恢复索引文件然后回到阶段2 。对后者，你应该用myisamchk -r 启动。
如果你没有进行备份但是确切地知道表是怎样创建的，在另一个数据库中创建表的一个拷贝。删除新的数据文件，然后从其他数据库将描述文件和索引文件移到破坏的数据库中。这样提供了新的描述和索引文件，但是让.MYD 数据文件独自留下来了。回到阶段2 并且尝试重建索引文件。
InnoDB 表可以采用下面的方法修复：
如果数据库页被破坏，你可能想要用SELECT INTO OUTFILE 从从数据库转储你的表，通常以这种方法获取的大多数数据是完好的。即使这样，损坏可能导致SELECT * FROM tbl_name 或者InnoDB 后台操作崩溃或断言，或者甚至使得InnoDB 前滚恢复崩溃。尽管如此，你可以用它来强制InnoDB 存储引擎启动同时阻止后台操作运行，以便你能转储你的表。例如：你可以在重启服务器之前，在选项文件的[mysqld] 节添加如下的行：
[mysqld]innodb_force_recovery = 4innodb_force_recovery 被允许的非零值如下。一个更大的数字包含所有更小数字的预防措施。如果你能够用一个多数是4 的选项值来转储你的表，那么你是比较安全的，只有一些在损坏的单独页面上的数据会丢失。一个为6 的值更夸张，因为数据库页被留在一个陈旧的状态，这个状态反过来可以引发对B 树和其它数据库结构的更多破坏。
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)
不要在恢复连接中做日志前滚。
数据库不能另外地带着这些选项中被允许的选项来使用。作为一个安全措施，当innodb_force_recovery 被设置为大于0 的值时，InnoDB 阻止用户执行INSERT, UPDATE 或DELETE 操作.
即使强制恢复被使用，你也可以DROP 或CREATE 表。如果你知道一个给定的表正在导致回滚崩溃，你可以移除它。你也可以用这个来停止由失败的大宗导入或失败的ALTER TABLE 导致的失控回滚。你可以杀掉mysqld 进程，然后设置innodb_force_recovery 为3 ，使得数据库被挂起而不需要回滚，然后舍弃导致失控回滚的表。

网上找的

参考资料：http://www.code-123.com/html/201062222632580.html

mysql的表坏了怎么修复啊?

参考资料：http://www.code-123.com/html/201062222632580.html

mysql无法启动

故障处理
移除当前使用的 redo log 文件，然后可以试着启动数据库，结果启动失败！
提示：
[ERROR] InnoDB: Page [page id: space=0, page number=0] log sequence number 178377412422 is in the future! Current system log sequence number 165909011496.
这样的错误，这是因为 MySQL writer 线程按照配置的时间间隔以 page 为单位刷新 buffer 数据到磁盘。当数据刷新到磁盘的时候，新写入磁盘的 page 包含了较新的 LSN，此时系统 system 表空间头的 LSN 并没有同步更新，通常这是检查点线程的工作。在正常的崩溃恢复中，MySQL 可以借助 redo log 来进行前滚和回滚，但是此时 redo log 已经被我们删掉了，MySQL 无法进行恢复操作。此时，我们设置 innodb_force_recovery=3 来强制启动 MySQL，仍然启动不成功，改成 4 后启动了！
再使用 mysqlmp 导出备份，结果噩梦又降临了！MySQL 又 crash 了。
提示：
InnDB: Failed to find tablespace for table......
设置参数 innodb_force_recovery=5，数据库仍然启动失败，再设置成 6，启动成功！用 sqlmp 顺利把数据备份出来了！
再初始化数据库，把刚刚备份的数据库导入，数据库恢复成功完成！

参数说明
这里的关键是设置 innodb_force_recovery 参数，对应这个参数的说明如下：
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：不执行前滚的操作。

mysql无法启动

mysql 数据库无法启动INNODB 怎么办求高手解决

可能是innodb数据文件损坏了

先不要继续操作了

先把数据和配置文件备份一下防止乱弄把数据全弄坏了

然后再用副本试着恢复

你可以试着设定不同的innodb_force_recovery系统变量来重新启动mysql

看看是不是有可以启动起来的值

MySQL损坏数据恢复

mysql> CREATE DATABASE sakila;

mysql> USE sakila;

mysql> CREATE TABLE actor (

actor_id SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT,

first_name VARCHAR(45) NOT NULL,

last_name VARCHAR(45) NOT NULL,

last_update TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,

PRIMARY KEY (actor_id),

KEY idx_actor_last_name (last_name)

)ENGINE=InnoDB DEFAULT CHARSET=utf8;

ALTER TABLE {库名}.{表名} DISCARD TABLESPACE;

例:

mysql> ALTER TABLE sakila.actor DISCARD TABLESPACE;

cp /backup_directory/actor.ibd path/to/mysql-5.7/data/sakila/

ALTER TABLE {库名}.{表名} IMPORT TABLESPACE;SHOW WARNINGS;

例:

mysql> ALTER TABLE sakila.actor IMPORT TABLESPACE; SHOW WARNINGS;

Query OK, 0 rows affected, 1 warning (0.15 sec)

Warning | 1810 | InnoDB: IO Read error: (2, No such file or directory)

Error opening './sakila/actor.cfg', will attempt to import

without schema verification

mysql> SELECT COUNT(*) FROM sakila.actor;

+----------+

| count(*) |

+----------+

| 200 |

+----------+

显示全文

全部频道

利用innodb_force_recovery修复MySQL数据页损坏