Description:
Environment
MySQL version: 5.7.x
Architecture: Dual-master replication setup between two servers (Server A: 11, Server B: 22)
Server 11: Read/Write (primary production node)
Server 22: Read-only (replica node)
Both servers have expire_logs_days configured as 3
Problem Description
We observed an unexpected binary log replay and data inconsistency event in a MySQL dual-master replication environment.
System History and Events
In July 2025, replication on server 22 (read-only node) became abnormal.
A full logical backup restore was performed using mysqldump to rebuild server 22.
During the restore process, sql_log_bin was NOT disabled (sql_log_bin=0 was not set), which caused binary logs to be generated on server 22 during the import operation.
After the restore, the mysql-bin.index file on server 22 contained inconsistent entries similar to:
mysql-bin.0027
mysql-bin.0001
mysql-bin.0002
mysql-bin.0026
However, in reality, only binary log files from mysql-bin.0001 to mysql-bin.0026 existed on disk.
It was later confirmed that some binary log files had been manually deleted using rm.
Despite the inconsistency between the index file and actual binary log files, the expired binary logs were not automatically purged or cleaned.
In October 2025, the MySQL instance on server 22 was restarted, but the stale binary logs were still not removed.
On June 12, 2026, a FLUSH LOGS operation was executed on server 22, which generated a new binary log file mysql-bin.0027.
Critical Incident
After the FLUSH LOGS operation:
The MySQL server re-read and reconstructed the binary log index file.
During this process, previously existing historical binlogs from July 2025 were reintroduced into the active binlog index context.
As a result, replication traffic was triggered unexpectedly.
Server 78 (master) applied binary log events that originally belonged to the historical restore period in July 2025.
Impact
Historical binary log events were unexpectedly replayed on the master server.
This caused data modifications and inconsistencies across approximately 121 tables.
The issue appears to be caused by binary log index corruption combined with FLUSH LOGS behavior.
How to repeat:
1.Deploy a MySQL 5.7.25 dual-master replication environment and set expire_logs_days=3.
2.Import backups via mysqldump on the replica node without disabling sql_log_bin.
3.Manually delete partial binlog files using the rm command instead of running PURGE BINARY LOGS.
4.Observe inconsistency between the mysql-bin.index file and physical binlog files on disk.
5.Restart the MySQL instance; expired logs will not be auto-cleaned up.
6.Execute FLUSH LOGS.
7.Observe historical binlog entries are reloaded, replication replays historical SQL statements unexpectedly and causes data inconsistency.
Suggested fix:
1.When MySQL reads the binlog index file and detects missing physical binlog files referenced in the index, throw an explicit error or warning to notify operators instead of silently ignoring the mismatch.
2.Rebuild the binlog index file automatically in a safe, ordered way when executing FLUSH LOGS, filtering out entries for non-existent log files to prevent stale historical binlog records from being reintroduced into the valid log list.
3.Make the expire_logs_days cleanup logic verify both the binlog index and actual disk files; skip invalid missing log entries and purge all eligible existing expired logs normally.
4.Block replication from reading invalid, non-existent binlog files recorded in a corrupted index to avoid accidental replay of outdated binlog events across master-replica links.
5.Add built-in logic to repair corrupted binlog.index automatically on server startup or log rotation, instead of relying on manual intervention from administrators.
