错误原因：无效（旧？）表或数据库名称 'lost+found'

Question

我的 MySQL 日志显示重复的错误：

141223  5:47:21 [ERROR] Invalid (old?) table or database name 'lost+found'

我有一个名为的数据库，#mysql50#lost+found但我似乎无法删除它。

mysql> show databases;
+---------------------+
| Database            |
+---------------------+
| information_schema  |
| maindatabas         |
| maindatabas_help    |
| maindatabas_tracker |
| gitlabhq_production |
| locations           |
| #mysql50#lost+found |
| mysql               |
| osticket            |
| performance_schema  |
+---------------------+
10 rows in set (0.00 sec)

mysql> DROP DATABASE `#mysql50#lost+found`;
ERROR 1008 (HY000): Can't drop database '#mysql50#lost+found'; database doesn't exist
mysql>

我正在运行服务器版本：5.5.40，由 Centos 6 上的 IUS 社区项目分发。

每个MySQL 在 CentOS 6x（不是 5x）上运行非常慢，我的 datadir 在 ext3 上，带有 barrier=0 选项。

是什么导致了这个错误，如何消除它？

Answer 1

在我看来，您datadir在自己的文件系统中。

Ext 文件系统，就像 Unix 下的大多数 FS 一样，在它们的根目录下有一个名为lost+found. 它的存在是为了在 fscked 不一致的文件系统时允许将分离的文件（即，它们具有内容，但没有关联的目录条目）重新附加到某处（参见，例如https://unix.stackexchange.com/问题/18154/what-is-the- purpose-of-the-lostfound-folder-in-linux-and-unix了解更多详细信息）。此目的在灾难恢复中很重要，因此您不应删除该目录。

当挂载包含该目录的文件系统的挂载点完全交给一个期望该挂载点中的所有内容都属于它的应用程序时，您的问题就会出现。MySQL就是这样，它试图将lost+found目录解释为与数据库相关的东西，并且（并非不合理）失败。

最好的办法是永远不要将整个 FS 专用于一个应用程序，而是将 FS 挂载在某个应用程序非特定的挂载点上，例如/data1，在该挂载点下创建一个子目录，例如/data1/mysql，并重新配置应用程序以使用该目录作为其数据目录。

Answer 2

MadHatter 很好地解释了错误。但从那时起，时代发生了变化，现在 MySQL（自 5.6.3 起）可以选择忽略此目录。只需将此语句添加到您的/etc/mysql/my.cnf文件中：

ignore-db-dir=lost+found

MySQL重新启动后，您可以使用以下命令进行检查：

show global variables like 'ignore_db_dirs';

如果要忽略多个目录，则需要分别为每个目录指定选项。

来源：http : //www.chriscalender.com/ignoring-the-lostfound-directory-in-your-datadir/