Question

我正在进行环境设置，使用MariaDB 10.0.12-MariaDB Homebrew

运行OSX

我搞砸了安装，所以我完全从我的设置中删除了MySQL和MariaDB，然后重新开始。

完成MariaDB的安装后，我从生产服务器通过DB Dump重新导入了我的数据库（innoDB）。它工作正常。重新启动后，第二天，我无法再访问数据库：

Table 'my.table' doesn't exist in engine

造成这种情况的原因是什么？解决方案是什么？我确实看到了我的数据库的结构，但是当我尝试访问它时，它给了我这个错误信息。

我确实尝试mysql-upgrade --force并删除了rm ib_logfile1 ib_logfile0

此处数据丢失不是问题，问题是每次重新启动时我都不能花30分钟重新安装每个数据库。

这是一些日志：

140730  9:24:13 [Note] Server socket created on IP: '127.0.0.1'.
140730  9:24:14 [Note] Event Scheduler: Loaded 0 events
140730  9:24:14 [Warning] InnoDB: Cannot open table mysql/gtid_slave_pos from the internal data dictionary of InnoDB though the .frm file for the table exists. See http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html for how you can resolve the problem.
140730  9:24:14 [Warning] Failed to load slave replication state from table mysql.gtid_slave_pos: 1932: Table 'mysql.gtid_slave_pos' doesn't exist in engine
140730  9:24:14 [Note] /usr/local/Cellar/mariadb/10.0.12/bin/mysqld: ready for connections.
Version: '10.0.12-MariaDB'  socket: '/tmp/mysql.sock'  port: 3306  Homebrew
140730 16:26:28 [Warning] InnoDB: Cannot open table db/site from the internal data dictionary of InnoDB though the .frm file for the table exists. See http://dev.mysql.com/doc/refman/5.6/en/innodb-troubleshooting.html for how you can resolve the problem.

Answer 1

有些东西删除了你的ibdata1文件，其中InnoDB保存了字典。绝对不是MySQL谁做的。

Answer 2

好的伙计们，本周末，当我的OpenStack环境崩溃时，我遇到了这个问题。关于如何恢复即将到来的另一篇文章。

我找到了一个适用于我的解决方案，其中一个SQL Server实例运行在Ver 15.1 Distrib 10.1.21-MariaDB下，Fedora 25 Server作为主机。如果您完全复制了旧的mariadb-server＆var / lib / mysql目录并且您正在复制的数据库尚未损坏，请不要收听所有其他说您的数据库已损坏的帖子。此过程基于操作系统已损坏但其文件仍可访问的系统。

以下是我遵循的步骤。

确保仅在新服务器上完全卸载了当前版本的SQL。此外，请确保运行以下命令已停止NEW AND OLD服务器上的所有mysql-server或mariadb-server进程：

service mysqld stop或service mariadb stop。
在新的SQL服务器上，进入/ var / lib / mysql目录，确保该目录中根本没有文件。如果此目录中有文件，则从新计算机中删除数据库服务器的过程不起作用，可能已损坏。确保从新机器上完全卸载它。
在OLD SQL服务器上：

mkdir / OLDMYSQL-DIR cd / OLDMYSQL-DIR tar cvf mysql-olddirectory.tar / var / lib / mysql gzip mysql-olddirectory.tar
确保在OLD和NEW服务器上都运行sshd。确保两台服务器之间存在网络连接。
在新SQL服务器上：

mkdir / NEWMYSQL-DIR
在OLD SQL服务器上：

cd / OLDMYSQL-DIR scp mysql-olddirectory.tar.gz @：/ NEWMYSQL-DIR
在新SQL服务器上：

cd / NEWMYSQL-DIR gunzip mysql-olddirectory.tar.gz或tar zxvf mysql-olddirectory.tar.gz （如果tar zxvf不起作用）tar xvf mysql-olddirectory.tar.gz
你现在应该有一个＆＃34; mysql＆＃34;目录文件位于NEWMYSQL-DIR中。抵制运行＆＃34; cp＆＃34;没有开关的命令。不起作用。运行以下＆＃34; cp＆＃34;命令并确保您使用我所做的相同开关。

cd mysql / cp -rfp * / var / lib / mysql /
现在，您应该拥有新服务器上所有旧SQL服务器文件的副本，并且具有权限。在新的SQL服务器上：

cd / var / lib / mysql /

非常重要的一步。请勿跳过

> rm -rfp ib_logfile*

现在在NEW SQL服务器上安装mariadb-server或mysql-server。如果您已经安装和/或运行它，那么您没有按照说明进行操作，这些步骤将失败。

FOR MARIADB-SERVER和DNF：

