我的
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.
