Why binlog_expire_logs_seconds May Not Work in MySQL 8.0 and How to Reproduce the Issue

If you are using MySQL 8.0 together with a physical hot‑backup tool, the system variable binlog_expire_logs_seconds may not work as you expect.

MySQL provides a variable to automatically delete expired binary logs. In MySQL 5.7 the variable is expire_logs_days (day precision). In MySQL 8.0 it was replaced by binlog_expire_logs_seconds , which uses second precision. When a binlog is older than the configured time, MySQL will purge it, but the purge is only triggered at MySQL startup or when the binlog is flushed.

Binlog flushing occurs in two situations: (1) the current binlog reaches max_binlog_size and the current transaction finishes, causing a new binlog to be created; (2) the user manually runs FLUSH [BINARY] LOGS , which also creates a new binlog.

Reproduction steps :

Set the global variable: set global binlog_expire_logs_seconds=60 and execute flush binary logs several times to generate multiple binlogs.

Wait 60 seconds, then run xtrabackup to perform a backup (the tool internally executes FLUSH NO_WRITE_TO_BINLOG BINARY LOGS ).

Observe that a new binlog is created after the backup, but the binlogs older than 60 seconds are not deleted.

The reason is that MySQL 8.0 introduces LOCK INSTANCE FOR BACKUP during backup to avoid global lock problems. This lock blocks the binlog expiration logic, so the old binlogs remain.

After releasing the backup lock, the expiration works normally. A practical workaround is to set max_binlog_size smaller so that a binlog reaches its size limit before the backup, allowing the automatic purge to trigger.

The issue does not occur in MySQL 5.7, where the backup lock does not interfere with binlog expiration. It has been reported as MySQL bug #104785 and is being fixed.