MySQL 如果不涉及软件错误，是否会发生存储引擎无法恢复的 InnoDB 损坏？
Can MySQL InnoDB corruption occur that the storage engine cannot recover from if there is NO software bug involved?
我正在开发嵌入式 Linux 系统 运行 MySQL 5.1。在极少数情况下，由于 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 的大小限制外，没有什么特别之处。
问题
InnoDB 表是否有可能损坏并且恢复是不可能的 如果不涉及任何错误（在 MySQL 本身或例如错误的 fsync()执行）？即使所有软件组件都正常工作，是否存在可能导致损坏（无法从中恢复数据库）的情况？这样的DB能否在断电的环境下安全使用"in normal operation"？
我最终要问的是：
寻找解决此问题的方法是否有意义，或者根本没有解决此问题的方法？
如果不涉及任何错误（在 MySQL 本身或例如错误的 fsync() 实现中），InnoDB 表是否有可能损坏？
Yes, eg: hardware failure
是否存在即使所有软件组件都正常工作也可能导致损坏的情况？
Yes, eg: hardware failure
这样的数据库能否在发生断电的环境中安全使用"in normal operation"？
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() 系统调用实际上可能 return 在数据被刷新到稳定存储之前。因此，操作系统崩溃或断电可能会破坏最近提交的数据，或者在最坏的情况下，甚至会因为写入操作被重新排序而破坏数据库。如果数据完整性对您很重要，请在生产中使用任何东西之前执行一些“即插即用”测试。在 OS X 10.3 及更高版本上，InnoDB 使用特殊的 fcntl() 文件刷新方法。在Linux下，建议禁用回写缓存。
在 ATA/SATA 磁盘驱动器上，hdparm -W0 /dev/hda 等命令可能会禁用回写缓存。请注意，某些驱动器或磁盘控制器可能无法禁用回写缓存。
关于保护用户数据的 InnoDB 恢复功能，InnoDB 使用文件刷新技术涉及称为双写缓冲区的结构，默认情况下启用 (innodb_doublewrite=ON)。双写缓冲区增加了崩溃或断电后恢复的安全性，并通过减少对 fsync() 操作的需要提高了大多数 Unix 的性能。如果您担心数据完整性或可能的故障，建议 innodb_doublewrite 选项保持启用状态。有关双写缓冲区的其他信息，请参阅第 14.9 节，“InnoDB 磁盘 I/O 和文件 Space 管理”。
注意
如果可靠性是您数据的考虑因素，请不要将 InnoDB 配置为使用 NFS 卷上的数据文件或日志文件。潜在问题因 OS 和 NFS 版本而异，包括缺乏防止写入冲突的保护以及最大文件大小限制等问题。
您是否升级了MySQL版本，但是运行mysql_upgrade失败了？这就是错误的意思。
我终于找到了根本原因。 InnoDB 表实际上并没有出现问题，而是系统表出现了问题。
在MySQL5.1系统表中使用MyISAM引擎存储。这使得这些表在断电时非常脆弱。
对于所有系统表，MYI（索引）和 MYD（数据）文件的内容都丢失了。
缺少此数据 - 当然 - 其余数据库有问题...
对我来说重要的提示是
mysql.plugin table
最后查看了包含系统表的目录，发现它们正在使用 MyISAM 存储引擎。那么后果就很明显了。
（仅）解决方案：
转到较新的版本（在我的案例中我使用的是 MariaDB）。
您 不能 使用 InnoDB 作为 MySQL 5.1.
系统表的存储引擎
我正在开发嵌入式 Linux 系统 运行 MySQL 5.1。在极少数情况下，由于 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 的大小限制外，没有什么特别之处。
问题
InnoDB 表是否有可能损坏并且恢复是不可能的 如果不涉及任何错误（在 MySQL 本身或例如错误的 fsync()执行）？即使所有软件组件都正常工作，是否存在可能导致损坏（无法从中恢复数据库）的情况？这样的DB能否在断电的环境下安全使用"in normal operation"？ 我最终要问的是： 寻找解决此问题的方法是否有意义，或者根本没有解决此问题的方法？
如果不涉及任何错误（在 MySQL 本身或例如错误的 fsync() 实现中），InnoDB 表是否有可能损坏？
Yes, eg: hardware failure
是否存在即使所有软件组件都正常工作也可能导致损坏的情况？
Yes, eg: hardware failure
这样的数据库能否在发生断电的环境中安全使用"in normal operation"？
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() 系统调用实际上可能 return 在数据被刷新到稳定存储之前。因此，操作系统崩溃或断电可能会破坏最近提交的数据，或者在最坏的情况下，甚至会因为写入操作被重新排序而破坏数据库。如果数据完整性对您很重要，请在生产中使用任何东西之前执行一些“即插即用”测试。在 OS X 10.3 及更高版本上，InnoDB 使用特殊的 fcntl() 文件刷新方法。在Linux下，建议禁用回写缓存。
在 ATA/SATA 磁盘驱动器上，hdparm -W0 /dev/hda 等命令可能会禁用回写缓存。请注意，某些驱动器或磁盘控制器可能无法禁用回写缓存。
关于保护用户数据的 InnoDB 恢复功能，InnoDB 使用文件刷新技术涉及称为双写缓冲区的结构，默认情况下启用 (innodb_doublewrite=ON)。双写缓冲区增加了崩溃或断电后恢复的安全性，并通过减少对 fsync() 操作的需要提高了大多数 Unix 的性能。如果您担心数据完整性或可能的故障，建议 innodb_doublewrite 选项保持启用状态。有关双写缓冲区的其他信息，请参阅第 14.9 节，“InnoDB 磁盘 I/O 和文件 Space 管理”。 注意
如果可靠性是您数据的考虑因素，请不要将 InnoDB 配置为使用 NFS 卷上的数据文件或日志文件。潜在问题因 OS 和 NFS 版本而异，包括缺乏防止写入冲突的保护以及最大文件大小限制等问题。
您是否升级了MySQL版本，但是运行mysql_upgrade失败了？这就是错误的意思。
我终于找到了根本原因。 InnoDB 表实际上并没有出现问题，而是系统表出现了问题。
在MySQL5.1系统表中使用MyISAM引擎存储。这使得这些表在断电时非常脆弱。
对于所有系统表，MYI（索引）和 MYD（数据）文件的内容都丢失了。
缺少此数据 - 当然 - 其余数据库有问题...
对我来说重要的提示是
mysql.plugin table
最后查看了包含系统表的目录，发现它们正在使用 MyISAM 存储引擎。那么后果就很明显了。
（仅）解决方案：
转到较新的版本（在我的案例中我使用的是 MariaDB）。 您 不能 使用 InnoDB 作为 MySQL 5.1.
系统表的存储引擎