MySQL Crash After Hardware Replacement: Missing MLOG_CHECKPOINT Redo Log and Recovery Procedure
After replacing a MySQL server's CPU and motherboard, the instance fails to start due to a missing MLOG_CHECKPOINT marker in the redo log, and the article explains the underlying cause, recovery options using innodb_force_recovery levels, and step‑by‑step data restoration.
Fault Description: After replacing the CPU and motherboard of a MySQL server, the instance fails to start.
Analysis: From MySQL 5.7 onward, InnoDB writes a one‑byte MLOG_CHECKPOINT marker after each checkpoint; if this marker is missing, the redo log is ignored, causing startup failure and possible data loss.
Handling: Removing the current redo log files and attempting to start the server fails. The error “Page ... log sequence number ... is in the future” indicates an LSN mismatch. Setting innodb_force_recovery=3 does not start; raising it to innodb_force_recovery=4 succeeds. Subsequent mysqldump attempts still crash, showing “Failed to find tablespace for table…”. Raising the parameter to innodb_force_recovery=5 still fails, but innodb_force_recovery=6 allows the server to start and data to be dumped.
Recovery Steps: After dumping, re‑initialize the database and import the backup to complete restoration.
Parameter Explanation: The innodb_force_recovery levels correspond to internal flags: SRV_FORCE_IGNORE_CORRUPT, SRV_FORCE_NO_BACKGROUND, SRV_FORCE_NO_TRX_UNDO, SRV_FORCE_NO_IBUF_MERGE, SRV_FORCE_NO_UNDO_LOG_SCAN, SRV_FORCE_NO_LOG_REDO.
Aikesheng Open Source Community
The Aikesheng Open Source Community provides stable, enterprise‑grade MySQL open‑source tools and services, releases a premium open‑source component each year (1024), and continuously operates and maintains them.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.