主页 / computer / 问题 / 1425464
Accepted
Felix Stupp
Asked: 2019-04-15 17:19:55 +0800 CST

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

  • 772

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

linux debian mysql

1 个回答

  1. Best Answer

    我能够用 MySQL 本身恢复我的数据，诀窍是强制 InnoDB 恢复数据库/表。请参阅https://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html。我需要使用innodb_force_recovery = 6MySQL 来接受损坏的文件。

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

    • 0

相关问题