When working with MySQL on Linux systems, you might encounter this peculiar error in your logs:
141223 5:47:21 [ERROR] Invalid (old?) table or database name 'lost+found'
This typically appears when MySQL encounters a directory named 'lost+found' in its data directory. On ext3/ext4 filesystems, this is a special system directory created by fsck for recovered files.
The database appears in your listings with a special prefix:
| #mysql50#lost+found |
The #mysql50#
prefix is MySQL's way of handling database names that contain special characters that would otherwise be invalid. However, this isn't a real database - it's MySQL interpreting a filesystem artifact.
When you try to drop it normally:
mysql> DROP DATABASE #mysql50#lost+found;
ERROR 1008 (HY000): Can't drop database '#mysql50#lost+found'; database doesn't exist
MySQL rejects the operation because it doesn't recognize this as a valid database in its internal catalog, despite showing it in listings.
Here's how to properly remove it:
First, stop your MySQL service:
sudo service mysql stop
Navigate to your MySQL data directory (typically /var/lib/mysql) and remove the directory:
cd /var/lib/mysql
sudo rm -rf \#mysql50\#lost+found
Note the backslashes to escape special characters. Alternatively:
sudo rm -rf '#mysql50#lost+found'
Then restart MySQL:
sudo service mysql start
To stop these messages from appearing in your logs:
- Create a my.cnf configuration override:
[mysqld] ignore_db_dirs=lost+found
- Ensure proper filesystem permissions on your MySQL data directory
- Consider moving to a filesystem that doesn't create lost+found directories (like XFS)
For some versions, you can try this workaround:
mysql> USE #mysql50#lost+found;
mysql> DROP DATABASE #mysql50#lost+found;
If that fails, the manual filesystem removal is your only option.
Since you mentioned using ext3 with barrier=0, consider these additional steps:
# Check filesystem health
sudo fsck -f /dev/your_mysql_partition
# Consider filesystem optimizations
sudo tune2fs -o ^acl,^user_xattr /dev/your_mysql_partition
When working with MySQL on Linux systems using ext3/ext4 filesystems, you might encounter a peculiar database named #mysql50#lost+found
that appears in your database list but can't be removed through normal SQL commands. This special directory is actually created by the Linux filesystem recovery tools, not by MySQL itself.
mysql> SHOW DATABASES;
+---------------------+
| Database |
+---------------------+
| #mysql50#lost+found |
| information_schema |
| mysql |
+---------------------+
The #mysql50#
prefix is MySQL's way of handling special characters in database names. The lost+found
directory is created by fsck (file system check) when recovering filesystems, and MySQL interprets it as a database. However, because it's not a true MySQL database, standard DROP commands fail:
mysql> DROP DATABASE #mysql50#lost+found;
ERROR 1008 (HY000): Can't drop database '#mysql50#lost+found'; database doesn't exist
The most effective solution is to remove the directory manually from the MySQL data directory:
# First, ensure MySQL is stopped
sudo systemctl stop mysql
# Navigate to your datadir (default is /var/lib/mysql)
cd /var/lib/mysql
# Remove the directory (use -f to force removal if needed)
sudo rm -rf '#mysql50#lost+found'
# Restart MySQL
sudo systemctl start mysql
To prevent this issue from recurring:
- Ensure proper shutdown procedures for your MySQL server
- Consider using XFS instead of ext3/ext4 if possible
- Regularly check your database directory for anomalies
For a safer approach that doesn't require MySQL downtime, you can try:
mysqlcheck --repair --databases '#mysql50#lost+found'
This might allow MySQL to properly recognize and handle the directory as a recoverable database.