Solved: MySQL 8.4 'InnoDB Log File Corrupted' Error on Startup
Quick Fix Summary
TL;DRStop MySQL, move the corrupted ib_logfile* files, then restart with innodb_force_recovery=1 to attempt recovery.
MySQL ERROR 3169 indicates the InnoDB redo log files (ib_logfile0, ib_logfile1) are corrupted, preventing the database engine from starting. This is a critical failure that halts all database operations.
Diagnosis & Causes
Recovery Steps
Step 1: Immediate Assessment and Safe Shutdown
First, confirm the error and ensure MySQL is completely stopped to prevent further damage.
# Check MySQL error log for the exact error
sudo tail -100 /var/log/mysql/error.log
# Force stop the MySQL service if it's stuck
sudo systemctl stop mysql
sudo pkill -9 mysqldStep 2: Backup Corrupted Log Files
Move the corrupted log files to a backup location. This allows MySQL to create new, clean log files on restart.
# Navigate to your MySQL data directory (common locations)
cd /var/lib/mysql
# Backup and remove the existing InnoDB log files
sudo mv ib_logfile* /tmp/mysql_log_backup_$(date +%s)/Step 3: Attempt Recovery with innodb_force_recovery
Configure MySQL to attempt a forced recovery by ignoring certain corruption levels. Start with the lowest level.
# Edit the MySQL configuration file
sudo nano /etc/mysql/my.cnf
# Add the following line under the [mysqld] section
[mysqld]
innodb_force_recovery = 1Step 4: Restart MySQL and Dump Data
Start MySQL in recovery mode. If it starts, immediately dump all databases to SQL files as the instance is unstable.
# Start MySQL with the new config
sudo systemctl start mysql
# Check if it's running
sudo systemctl status mysql
# Dump ALL databases to a safe location
sudo mysqldump --all-databases --single-transaction --quick > /backup/full_recovery_dump.sqlStep 5: Clean Reinstallation and Data Restore
After a successful dump, perform a clean installation of MySQL and restore your data from the dump.
# 1. Stop MySQL and clean the data directory
sudo systemctl stop mysql
sudo rm -rf /var/lib/mysql/*
# 2. Remove the innodb_force_recovery line from my.cnf and restart
sudo systemctl start mysql
# 3. Restore the data from the dump file
sudo mysql < /backup/full_recovery_dump.sqlStep 6: If Force Recovery Fails (Levels 2-6)
If level 1 fails, incrementally increase `innodb_force_recovery` up to 6, dumping data at each successful startup. Level 6 is last resort.
# In /etc/mysql/my.cnf, try the next level
[mysqld]
innodb_force_recovery = 2
# Repeat Step 4: Start, dump, stop. Continue until success or level 6.Architect's Pro Tip
"Before using `innodb_force_recovery`, snapshot your entire VM or disk. If recovery corrupts data further, you can instantly revert to the pre-recovery state."
Frequently Asked Questions
Will I lose data using this recovery method?
The goal is to recover data, not lose it. By using `innodb_force_recovery` to start MySQL and immediately creating a logical dump, you salvage as much data as possible before rebuilding the database cleanly.
What if MySQL won't start even with innodb_force_recovery = 6?
If level 6 fails, the system tablespace (ibdata1) is likely also corrupted. Your options are restoring from a physical backup (e.g., Percona XtraBackup snapshot) or a logical backup taken before the crash.
How can I prevent this error in the future?
Ensure reliable power (UPS), use a battery-backed write cache (BBWC) on RAID controllers, perform regular backups, and monitor disk health with SMART tools. Also, always shut down MySQL cleanly.