MYSQL中INNODB存储引擎数据库恢复方法

INNODB存储引擎数据库恢复方法与另一种类型的数据库恢复是有区别的，下面本文章就为大家介绍MYSQL中INNODB存储引擎数据库恢复方法，希望文章能给各位带来帮助哦。

MySQL的数据库文件直接复制便可以使用，但是那是指“MyISAM”类型的表。

而使用MySQL-Front直接创建表，默认是“InnoDB”类型，这种类型的一个表在磁盘上只对应一个“*.frm”文件，不像MyISAM那样还“*.MYD,*.MYI”文件。

MyISAM类型的表直接拷到另一个数据库就可以直接使用，但是InnoDB类型的表却不行。解决方法就是:

同时拷贝innodb数据库表“*.frm”文件和innodb数据“ibdata1”文件到合适的位置。启动MySQL的Windows服务，如果不能成功的话，查看data文件夹中有个“*.err”错误日志文件，其中会对启动失败的原因有所描述的。比如我碰到过两种错误原因。

一种是类似这样的错误信息:

1. INIFilecode
2. InnoDB:Error:logfile.ib_logfile0isofdifferentsize010485760bytesInnoDB:thanspecifiedinthe.cnffile025165824bytes!

这是因为在mysql配置文件中配置的日志文件大小与实际的不相符,解决方法是直接删掉旧的“ib_logfile0”等日志文件,重启MySQL后会自动生成新的日志文件的.

另一中则是这样的错误信息:

1. INIFilecode
2. InnoDB:Operatingsystemerrornumber5inafileoperation.InnoDB:TheerrormeansmysqlddoesnothavetheaccessrightstoInnoDB:thedirectory.ItmayalsobeyouhavecreatedasubdirectoryInnoDB:ofthesamenameasadatafile.InnoDB:Filename.ibdata1InnoDB:Fileoperationcall:‘open’.InnoDB:Cannotcontinueoperation.

经检查原来是“ibdata1”文件在复制的过程中不知怎的被加上只读属性了,解决方法是去掉“ibdata1”文件的只读属性便可.

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

[mysqld]

innodb_force_recovery = 4

innodb_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实现一种被认识为“模糊”检查点设置的检查点机制,InnoDB以小批量从缓冲池刷新已修改的数据库页,没必要以单个批次刷新缓冲池,单批次刷新实际操作中可能会在检查点设置进程中停止用户SQL语句的处理.

在崩溃恢复中，InnoDB找寻被写进日志的检查点标签。它知道所有在该标签之前对数据库的修改被呈现在数据库的磁盘映像中。然后InnoDB从检查点往前扫描日志文件，对数据库应用已写入日志的修改。

InnoDB以循环方式写日志文件,所有使得缓冲池里的数据库页与磁盘上的映像不同的已提交修改必须出现在日志文件中,以备万一InnoDB需要做一个恢复,这意味着,当InnoDB开始重新使用一个日志文件,它需要确认在磁盘上的数据库页映像包含已写进InnoDB准备重新使用的日志文件里的修改,换句话说,InnoDB必须创建一个检查点,这经常涉及已修改数据库页到磁盘的刷新.//phpfensi.com

前面的叙述解释了为什么使你的日志文件非常大会在设置检查点中节约磁盘I/O。设置日志文件总的大小和缓冲池一样大或者甚至比缓冲池大通常是有意义的。大日志文件的缺点是崩溃恢复要花更长的时间，因为有更多写入日志的信息要应用到数据库上。

把一个InnoDB数据库移到另一台机器

在Windows上， InnoDB 总是在内部以小写名字的方式存储数据库和表。要从Unix把二进制格式的数据库移到Windows，或者从Windows移到Unix，你应该让所有表和数据库的名字小写。要实现这个，一个方便的方式是在创建任何数据库和表之前，在你的my.cnf或my.ini文件的[mysqld]节内添加如下行：

[mysqld]

lower_case_table_names=1

类似于MyISAM数据文件,InnoDB数据和日志文件在所有有相同浮点数格式的平台上是二进制兼容的,你可以拷贝所有列在15.2.8节,“InnoDB数据库的备份和恢复”里的相关文件来简单地移动一个InnoDB数据库,如果浮点格式不同,但你没有在表中使用FLOAT或DOUBLE数据类型,则过程是一样:简单地拷贝相关文件,如果格式不容,且你的表包含浮点数据,你必须使用mysqldump在一台机器转储你的表,然后在另一台机器导入转储文件.

假设表空间有足够的空间供导入事务产生的大型回滚片断使用,则提高性能的一个方法是在导入数据时关掉autocommit模式,仅在导入整个表或表的一个片断之后提交.