MySQL 的 binlog 日志为何会被“清空”？
MySQL 本身不会主动“清空”二进制日志（
binlog），但常见误操作或配置不当会导致日志文件被轮转、删除或截断，表现为“突然没了”。典型原因包括：
PURGE BINARY LOGS手动执行、
expire_logs_days自动过期清理、磁盘空间不足触发
max_binlog_size强制轮转后旧文件被删、或误用
RESET MASTER（彻底清空所有 binlog 并重置序列）。
如何防止 binlog 被意外删除？
核心是控制生命周期和访问权限，而非完全禁止删除：
禁用自动过期：将expire_logs_days设为
0（默认值），并从配置文件中显式注释或移除该参数，避免被继承； 禁用危险命令权限：确保普通应用账号没有
REPLICATION CLIENT或
SUPER权限，防止执行
PURGE BINARY LOGS或
RESET MASTER； 设置只读 binlog 目录：在操作系统层面限制 MySQL 用户对
log_bin_basename所在目录的写权限（如
chown root:mysql /var/lib/mysql/logs/ && chmod 750 /var/lib/mysql/logs/），仅保留 MySQL 进程自身追加日志的能力； 定期归档而非删除：用脚本配合
mysqlbinlog将旧 binlog 导出为 SQL 文件或压缩存档，再安全删除原始文件——注意归档后仍需保留至少一份完整链路（即从最早的 active binlog 到当前）。
如何验证 binlog 是否还在被正常写入？
不能只看文件存在，要确认 MySQL 正在持续追加：
执行SHOW BINARY LOGS;查看当前活跃日志列表及文件大小变化； 对比
SHOW MASTER STATUS;中的
File和
Position，隔几分钟再查一次，确认
Position在增长； 用
tail -f /var/lib/mysql/mysql-bin.000001（路径以
log_bin_basename为准）观察实时写入，注意：MySQL 是顺序写入且带缓存，尾部短暂无变化不等于停写； 检查错误日志中是否有
Could not open log file或
Failed to write to binary log类报错。
使用 GTID 时 binlog 保护更关键
开启
gtid_mode=ON后，MySQL 依赖完整的 binlog 链来保证事务一致性。一旦中间缺失某个 binlog 文件，从库可能无法正确计算
Executed_Gtid_Set，导致复制中断且无法安全跳过。此时： 必须确保
enforce_gtid_consistency=ON，否则 GTID 模式下部分语句会被拒绝，反而降低风险暴露； 不要依赖
PURGE BINARY LOGS TO 'mysql-bin.000010'这类基于文件名的清理，GTID 模式下应改用
PURGE BINARY LOGS BEFORE '2024-01-01 00:00:00'或更稳妥地——由备份系统统一管理归档边界； 备份工具（如
mysqldump --set-gtid-purged=OFF）若未正确处理 GTID，可能隐式触发日志清理，务必验证备份脚本行为。 实际运维中最容易被忽略的是：
log_bin_basename配置路径与 MySQL 数据目录分离后，备份脚本可能只扫数据目录，漏掉独立存放的 binlog，结果“以为有归档”，其实早已丢失。
