崩潰後 MySQL InnoDB 中的數據失去

我在 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備份確認所有數據都正確儲存。我想有一個 innodb 日誌刷新問題，但為什麼這麼大？

謝謝

對我來說，問題是作業系統崩潰或關機後**自動 WINDOWS RESTORE 。**令人難以置信的是，該程序替換了 IBD 文件（數據庫索引）！我解決了禁用 Windows 還原，我找不到任何方法來更改 mysql 索引文件副檔名或忽略 Windows 還原中的文件。

幾個月來我真的很生氣和擔心這個問題，我希望這可以幫助你。

該日誌僅表明您沒有正確關閉，因此在啟動時，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_commitset 以外的任何設置執行1，這是您的錯，因為這是一個危險的設置。如果您使用 執行它1，這意味著 InnoDB 正在請求將數據寫入磁碟並確認，但係統在寫入數據時向 InnoDB 撒謊，導致稍後損壞。

沒有辦法取回數據。如果您需要失去的數據，則必須從備份中恢復。

MyISAM 絕對不安全，事實上，在同樣的情況下，MyISAM 很可能會遭受嚴重的腐敗。

引用自：https://dba.stackexchange.com/questions/55495