在我的 VM 服务器完全崩溃后，我不知道为什么，这个 Debian 上的 MariaDB 无法再次启动。error.log日志文件的内容：
2019-04-15 0:40:43 139787712552320 [Note] InnoDB: innodb_empty_free_list_algorithm has been changed to legacy because of small buffer pool size. In order to use backoff, increase buffer pool at least up to 20MB.
2019-04-15 0:40:43 139787712552320 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2019-04-15 0:40:43 139787712552320 [Note] InnoDB: The InnoDB memory heap is disabled
2019-04-15 0:40:43 139787712552320 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2019-04-15 0:40:43 139787712552320 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2019-04-15 0:40:43 139787712552320 [Note] InnoDB: Compressed tables use zlib 1.2.8
2019-04-15 0:40:43 139787712552320 [Note] InnoDB: Using Linux native AIO
2019-04-15 0:40:43 139787712552320 [Note] InnoDB: Using SSE crc32 instructions
2019-04-15 0:40:43 139787712552320 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2019-04-15 0:40:43 139787712552320 [Note] InnoDB: Completed initialization of buffer pool
2019-04-15 0:40:43 139787712552320 [Note] InnoDB: Highest supported file format is Barracuda.
InnoDB: No valid checkpoint found.
InnoDB: A downgrade from MariaDB 10.2.2 or later is not supported.
InnoDB: If this error appears when you are creating an InnoDB database,
InnoDB: the problem may be that during an earlier attempt you managed
InnoDB: to create the InnoDB data files, but log file creation failed.
InnoDB: If that is the case, please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/error-creating-innodb.html
2019-04-15 0:40:43 139787712552320 [ERROR] Plugin 'InnoDB' init function returned error.
2019-04-15 0:40:43 139787712552320 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2019-04-15 0:40:43 139787712552320 [Note] Plugin 'FEEDBACK' is disabled.
2019-04-15 0:40:43 139787712552320 [ERROR] Unknown/unsupported storage engine: InnoDB
2019-04-15 0:40:43 139787712552320 [ERROR] Aborting
我怀疑ibdata1，ib_logfile0并且ib_logfile1被破坏，因为我发现另一个线程
有人想将他们的数据库从一台服务器转移到另一台服务器，解决方案是在转移文件之前正确关闭服务器上的 MySQL。
如果我按照其他线程删除日志文件，这些线程声称 MySQL / InnoDB 可以恢复它们，服务器也会崩溃，但 InnoDB 会抱怨我可能忘记复制日志文件。请参阅日志这里（日志发布在 GitHub 上，对于 StackExchange 来说太长了）
如果我也删除了ibdata1，服务器会启动，但我无法访问数据库，因为“表‘xyz’在引擎中不存在”。
此主题提到我可以恢复我的数据，但我不能简单地按照解决方案操作，因为我必须将其应用到超过 200 个表。
我正在使用mysqld Ver 10.1.37-MariaDB-0+deb9u1 for debian-linux-gnu on x86_64 (Debian 9.6)
并且已经使用了 MariaDB for Debian 的默认配置，但以下内容除外：
[mysqld]
innodb_large_prefix=ON
innodb_file_format=barracuda
innodb_file_per_table=ON
有没有办法恢复或修复数据库数据？
PS：现在服务器将mysqldump每小时使用一次 cron 作业来防止出现最新转储已超过 2 个月的问题...
答案1
我能够使用 MySQL 本身恢复数据，诀窍是强制 InnoDB 恢复数据库/表。请参阅https://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html。我需要使用innodb_force_recovery = 6MySQL 来接受我的损坏的文件。
只有一张表看起来是不可恢复的，似乎这张表导致了不一致。