如果mysql数据库的innodb日志文件丢失会怎么样?

我做的是

/etc/init.d/mysql stop

然后删除文件:ib_logfile0,ib_logfile1

然后修改了my.cnf文件,变量:innodb_log_file_size

然后:

/etc/init.d/mysql start

并允许重新创建文件

我后来发现全局变量innodb_fast_shutdown设置为“1”

问题是,丢失了多少数据?

注意:我仍然有旧文件ib_logfile0,ib_logfile1,尚未删除.

依赖数据库的网站似乎正在运作.

解决方法:

首先要做的事情是:不实际删除文件的理由 – 移动文件总是比删除它们更好 – 但不要试图将旧的日志文件放回去.

您可能能够分析它们,但是您无法将它们重新投入使用,因为日志文件中的日志序列号(LSN)与ibdata中存储的日志序列号不匹配.

InnoDB:                          WARNING!
InnoDB: The log sequence number in ibdata files is higher
InnoDB: than the log sequence number in the ib_logfiles! Are you sure
InnoDB: you are using the right ib_logfiles to start up the database?

它很可能会开始崩溃恢复,并可能开始“修复”未被破坏的东西……所以,我绝对不会尝试这个.

The question is, how much data was lost?

如果丢失了任何数据,那么最近的更改(插入/更新/删除);然而,与我一直认为的完全相反,将innodb_fast_shutdown设置为1(但不是2)时所做的事情实际上是安全的.

http://dev.mysql.com/doc/refman/5.5/en/innodb-data-log-reconfiguration.html

这些指示意味着只要它没有设置为’2’就可以了,如果设置为’2′,他们会说它设置为’1′ – 而不是’0′,就像我想的那样已经预料到…所以看起来你要么好,要么文档中有一个相当严重的缺陷.

上一篇:linux – InnoDB日志序列号是未来的


下一篇:如何在mysql中修复或删除/创建损坏的表?