我的 mysql 服务器 5.7 崩溃了，即使添加了 innodb_force_recovery 也无法启动。我尝试了 innodb_force_recovery= 1 到 6 的所有值，但没有任何效果。
请帮忙现在该做什么以及如何手动或使用其他库恢复/修复损坏的 InnoDB 表？
我没有备份，只剩下大小约为 10GB 的损坏的 InnoDB 表文件。
每次尝试后，系统日志都会显示以下几行：
May 21 10:02:33 server2 kernel: [ 3137.604417] audit: type=1400 audit(1495341153.370:19): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/sbin/mysqld" pid=24185 comm="apparmor_parser"
May 21 10:02:33 server2 mysqld_safe: Logging to '/var/log/mysql/error.log'.
May 21 10:02:33 server2 mysqld_safe: Logging to '/var/log/mysql/error.log'.
May 21 10:02:33 server2 mysqld_safe: Starting mysqld daemon with databases from /var/lib/mysql
May 21 10:02:33 server2 mysqld[24557]: /usr/sbin/mysqld (mysqld 5.7.17) starting as process 24557 ...
May 21 10:02:33 server2 mysqld[24557]: InnoDB: PUNCH HOLE support available
May 21 10:02:33 server2 mysqld[24557]: InnoDB: Mutexes and rw_locks use GCC atomic builtins
May 21 10:02:33 server2 mysqld[24557]: InnoDB: Uses event mutexes
May 21 10:02:33 server2 mysqld[24557]: InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
May 21 10:02:33 server2 mysqld[24557]: InnoDB: Compressed tables use zlib 1.2.3
May 21 10:02:33 server2 mysqld[24557]: InnoDB: Using Linux native AIO
May 21 10:02:33 server2 mysqld[24557]: InnoDB: Number of pools: 1
May 21 10:02:33 server2 mysqld[24557]: InnoDB: Using CPU crc32 instructions
May 21 10:02:33 server2 mysqld[24557]: InnoDB: Initializing buffer pool, total size = 1G, instances = 8, chunk size = 128M
May 21 10:02:33 server2 mysqld[24557]: InnoDB: Completed initialization of buffer pool
May 21 10:02:33 server2 mysqld[24557]: InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
May 21 10:02:33 server2 mysqld[24557]: InnoDB: Highest supported file format is Barracuda.
May 21 10:02:33 server2 mysqld[24557]: InnoDB: Log scan progressed past the checkpoint lsn 1903477238014
May 21 10:02:33 server2 mysqld[24557]: InnoDB: Doing recovery: scanned up to log sequence number 1903482480640
May 21 10:02:34 server2 mysqld[24557]: InnoDB: Doing recovery: scanned up to log sequence number 1903478876160
May 21 10:02:34 server2 mysqld[24557]: InnoDB: Doing recovery: scanned up to log sequence number 1903484119040
May 21 10:02:34 server2 mysqld[24557]: InnoDB: Doing recovery: scanned up to log sequence number 1903486713411
May 21 10:02:34 server2 mysqld[24557]: InnoDB: Database was not shutdown normally!
May 21 10:02:34 server2 mysqld[24557]: InnoDB: Starting crash recovery.
May 21 10:02:34 server2 mysqld[24557]: InnoDB: Space id and page no stored in the page, read in are [page id: space=0, page number=224284], should be [page id: space=0, page number=360462]
May 21 10:02:34 server2 mysqld[24557]: InnoDB: Database page corruption on disk or a failed file read of page [page id: space=0, page number=360462]. You may have to recover from a backup.
May 21 10:02:34 server2 mysqld[24557]: InnoDB: Page dump in ascii and hex (16384 bytes):
May 21 10:02:34 server2 mysqld[24557]: InnoDB: Uncompressed page, stored checksum in field1 1176070173, calculated checksums for field1: crc32 1474463089/3411817011, innodb 1277319011, none 3735928559, stored checksum in field2 2383263673, calculated checksums for field2: crc32 1474463089/3411817011, innodb 3335309735, none 3735928559, page LSN 443 804368015, low 4 bytes of LSN at page end 801385784, page number (if stored to page already) 224284, space id (if created with >= MySQL-4.1.1 and stored already) 0
May 21 10:02:34 server2 mysqld[24557]: InnoDB: It is also possible that your operating system has corrupted its own file cache and rebooting your computer removes the error. If the corrupt page is an index page. You can also try to fix the corruption by dumping, dropping, and reimporting the corrupt table. You can use CHECK TABLE to scan your table for corruption. Please refer to http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html for information about forcing recovery.
May 21 10:02:34 server2 mysqld[24557]: [FATAL] InnoDB: Aborting because of a corrupt database page in the system tablespace. Or, there was a failure in tagging the tablespace as corrupt.
May 21 10:02:34 server2 mysqld_safe: mysqld from pid file /var/run/mysqld/mysqld.pid ended
答案1
MySQL 在日志信息中以简单易懂的英语提供了如此多的建议，难道不是很精彩吗？！
InnoDB：也可能是您的操作系统损坏了其自身的文件缓存，重新启动计算机即可消除错误。如果损坏的页面是索引页。您还可以尝试通过转储、删除和重新导入损坏的表来修复损坏。您可以使用
CHECK TABLE扫描表以查找损坏。请参阅 http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html 了解有关强制恢复的信息。
这是您已经尝试过的方法。当您仍然无法启动它时，显然不可能通过运行任何 SQL 查询或命令来通过转储数据库重新导入来解决这个问题。如果您之前也重新启动过innodb_force_recovery，那么这只剩下最后一个选项，也是从日志中找到的：
InnoDB：磁盘上的数据库页面损坏或页面的文件读取失败
[page id: space=0, page number=360462]。您可能需要从备份中恢复。
您确实有备份，对吗？
如果没有备份，你最后的希望可能是Percona InnoDB 数据恢复工具。
该项目是一套用于从 InnoDB 数据文件中恢复丢失或损坏的 MySQL 数据的工具。它由 Percona 创建，并开源供社区使用。
我与 Percona 没有任何关系，只推荐开源工具和文档。
答案2
你设置innodb_force_recovery=1和默认innodb_purge_threads = 1 复制代码或 1+ 数字，在日志中它们将循环：InnoDB：等待后台线程启动
因此 mysqld 无法启动，您需要：
innodb_force_recovery=3
innodb_purge_threads=0