Question

我正在开发运行MySQL 5.1的嵌入式Linux系统。在极少数情况下，由于mysqld无法启动，QA报告系统无法正常启动。如果发生这种情况，MySQL日志文件看起来与此摘录类似：

150716 14:29:42  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
150716 14:29:42  InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 0 133478.
InnoDB: Doing recovery: scanned up to log sequence number 0 133478
150716 14:29:42  InnoDB: Started; log sequence number 0 133478
/usr/libexec/mysqld: Unknown error 130
150716 14:29:42 [ERROR] Can't open the mysql.plugin table. Please run the mysql_upgrade script to create it.
150716 14:29:42 [ERROR] Fatal error: Can't open and lock privilege tables: Incorrect file format 'host'

这可能是因为这是一个没有电源开关的嵌入式设备，它通过拔掉网络电缆断电，从而导致PoE电源中断。在这种情况下，mysqld当然会非常异常终止。

my.cnf除了大小限制为18 MB外，没有什么特别之处。

问题

如果没有涉及错误（在MySQL本身或者例如错误的fsync（）实现中），InnoDB表是否可能被破坏并且恢复是不可能的？即使所有软件组件都正常工作，是否存在可能导致损坏（数据库无法恢复）的情况？这种数据库能否安全地用于“正常运行”中发生电源故障的环境？我最终要问的是：有没有必要寻找这个问题的解决方案，还是没有解决这个问题？

Answer 1

如果没有涉及错误（在MySQL本身或者例如错误的fsync（）实现中），InnoDB表是否可能被破坏？

Yes, eg: hardware failure

即使所有软件组件都正常工作，是否存在可能导致损坏的情况？

Yes, eg: hardware failure

这种数据库是否可以在“正常运行”中发生电源故障的环境中安全使用？

Yes, only if your hardware works "normally"

我最终要问的是：是否有必要寻找解决此问题的方法，或者无法解决此问题？

Usually it's very difficult to fix the database if you meet a corruption. Do backup.

本文可能对您有所帮助： https://dev.mysql.com/doc/refman/5.6/en/innodb-init-startup-configuration.html

注意

InnoDB是一种适用于MySQL的事务安全（ACID兼容）存储引擎，具有提交，回滚和崩溃恢复功能，可保护用户数据。但是，如果底层操作系统或硬件不像宣传的那样工作，则不能这样做。许多操作系统或磁盘子系统可能会延迟或重新排序写入操作以提高性能。在某些操作系统上，应该等到文件的所有未写入数据都已刷新的fsync（）系统调用实际上可能在数据刷新到稳定存储之前返回。因此，操作系统崩溃或断电可能会破坏最近提交的数据，或者在最坏的情况下，甚至会因为重新排序写入操作而损坏数据库。如果数据完整性对您很重要，请在使用生产中的任何内容之前执行一些“拔插”测试。在OS X 10.3及更高版本中，InnoDB使用特殊的fcntl（）文件刷新方法。在Linux下，建议禁用回写缓存。

在ATA / SATA磁盘驱动器上，hdparm -W0 / dev / hda等命令可能会禁用回写缓存。请注意，某些驱动器或磁盘控制器可能无法禁用回写缓存。

关于保护用户数据的InnoDB恢复功能，InnoDB使用文件刷新技术，该技术涉及称为doublewrite缓冲区的结构，默认情况下启用（innodb_doublewrite = ON）。双写缓冲区可在崩溃或停电后为恢复增加安全性，并通过减少对fsync（）操作的需求来提高大多数Unix的性能。如果您担心数据完整性或可能的故障，建议保持启用innodb_doublewrite选项。有关doublewrite缓冲区的更多信息，请参见第14.9节“InnoDB磁盘I / O和文件空间管理”。注意

如果可靠性是您数据的考虑因素，请不要将InnoDB配置为在NFS卷上使用数据文件或日志文件。潜在的问题根据操作系统和NFS的版本而有所不同，包括缺少写入冲突的保护以及最大文件大小限制等问题。

Answer 2

您是否升级了MySQL版本，但无法运行mysql_upgrade？这就是错误所说的。

Answer 3

我终于找到了根本原因。 InnoDB表实际上并没有出现这个问题，而是使用系统表。

在MySQL 5.1中，使用MyISAM引擎存储系统表。这使得这些表在断电时非常脆弱。

对于所有系统表，MYI（索引）和MYD（数据）文件的内容都丢失了。

缺少这些数据 - 当然 - 其他数据库都有问题......

对我来说重要的提示是

mysql.plugin表

最后查看包含系统表的目录，看到他们正在使用MyISAM存储引擎。然后后果非常明显。

（仅）解决方案：

转到更新的版本（在我的情况下我使用了MariaDB）。您不能使用InnoDB作为MySQL 5.1上系统表的存储引擎。

如果没有涉及软件错误，是否会发生MySQL InnoDB损坏，存储引擎无法恢复？

3 个答案: