在我的 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 个月的问题......