Is there a way to delete an InnoDB table or database with pending transactions in MySQL (preferably on file system level)?

What happened:

I use MySQL 5.5.28 and ran LOAD DATA INFILE… to import a huge data set (300M rows) into an InnoDB table. I did not use set autocommit = 0; before. Unfortunately, mysqld was stopped right in the middle of the import.

When I restart mysql, it tries to roll back the transaction filling the system log with messages like this:

mysqld_safe[4433]: 121212 16:58:52 InnoDB: Waiting for 1 active transactions to finish

The problem is that the roll back is running for more that 25 hours now during which mysqld is not accepting any socket connections.

I cannot just delete /var/lib/mysql/* and start from scratch because there are some other InnoDB databases/tables on this machine as well. However, the problematic table is the only table in a separate database. Deleting the entire table or the entire database is not a problem since I can re-import all data afterwards.

2 Answers 2


There is nothing you can really do because a rollback is being done via the UNDO tablespace inside ibdata1, which should have grown immensely.

If you kill the mysqld process and restart mysql, it will just pickup where it left off as part of the crash recovery cycle.

DISCLAIMER : Not Responsible for Data Loss

What you could do may result in data loss for other tables, but there is something you can do to circumvent InnoDB's normal crash recovery cycle.

There is a startup option called innodb_force_recovery, which allows you to bypass various stages of InnoDB crash recovery.

According to MySQL Documentation on Forcing InnoDB Recovery, here are the settings and its effects:


Let the server run even if it detects a corrupt page. Try to make SELECT * FROM tbl_name jump over corrupt index records and pages, which helps in dumping tables.


Prevent the master thread from running. If a crash would occur during the purge operation, this recovery value prevents it.


Do not run transaction rollbacks after crash recovery.


Prevent insert buffer merge operations. If they would cause a crash, do not do them. Do not calculate table statistics.


Do not look at undo logs when starting the database: InnoDB treats even incomplete transactions as committed.


Do not do the redo log roll-forward in connection with recovery.

With transactional changes buried in the UNDO and REDO logs, you run the risk of

  • losing data meant to be written
  • keeping data meant to be deleted

In case you expect bad side effects, backup the entire /var/lib/mysql and put it somewhere in case you want to copy ibdata1, ib_logfile0, and ib_logfile1 and retry normal recovery.

If mysql is fully up in one of the modes

  • mysqldump all data except the offending table
  • shutdown mysql
  • remove everything in /var/lib/mysql except /var/lib/mysql/mysql
  • start mysql
  • reload the mysqldump

CAVEAT : Make sure you backup everything !!!

I hope this helps !!!


I had a similar situation this week.

And after four iterations of restoring a full backup to a test server and attempting to drop, delete, or kill the tables with the giant pending transactions, we eventually got to Friday afternoon and decided to just let it run. Over three days, the transaction finished with negligable server load and the database was fine. Which was much better than any of the manual operations on .frm files and mysql tables which had tried and failed.

My solution : Don't delete it. Allow the pending transactions to finish, even if you have to put off other operations for a few days, or find some disk space somewhere, or let your slave server take the load.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.