MySQL 8.0.28+ 才真正支持 binlog_expire_logs_seconds，旧版本无效；该变量动态生效但不持久化，需写入配置文件或用 SET PERSIST；优先级高于 expire_logs_days；GTID 模式下设太短会导致从库无法恢复。
binlog_expire_logs_seconds 设置后为什么没生效
MySQL 8.0.28+ 才真正支持 binlog_expire_logs_seconds，旧版本（包括 5.7 和 8.0.27 及之前）设了也无效，仍只认 expire_logs_days。检查版本用 SELECT VERSION()，别只看文档想当然。
即使版本够新，该变量是动态的但**不持久化**：重启后恢复默认值（默认 2592000 秒，即 30 天）。必须写进配置文件才可靠：
[mysqld] binlog_expire_logs_seconds = 604800 # 保留 7 天
- 运行时临时设置用
SET PERSIST binlog_expire_logs_seconds = 604800（仅限支持PERSIST的版本） - 若从库延迟超过保留时长，
SHOW SLAVE STATUS中Seconds_Behind_Master会跳变或报错Could not find first log file name in binary log index file -
binlog_expire_logs_seconds优先级高于expire_logs_days，两者都设时后者被忽略
主从同步卡住时，手动 PURGE BINLOGS 的风险
从库还没读完的 binlog 被主库删掉，会导致从库 I/O 线程中断，错误信息是 Got fatal error 1236 from master when reading data from binary log，具体提示类似 The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires。
安全 purge 前必须确认从库已消费完毕：
- 在主库查最老未被任何从库读取的 binlog：
SHOW BINARY LOGS+SELECT * FROM performance_schema.replication_applier_status_by_coordinator（不直观），更实用的是SELECT @@global.gtid_executed主库和各从库比对 - 用
SHOW SLAVE STATUS\G看从库的Relay_Master_Log_File，确保它在SHOW BINARY LOGS列表里且不是最早那个 - 宁可多留 1–2 天，也不要靠
PURGE BINLOGS TO 'mysql-bin.000123'硬删——除非你刚确认过所有从库Exec_Master_Log_Pos都大于该文件末尾偏移
磁盘空间告警时，快速定位 binlog 占用真实大小
SHOW BINARY LOGS 显示的 File_size 是逻辑大小，实际磁盘占用可能更大（尤其启用了压缩或加密），而且 MySQL 不统计日志索引文件 mysql-bin.index 和可能残留的临时 binlog 文件（如 mysql-bin.000123-orig）。
直接看磁盘更准：
- Linux 下进
datadir（查SELECT @@datadir），执行du -sh mysql-bin.*和ls -lh mysql-bin.* | head -20 - 注意隐藏文件：
ls -la | grep "mysql-bin\."，有时 purge 失败会留下.000123~或带@002d编码的残骸 - 如果启用了
binlog_transaction_compression = ON，压缩率高但解压开销大，File_size显示值会明显小于磁盘占用（因为显示的是解压后预估）
GTID 模式下，expire 配置和故障恢复的隐含依赖
GTID 模式（gtid_mode = ON）要求主库 binlog 必须包含从库缺失的所有事务。哪怕只差一个 GTID，从库就无法自动追上——binlog_expire_logs_seconds 设太短，等于主动切断恢复路径。
线上建议：
- 保留时间 ≥ 最慢从库的典型延迟峰值 + 24 小时缓冲（例如监控显示最大延迟 17 小时，那就至少设 48 小时）
- 不要依赖
RESET SLAVE后重新CHANGE MASTER来绕过缺失 binlog：GTID 自动定位失败时，只能靠备份恢复或人工注入空事务补 GTID，操作门槛高 - 定期用
SELECT * FROM performance_schema.replication_group_members（MGR）或SELECT * FROM mysql.slave_master_info（传统复制）核对各节点 GTID 集合差异
binlog 保留策略不是孤立参数，它和你的监控粒度、从库稳定性、DBA 响应速度强绑定。设太短，出问题时连“回退到上个 binlog”这种基本操作都做不到。
