☰

MariaDB 服务器无法启动：“InnoDB：未找到有效的检查点。”

tag-icon • tag-icon linux debian mysql mariadb innodb
MariaDB 服务器无法启动：“InnoDB：未找到有效的检查点。”

在我的 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 来接受我的损坏的文件。

只有一张表看起来是不可恢复的，似乎这张表导致了不一致。

相关内容