MySQL InnoDB Won't Start After Power Loss — Fix Guide

You had a power outage. Now MySQL won't start. The error log shows something like InnoDB: Corruption in the InnoDB tablespace. Tablespace is corrupted. or InnoDB: Database page corruption on disk. This is a classic failure after a hard shutdown. The culprit is almost always a partial write to the InnoDB redo log files (ib_logfile0 and ib_logfile1) or the system tablespace (ibdata1).

Don't panic. This fix works for 95% of cases. You won't lose all your data. But you will lose the last few transactions. That's the price of dirty shutdown.

Why This Happens

InnoDB uses a write-ahead log. It writes changes to the redo logs before it writes to the actual data files. On a clean shutdown, it flushes everything to disk. On a power loss, it doesn't. So when MySQL starts again, it tries to replay the redo logs. If those logs are half-written or corrupted because of the sudden stop, InnoDB can't figure out what's consistent. It gives up and says "corruption."

This is different from a full disk or hardware failure. Those are worse. This is just a recovery failure. The data is probably still there. You just need to bypass the recovery.

The Fix: Step by Step

1. Stop MySQL if it's running. If it's stuck trying to start, kill it. systemctl stop mysql or service mysql stop. Wait until it's truly dead.
2. Back up your data directory. This is your safety net. Copy the whole /var/lib/mysql/ folder (or wherever MySQL stores data). cp -r /var/lib/mysql /var/lib/mysql.bak. Don't skip this.
3. Add innodb_force_recovery = 1 to your MySQL config file (usually /etc/my.cnf or /etc/mysql/my.cnf). Put it under the [mysqld] section.
4. Try starting MySQL. systemctl start mysql. If it starts, great. You got lucky. Dump all your databases right now: mysqldump --all-databases > fulldump.sql.
5. If it still fails, increase the force recovery level. Change innodb_force_recovery to 2, then 3, then 4, and so on. Each level skips more recovery steps. Level 1 skips corrupted pages. Level 2 skips the purge. Level 3 skips the merge. Level 4 only reads the data files, no undo logs. Level 5 skips the redo logs entirely. Level 6 is the nuclear option — it skips the undo logs and just reads the data as-is.
6. Once MySQL starts at any level, dump everything. mysqldump --all-databases > fulldump.sql. This is your data. The dump will be clean because it reads the tables through InnoDB's recovery logic.
7. Stop MySQL, remove the force recovery setting, and do a clean start. Delete or comment out innodb_force_recovery from the config. Stop MySQL. Remove the old data directory (after the backup!) and create a fresh one: rm -rf /var/lib/mysql && mysql_install_db (or mysqld --initialize on MySQL 8.0). Start MySQL. Then restore the dump: mysql < fulldump.sql.

What to Expect After Recovery

You'll lose the last few transactions. Maybe a dozen rows. But the bulk of your data is safe. Don't run a production database on the force recovery level. It's read-only in some modes, and it can cause more corruption if you write to it. Use it only to get the data out.

If It Still Fails

Three things to check:

• Check the error log carefully. Sometimes it says which table is corrupted. If it's a specific table, you can try to repair it with mysqlcheck --repair on that table. But this rarely works for InnoDB. Dump everything else first.
• Try innodb_force_recovery = 6. This is the last resort. It reads the data files without any recovery. Your dump might have missing rows or garbage data in some tables. But it's better than nothing.
• Check for hardware issues. Run smartctl -H /dev/sda (or whatever your disk is). Check dmesg for disk errors. Check fsck on the filesystem. If the disk is dying, you need to clone it first with ddrescue before you do anything else.

If none of this works, you're in a bad spot. You'll need to restore from backup. That's why you have backups, right? Right?

One last tip: After you recover, enable innodb_flush_log_at_trx_commit = 1 in your config. This makes InnoDB flush the redo log on every transaction commit. It's slower, but it reduces the chance of this exact failure. For most apps, the performance hit is small. For high-traffic sites, you might want to use a UPS instead. Or both.