MyRapidi
MyRapidi
Menu

Search our Wiki

[ERROR] InnoDB: Ignoring the redo log due to missing MLOG_CHECKPOINT

The error [ERROR] InnoDB: Ignoring the redo log due to missing MLOG_CHECKPOINT typically occurs in MySQL or MariaDB databases using the InnoDB storage engine. This error indicates an issue with the InnoDB redo log, which is essential for ensuring data consistency and recovery in the event of a crash. Here are the situations where this error might arise:

  1. Incomplete or Corrupted Redo Log: If the InnoDB redo log files (ib_logfile0, ib_logfile1, etc.) are incomplete or corrupted, the database may fail to locate the necessary MLOG_CHECKPOINT record. This record is critical for determining the state of the redo log.
  2. Unexpected Shutdown or Crash: If the database server experiences an unexpected shutdown or crash, the redo log might not be written or flushed properly. Upon restart, InnoDB may find that the expected checkpoint record is missing.
  3. Improper File Restoration: If redo log files are manually restored or copied from a backup without ensuring their consistency with the rest of the database files, the checkpoint records might not match, leading to this error.
  4. Configuration Issues: Certain misconfigurations in the InnoDB settings, such as incorrect file paths or sizes for the redo log files, can cause the InnoDB engine to misinterpret or fail to read the redo logs correctly.
  5. Filesystem Issues: Underlying filesystem problems, such as disk errors or file system corruption, can result in missing or unreadable redo log files, leading to the absence of the checkpoint record.

Steps to address the issue:

  • Check Disk Space and Permissions: Ensure that there is sufficient disk space and that the database has the necessary permissions to read/write the redo log files.
  • Review Log Files: Check the MySQL/MariaDB error logs for more detailed information about the problem. This can provide clues about what might have gone wrong.
  • Backup and Restore: If the redo log files are corrupted beyond repair, restoring the database from a recent backup might be necessary. Ensure that the backup is consistent and includes all necessary log files.
  • Restart Database: Sometimes, simply restarting the database server can resolve transient issues related to file locks or temporary corruption.
  • Increase Redo Log Size: If the redo log is frequently becoming full, increasing its size might help prevent such issues. This can be done by modifying the innodb_log_file_size parameter in the MySQL/MariaDB configuration file.

To increase the redo log size, you can add or modify the following lines in your MySQL/MariaDB configuration file (my.cnf or my.ini):






After making this change, you will need to:

  1. Shut down the MySQL/MariaDB server.
  2. Move the existing redo log files to a different location or delete them (after ensuring you have backups).
  3. Restart the server to create new redo log files with the specified size. 
  • File System Check: Run a filesystem check to ensure there are no underlying issues with the disk where the redo log files are stored.
  • Consult Documentation: Refer to the MySQL or MariaDB documentation for specific instructions and best practices related to InnoDB redo logs and crash recovery.

If the InnoDB redo log is corrupt, it can prevent the MySQL or MariaDB server from starting properly or cause data consistency issues. Here are the steps to handle a corrupted redo log:

Step-by-Step Guide


1. Stop the Database Server

First, stop the MySQL/MariaDB server to ensure no further writes are attempted on the corrupted redo logs.

sudo systemctl stop mysql # For MySQL


2. Backup Data Directory

Before making any changes, backup your data directory to ensure you have a copy of your data in its current state.

cp -r /var/lib/mysql /var/lib/mysql_backup # Adjust path if your data directory is different


3. Move or Delete Corrupted Redo Log Files

Locate the redo log files (ib_logfile0, ib_logfile1, etc.) and move or delete them. These files are typically located in the MySQL data directory.

cd /var/lib/mysql # Adjust path if your data directory is different 
mv ib_logfile0 ib_logfile0.bak 
mv ib_logfile1 ib_logfile1.bak 
# Repeat for any additional redo log files (ib_logfile2, etc.)

4. Check and Update Configuration (Optional)

Optionally, you might want to increase the size of the redo log files to prevent future issues. This involves editing the MySQL configuration file (my.cnf or my.ini).

5. Start the Database Server

Restart the MySQL server. This will create new redo log files with the appropriate size.

sudo systemctl start mysql # For MySQL

6. Check Logs and Verify

Check the MySQL/MariaDB error logs to ensure the server started correctly and that new redo log files were created.

tail -n 100 /var/log/mysql/error.log # Adjust path if your log file is different

Recovery Scenarios

Scenario 1: Database Starts Successfully

If the database starts successfully, monitor it closely for any further issues. It’s also a good practice to perform a full backup as soon as possible.

Scenario 2: Database Fails to Start

If the database fails to start, additional recovery steps may be necessary. Here are some additional steps:

  • Force InnoDB Recovery: Add the following line to your MySQL configuration file to force InnoDB to recover from a corrupted state.
[mysqld] innodb_force_recovery=1 # You can increase this value incrementally up to 6

Restart the MySQL server again. If it starts, dump all databases immediately using mysqldump.

mysqldump --all-databases > all_databases_backup.sql

After dumping the databases, remove the innodb_force_recovery line from the configuration file and restart the server again to disable recovery mode.

  • Restoring from Backup: If forcing recovery doesn't work, you may need to restore from a recent backup. Ensure the backup is consistent and includes all necessary data.
mysql -u root -p < all_databases_backup.sql

Handling a corrupted redo log involves stopping the server, backing up your data, moving or deleting the corrupted log files, optionally increasing the log file size, and restarting the server. If issues persist, forcing InnoDB recovery or restoring from backup are additional steps to consider. Always ensure you have reliable backups to minimize data loss in such scenarios.