InnoDB Error: Attempted to Open a Previously Opened Tablespace

The "Attempted to open a previously opened tablespace" error in MySQL/MariaDB occurs when InnoDB detects conflicting tablespace IDs, usually after a partial restore, a crash during an ALTER TABLE operation, or when .ibd files were manually copied between databases. This guide covers diagnosis and resolution for cPanel/CloudLinux environments.

01. What This Error Means

InnoDB tracks every table's tablespace using an internal ID stored in both the ibdata1 system tablespace and each table's individual .ibd file (when using innodb_file_per_table, which is the default). This error means InnoDB found two different .ibd files claiming the same tablespace ID, or a tablespace ID in ibdata1 that doesn't match the .ibd file on disk.

The full error typically looks like:

InnoDB: Error: attempted to open a previously opened tablespace.
Previous tablespace db1/table1 uses space ID: 45 at filepath: ./db1/table1.ibd.
Cannot open tablespace db2/table2 which uses space ID: 45 at filepath: ./db2/table2.ibd

02. Diagnosing the Problem

Check the MySQL error log for the full context:

# Find recent tablespace errors
grep -i "tablespace" /var/lib/mysql/*.err | tail -50

# Check which tables are affected
grep "previously opened" /var/lib/mysql/*.err

Identify the conflicting tables and their databases. Common scenarios:

Partial cPanel restore - A cPanel account restore imported .ibd files from the backup that conflict with existing tablespace IDs in ibdata1.

Manual file copy - Someone copied .ibd files between accounts or servers without properly exporting/importing the tablespace.

Crash during ALTER TABLE - A temporary tablespace file was left behind after a crash during a table rebuild.

03. Fixing Orphaned Tablespace Files

If the error references a table that no longer exists in the MySQL data dictionary but its .ibd file is still on disk:

# Check if the table exists in MySQL
mysql -e "SELECT * FROM information_schema.TABLES WHERE TABLE_SCHEMA='dbname' AND TABLE_NAME='tablename';"

# If it returns no rows but the .ibd file exists, remove the orphan
ls -la /var/lib/mysql/dbname/tablename.ibd

# Remove the orphaned file (after backing up)
mv /var/lib/mysql/dbname/tablename.ibd /var/lib/mysql/dbname/tablename.ibd.orphan

# Restart MySQL
systemctl restart mysql

04. Rebuilding the Affected Table

If the table exists and has data you need to preserve:

# Dump the table data first
mysqldump dbname tablename > /tmp/tablename_backup.sql

# Discard and re-import the tablespace
mysql dbname -e "ALTER TABLE tablename DISCARD TABLESPACE;"

# Remove the .ibd file if it still exists
rm -f /var/lib/mysql/dbname/tablename.ibd

# Recreate the tablespace
mysql dbname -e "ALTER TABLE tablename IMPORT TABLESPACE;"

If DISCARD TABLESPACE fails, you may need to drop and recreate the table:

# Get the CREATE TABLE statement
mysql dbname -e "SHOW CREATE TABLE tablename\G" > /tmp/tablename_create.sql

# Drop the table
mysql dbname -e "DROP TABLE tablename;"

# Remove lingering .ibd file
rm -f /var/lib/mysql/dbname/tablename.ibd

# Recreate and reimport
mysql dbname < /tmp/tablename_create.sql
mysql dbname < /tmp/tablename_backup.sql

05. InnoDB Force Recovery

If MySQL won't start at all due to the tablespace error, use InnoDB force recovery to get it running enough to dump data:

# Edit my.cnf
vi /etc/my.cnf

# Add under [mysqld]
innodb_force_recovery = 1

# Restart MySQL
systemctl restart mysql

Force recovery levels:

1 (SRV_FORCE_IGNORE_CORRUPT) - Skip corrupt pages. Try this first.

2 (SRV_FORCE_NO_BACKGROUND) - Don't run background operations.

3 (SRV_FORCE_NO_TRX_UNDO) - Don't roll back transactions.

4 (SRV_FORCE_NO_IBUF_MERGE) - Don't merge insert buffer.

5 (SRV_FORCE_NO_UNDO_LOG_SCAN) - Don't look at undo logs.

6 (SRV_FORCE_NO_LOG_REDO) - Don't do redo log roll-forward.

# Once MySQL starts in recovery mode, dump everything
mysqldump --all-databases --single-transaction > /tmp/all_databases.sql

# Remove force_recovery from my.cnf
# Stop MySQL, remove ibdata1/ib_logfile*, restart, reimport
systemctl stop mysql
mv /var/lib/mysql/ibdata1 /var/lib/mysql/ibdata1.old
mv /var/lib/mysql/ib_logfile0 /var/lib/mysql/ib_logfile0.old
mv /var/lib/mysql/ib_logfile1 /var/lib/mysql/ib_logfile1.old
systemctl start mysql
mysql < /tmp/all_databases.sql

06. Prevention

Use mysqldump for transfers - Never copy .ibd files directly between servers. Always use mysqldump or EXPORT/IMPORT TABLESPACE for moving tables.

Verify cPanel restores - After restoring a cPanel backup, check the MySQL error log for tablespace conflicts before considering the restore complete.

Monitor for crashes - Set up monitoring for unexpected MySQL restarts. Crash recovery is when most orphaned tablespace files get created.

Regular backups - Keep multiple days of mysqldump backups so you have clean SQL dumps to restore from if InnoDB corruption occurs.

Quick Recap: Fixing InnoDB Tablespace Errors

1. Backup first - Copy the entire MySQL data directory before doing anything
2. Check the error log - Identify which tables and databases are affected
3. Remove orphans - Move orphaned .ibd files that don't have matching data dictionary entries
4. Rebuild if needed - Dump, drop, recreate, and reimport affected tables
5. Force recovery as last resort - Start at level 1, dump everything, then clean rebuild

Last updated March 2026 · Browse all Server Maintenance articles