由于（页面文件写入错误），我的MySQL服务器运行崩溃。 我做了一个磁盘诊断，但没有发现错误。 我重新启动了MySQL服务器。 它像1-2小时扫描bin日志并logging日志如下：
InnoDB: Doing recovery: scanned up to log sequence number 51 2341175808 InnoDB: Doing recovery: scanned up to log sequence number 51 2346418688 InnoDB: Doing recovery: scanned up to log sequence number 51 2351661568 InnoDB: Doing recovery: scanned up to log sequence number 51 2356904448 InnoDB: Doing recovery: scanned up to log sequence number 51 2362147328 之后，我看到很多错误，如下所示：
InnoDB: Number of pending reads 128, pending pread calls 0 InnoDB: Error: InnoDB has waited for 50 seconds for pending InnoDB: reads to the buffer pool to be finished. InnoDB: Number of pending reads 128, pending pread calls 0 InnoDB: Error: InnoDB has waited for 50 seconds for pending InnoDB: reads to the buffer pool to be finished. InnoDB: Number of pending reads 128, pending pread calls 0 InnoDB: Error: InnoDB has waited for 50 seconds for pending InnoDB: reads to the buffer pool to be finished.
我有几个小时的等待，但它只是重复添加这些行到错误日志，没有迹象停止。
上面的日志消息是什么意思？ 我怎样才能让我的MySQL服务器再次运行？ 我有一个80GB的InnoDB数据库在这台服务器上运行。 有没有办法强制恢复它，而不撤消任何未完成的交易，或尝试从导致崩溃的页面文件恢复数据？ 我没有问题放弃这些数据。
我尝试了“sudo -u mysql / usr / sbin / mysqld –innodb_force_recovery = 6”重新启动MySQL服务器，但得到了新的重复错误，如下所示：
InnoDB: stored checksum 2440779633, prior-to-4.0.14-form stored checksum 3425185587 InnoDB: Page lsn 51 2450779673, low 4 bytes of lsn at page end 2450779673 InnoDB: Page number (if stored to page already) 10824, InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0 InnoDB: Page may be an index page where index id is 4294967295 0 InnoDB: (index "CLUST_IND" of table "SYS_IBUF_TABLE_0") InnoDB: Database page corruption on disk or a failed InnoDB: file read of page 10824. InnoDB: You may have to recover from a backup. InnoDB: It is also possible that your operating InnoDB: system has corrupted its own file cache InnoDB: and rebooting your computer removes the InnoDB: error. InnoDB: If the corrupt page is an index page InnoDB: you can also try to fix the corruption InnoDB: by dumping, dropping, and reimporting InnoDB: the corrupt table. You can use CHECK InnoDB: TABLE to scan your table for corruption. InnoDB: See also http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html InnoDB: about forcing recovery. InnoDB: Ending processing because of a corrupt database page.
我现在应该怎么做？
没有导致崩溃，MySQL版本和你的my.cnf错误，很难确定究竟是什么问题….这就是说，这里是一些通用的build议….
您可以通过多种方式find具有损坏页面的表格。 最简单的方法来closures服务器，并运行innochecksum对数据库中的所有表。 如果发现任何问题，可以通过设置innodb_force_recovery来启动数据库，并尝试运行表的SELECT INTO OUTFILE来转储内容，然后LOAD DATA FROM INFILE将其加载到新表中。 在1处启动innodb_force_recovery，如果在转储表时发生崩溃，请继续增加innodb_force_recovery值，直到您可以转储数据而不崩溃为止。 确保没有客户连接，而你这样做。
Percona还拥有用于InnoDB的Percona数据恢复工具 ，可以最大限度地减less停机时间，但是它们需要一些专业知识才能使用，并且有可能使事情变得更糟。 而且，实际上，你可以在一个实时数据库上运行innochecksum，但是你可能会为腐败的页面误报。 在这种情况下，您可以closures服务器，只有innochecksum返回页面错误的表。 在现场服务器上，一个成功的innochecksum将意味着表是好的，而一个失败的innochecksum可能不准确。
当你得到这个位置时，我build议创build一个这个数据库的奴隶，以便如果这再次发生，你可以很容易地开始使用奴隶，而不用担心复杂的恢复程序。
我得到了类似的错误，并在阅读https://dba.stackexchange.com/questions/24477/innodb-corruption后，我决定testing我的RAM。 这是有缺陷的…
我发现运行memtester，而不需要重新启动机器，并得到了很多：
FAILURE: 0x657423ee6593084d != 0x84e423ee6593084d at offset 0x16f17b1a0. FAILURE: 0x58c620a5a8e4984f != 0x783620a5a8e4984f at offset 0x16f3571a0. FAILURE: 0x73eba2598aaaa228 != 0x935ba2598aaaa228 at offset 0x16f3db1a0.
所以，如果你在一个稳定版本的mysql上有这个错误，而且重新启动可以修复你的问题，那很可能是一个RAM问题。 如果你注意错误信息，它说：
InnoDB: It is also possible that your operating InnoDB: system has corrupted its own file cache InnoDB: and rebooting your computer removes the InnoDB: error.
但是，也许你和我一样，拒绝相信这可能是一个硬件问题。