主页 / dba / 问题 / 55495
Accepted
Tobia
Asked: 2013-12-24 04:47:07 +0800 CST

崩溃后 MySQL InnoDB 中的数据丢失

  • 772

我在 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 日志刷新问题，但为什么这么大？

谢谢

innodb mysql-5.6

2 个回答

  1. 该日志仅表明您没有正确关闭，因此在启动时，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 很可能会遭受严重的腐败。

    • 2
  2. Best Answer

    对我来说，问题是操作系统崩溃或关机后自动 WINDOWS RESTORE 。令人难以置信的是，该程序替换了 IBD 文件（数据库索引）！我解决了禁用 Windows 还原，我找不到任何方法来更改 mysql 索引文件扩展名或忽略 Windows 还原中的文件。

    几个月来我真的很生气和担心这个问题，我希望这可以帮助你。

    • 2

相关问题