How to Recover a Deleted MySQL ib_logfile1 Without Restarting the Server

Background

A test environment accidentally deleted the InnoDB redo log file ib_logfile1 on a MySQL 5.6.27 server. The author recounts the situation and stresses the importance of staying calm and not restarting the database.

Environment

Linux host running MySQL 5.6.27.

Root Cause

Human error – a mistaken command removed the log file.

Recovery Strategy

The key is to keep the MySQL process alive, locate the deleted file through the Linux file‑descriptor interface, ensure all buffered log data is flushed to disk, and then copy the file back.

Step‑by‑Step Procedure

Identify the MySQL server PID: ps -ef | grep mysql Navigate to the process’s file‑descriptor directory, e.g. /proc/<PID>/fd, and list its entries. The deleted ib_logfile1 will appear with the (deleted) flag but still points to an open file.

Flush InnoDB buffers and lock tables to guarantee that all log data is written to disk:

FLUSH TABLES WITH READ LOCK;

FLUSH LOGS;

Verify that new binary logs are generated and that the old binary logs contain the statements executed after the accidental deletion.

Copy the still‑open deleted file back to its original location (usually /var/lib/mysql/ib_logfile1) using a command such as:

cp /proc/<PID>/fd/<fd_number> /var/lib/mysql/ib_logfile1

Ensure the file ownership and permissions match the MySQL data directory.

Release the read lock and resume normal operation: UNLOCK TABLES; After these steps the server continues to run and the missing log file is restored without a restart.

Incorrect Scenarios

If the database is stopped before copying the file, MySQL will fail to start, showing errors similar to those in the screenshots. Likewise, copying a file before flushing the log buffer (or copying a corrupted file) leads to start‑up errors because the LSN (Log Sequence Number) in the data files no longer matches the log file.

Observations

When the correct log file is copied back, MySQL still reports an error because the LSN stored in the data files has already advanced (e.g., from 3117292814 to 3117292824). The server truncates the problematic log file and generates a new one with the updated LSN.

Conclusion & Best Practices

Never shut down MySQL when recovering a deleted log or data file. Always flush buffers first, keep the server running, and verify that no new transactions are in progress before copying the file back.