> dnf install mariadb-server
> service mariadb restart

FOR MYSQL-SERVER和YUM：

> yum install mysql-server
> service mysqld restart

Answer 3

您可以尝试：

从C：\ xampp \ mysql \ data备份数据库文件夹（.frm＆amp; .ibd文件仅对应您的表名）
在C：\ xampp \ mysql \ data
修改my.ini add
```
[mysqld]
innodb_file_per_table = on
```
然后打开phpmyadmin（或任何其他数据库查看器，如Navicat或MYSQL Workbench）并运行
```
ALTER TABLE tbl_name IMPORT TABLESPACE 
```
每张表
一旦打开你的表，就可以进行完整的mysql转储
删除所有内容并进行全新安装

我知道，做很多工作你不需要它。

Answer 4

我刚刚在MariaDB / InnoDB中遇到了这个问题，并且能够通过

对其进行修复

在另一个MySQL / MariaDB实例的正确数据库中创建所需表
停止两个服务器
将.ibd，.frm文件复制到原始服务器
启动两个服务器
在两个服务器上删除问题表

Answer 5

就我而言，重新启动操作系统并重新启动MariaDB服务器后，错误消失了。奇怪。

Answer 6

这个真的很烂。

我尝试了这里建议的所有解决方案，但唯一可行的是

创建一个新数据库
在所有正常运行的表上运行ALTER TABLE old_db.{table_name} RENAME new_db.{table_name}
运行DROP old_db
再次创建old_db
在ALTER TABLE new_db.{table_name} RENAME old_db.{table_name}中的所有表上运行new_db

完成后，您终于可以再次创建以前拥有的表。

Answer 7

此主题需要一段时间才能找到结果和原因：

使用MaiaDB 5.4。通过SuSE-LINUX tumblweed

与mariadb的任何直接关系都不需要指定目录中的某些文件。即：我在mysql mariadb的同一指定目录中的某些地方放置了一些提示，文本文件，一些bakup副本，这导致了无尽的错误消息并阻止了服务器启动。 Mariadb似乎非常明智且充满敌意，因为存在其他文件而不是数据库文件（注释，备份，实验性文件等）。
使用libreoffice作为客户端，然后已经在创建和使用数据库方面产生了很多问题，并导致了一些崩溃。崩溃最终产生了错误的表。
可能是因为这个原因，或者可能是因为存在尚未删除但无法使用的表！ mysql mariadb服务器崩溃，并且甚至不想做。

错误消息始终相同：“表'some.table'在引擎中不存在”

但是，当它开始时，表似乎是正常的，但是无法对其进行处理。

那么如果没有更精确的错误消息怎么办？不能使用的表显示为：“ CHECK TABLE”或在系统的命令行上显示为“ mysqlcheck” 因此，我以root或允许用户的身份通过filemanager或在系统级删除了所有可疑文件，然后解决了问题。

建议：错误消息可能更准确一些，例如： “损坏的表”（可以在CHECK TABLE中找到，但仅在服务器正在运行时才能找到）或通过mysqlcheck甚至在服务器未运行的情况下-但这是其他不可见的文件，如提示/ bakups a.s.o。

无论如何，在备份卷上保留原始数据库文件的备份副本很有帮助。这有助于检查并反复测试，直到找到解决方案为止。

祝你好运-赫伯特

Answer 8

我有不支持的旧 MySQL 和 Centos 操作系统（我相信是 6 版）。
有一天我无法访问 Plesk。
使用 Filezilla，我从 var/lib/mysql/databasename/ 复制了数据库文件然后我购买了一台带有新 Centos 8 操作系统和 MariaDB 的新服务器。在 Plesk 中，我创建了一个与旧数据库同名的新数据库。
使用 Filezilla，然后我将旧的数据库文件粘贴到新创建的数据库文件夹中。我可以在 phpmyadmin 中看到数据，但它给出了诸如此处描述的错误。我碰巧有一个旧的 sql 备份转储文件。我导入了转储文件，它覆盖了这些文件。然后我将旧文件粘贴回 var/lib/mysql/databasename/ 然后我不得不在 Plesk 中进行修复。令我惊讶。有效。我恢复了超过 6 个月的订单数据，我没有丢失任何东西。

Answer 9

在我的情况下，数据库完全正常工作，但是当我连接到数据库时，错误在工作台中弹出而没有任何后果。我发现引擎中不存在的表是我从数据库中删除的旧表（我不再需要它）。但是不知怎么的，我不小心把这个表的一些备份文件复制到了数据库的字典中（.frm和.ibd文件），删除后，错误消失了。

MariaDB数据库损坏：表格不存在于引擎中

9 个答案: