Cause of error: Invalid (old?) table or database name 'lost+found'

My MySQL log shows duplicated errors:

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

I have a database named #mysql50#lost+found but I cannot seem to delete it.

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>

I am operating Server version: 5.5.40 Distributed by The IUS Community Project on Centos 6.

Per MySQL is running VERY slow on CentOS 6x (not 5x), my datadir is on ext3 with the barrier=0 option.

What is causing this error, and how can it be eliminated?

It looks to me like your datadir is in a file system of its own.

Ext file systems, like most FSes under Unix, have at their root a directory called lost+found. It exists in order to allow files that become detached (that is, they have content, but no associated directory entry) to be reattached somewhere when an inconsistent file system is fscked (see, eg, https://unix.stackexchange.com/questions/18154/what-is-the-purpose-of-the-lostfound-folder-in-linux-and-unix for more details). This purpose is important in disaster-recovery, so you shouldn't delete the directory.

Your problem arises when the mount point, on which the file system that contains that directory is mounted, is given over entirely to an application that expects everything in that mount point to belong to it. MySQL being one such, it attempts to interpret the lost+found directory as being something db-related, and (not unreasonably) fails.

Your best bet is never to dedicate an entire FS to an application, but instead to mount the FS on some application-non-specific mount point, eg /data1, create a subdirectory under that, eg /data1/mysql, and reconfigure the application to use that directory as its datadir.

MadHatter explained well the error. But since then the times have changed and now MySQL (since 5.6.3) has an option to ignore this directory. Just add this statement into your /etc/mysql/my.cnf file:

ignore-db-dir=lost+found

After MySQL restart you can check it with command:

show global variables like 'ignore_db_dirs';

If you want to ignore multiple directories, you need specify the option for each of them separately.

Source: http://www.chriscalender.com/ignoring-the-lostfound-directory-in-your-datadir/

Location of my.cnf under CentOS 7.2 if You are using MariaDB is in

/etc/my.cnf

You can restart the service with

systemctl restart mariadb.service

ignore-db-dir should be put under [mysqld] section and not under [mysqld_safe] one.

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock

ignore-db-dir=lost+found

# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
# Settings user and group are ignored when systemd is used.
# If you need to run mysqld under a different user or group,
# customize your systemd unit file for mariadb according to the
# instructions in http://fedoraproject.org/wiki/Systemd

[mysqld_safe]
log-error=/var/log/mariadb/mariadb.log
pid-file=/var/run/mariadb/mariadb.pid
#
# include all files from the config directory
#
!includedir /etc/my.cnf.d