linux – 错误原因:无效(旧?)表或数据库名称’找不到’

我的 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 is running VERY slow on CentOS 6x (not 5x),我的datadir在ext3上,屏障= 0选项.

导致此错误的原因是什么,如何消除?

解决方法

在我看来,你的datadir就属于自己的文件系统.

与Unix下的大多数FS一样,Ext文件系统在其根目录下有一个名为lost found的目录.它的存在是为了允许在不一致的文件系统被fscked时重新附加分离的文件(即,它们具有内容,但没有相关的目录条目)(例如,参见https://unix.stackexchange.com/questions/18154/what-is-the-purpose-of-the-lostfound-folder-in-linux-and-unix以获得更多细节).此目的在灾难恢复中很重要,因此您不应删除该目录.

当挂载包含该目录的文件系统的挂载点完全交给应用程序时,就会出现问题,该应用程序希望该挂载点中的所有内容都属于它. MySQL就是其中之一,它试图将丢失的找到的目录解释为与db相关的东西,并且(并非不合理地)失败.

最好的办法是永远不要将整个FS专用于应用程序,而是将FS安装在某些非特定应用程序安装点上,例如/ data1,在其下创建一个子目录,例如/ data1 / mysql,并重新配置应用程序使用该目录作为其datadir.

相关文章

linux常用进程通信方式包括管道(pipe)、有名管道(FIFO)、...
Linux性能观测工具按类别可分为系统级别和进程级别,系统级别...
本文详细介绍了curl命令基础和高级用法,包括跳过https的证书...
本文包含作者工作中常用到的一些命令,用于诊断网络、磁盘占满...
linux的平均负载表示运行态和就绪态及不可中断状态(正在io)的...
CPU上下文频繁切换会导致系统性能下降,切换分为进程切换、线...