Description:
Environment
MySQL dual-master replication architecture between Server A and Server B; Server A is read-write, Server B is read-only. Both servers have expire_logs_days = 3.
Server B was rebuilt using logical backup data exported from Server A.
The mysql-bin.index file on Server B contained entries similar to:
mysql-bin.0027mysql-bin.0001mysql-bin.0002mysql-bin.0026
In reality, only binary log files from mysql-bin.0001 to mysql-bin.0026 existed on disk; certain conditions caused a mismatch between the index file and actual binlog files.
Server B exceeded the retention period defined by expire_logs_days, but binary logs were not automatically purged.
Server B was later restarted, but binary logs were still not cleaned up.
Recently, FLUSH LOGS was executed on Server B, generating a new binary log file mysql-bin.0027. After this operation, historical binary logs present on Server B were transmitted to Server A, and Server A re-used the received binary log.
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.
