崩溃后在MySQL InnoDB中丢失的数据

Question

我在MySQL 5.6社区版服务器安装中发现了6天的回滚。似乎有些原木丢失了，我不明白为什么。

2013-12-22 20:38:54 380 [Note] Plugin 'FEDERATED' is disabled.
2013-12-22 20:38:54 380 [Warning] option 'innodb-autoextend-increment': unsigned value 67108864 adjusted to 1000
2013-12-22 20:38:54 388 InnoDB: Warning: Using innodb_additional_mem_pool_size is DEPRECATED. This option may be removed in future releases, together with the option innodb_use_sys_malloc and with the InnoDB's internal memory allocator.
2013-12-22 20:38:54 380 [Note] InnoDB: The InnoDB memory heap is disabled
2013-12-22 20:38:54 380 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions
2013-12-22 20:38:54 380 [Note] InnoDB: Compressed tables use zlib 1.2.3
2013-12-22 20:38:54 380 [Note] InnoDB: Not using CPU crc32 instructions
2013-12-22 20:38:54 380 [Note] InnoDB: Initializing buffer pool, size = 86.0M
2013-12-22 20:38:54 380 [Note] InnoDB: Completed initialization of buffer pool
2013-12-22 20:38:54 380 [Note] InnoDB: Highest supported file format is Barracuda.
2013-12-22 20:38:54 380 [Note] InnoDB: The log sequence numbers 5988825 and 5988825 in ibdata files do not match the log sequence number 6057379 in the ib_logfiles!
2013-12-22 20:38:54 380 [Note] InnoDB: Database was not shutdown normally!
2013-12-22 20:38:54 380 [Note] InnoDB: Starting crash recovery.
2013-12-22 20:38:54 380 [Note] InnoDB: Reading tablespace information from the .ibd files...
2013-12-22 20:38:57 380 [Note] InnoDB: Restoring possible half-written data pages 
2013-12-22 20:38:57 380 [Note] InnoDB: from the doublewrite buffer...
2013-12-22 20:39:07 380 [Note] InnoDB: 128 rollback segment(s) are active.
2013-12-22 20:39:07 380 [Note] InnoDB: Waiting for purge to start
2013-12-22 20:39:07 380 [Note] InnoDB: 5.6.13 started; log sequence number 6057379
2013-12-22 20:39:07 380 [Note] Server hostname (bind-address): '*'; port: 3306
2013-12-22 20:39:07 380 [Note] IPv6 is available.
2013-12-22 20:39:07 380 [Note]   - '::' resolves to '::';
2013-12-22 20:39:07 380 [Note] Server socket created on IP: '::'.
2013-12-22 20:39:12 380 [Note] Event Scheduler: Loaded 0 events
2013-12-22 20:39:12 380 [Note] C:/Program Files/MySQL/MySQL Server 5.6/bin\mysqld: ready for connections.

您能告诉我为什么会发生这种情况，以及如何恢复数据吗？是可能的吗？您认为MyISAM表更安全吗?一个开关可以解决这种错误吗？

编辑

关于这个谜题的更多信息。

• 这台机器有RAID-1卷.
• 这个问题在12月22日停电之后就已经开始出现了。断电后，我得到了以前的日志，我的数据库有很多天的数据回滚。我发现数据库与12月14日的数据完全吻合。
• 从12月14日到21日，有许多优雅的服务器关闭(每天晚上)，我发现从12月14日至21日每天都有一个完整的备份。12月22日的备份有8天的数据间隔。

我觉得这很奇怪。我可以理解断电后的数据丢失，但我无法理解这么大的回滚(8天)，因为在这8天中有许多服务器关闭和mysqldump备份确认所有数据都被正确存储。我以为有一个无害的日志刷新问题，但为什么这么大？

谢谢

Answer 1

对我来说，问题是操作系统崩溃或断电后的自动窗口恢复。令人难以置信的是，这个过程取代了IBD文件(数据库索引)！我解决了禁用windows还原的问题，无法找到任何方法更改mysql索引文件扩展名或忽略windows还原中的文件。

几个月来，我真的为这个问题生气和担心，我希望这能帮到你。

Answer 2

这个日志只是表示您没有正确关闭，因此在启动时，InnoDB必须执行“崩溃恢复”。丢失数据的不是崩溃恢复--而是你的操作系统或硬件。崩溃恢复实际上是为了避免因崩溃而丢失数据(这是其全部目的)。

日志消息表示存在严重问题：

The log sequence numbers 5988825 and 5988825 in ibdata files do not match the log sequence number 6057379 in the ib_logfiles!

这可能意味着，由于MySQL中的错误配置，或者由于操作系统或硬件的错误配置，数据无法有效地到达磁盘。

如果将innodb_flush_log_at_trx_commit设置为1以外的任何内容，则这是您的错误，因为这是一个危险的设置。如果您使用1运行它，这将意味着InnoDB请求将数据写入磁盘并进行确认，但是系统正在欺骗InnoDB编写数据，从而导致以后的损坏。

没有办法把数据拿回来。如果需要丢失的数据，则必须从备份还原数据。

MyISAM绝对不是更安全，事实上，在同样的情况下，MyISAM很可能会遭受极端的腐败。