直接答案：先停止继续放大磁盘的非核心任务，确认数据库是否仍可写，再记录SHOW BINARY LOGS、当前文件、所有副本执行位置、备份链和时间点恢复需求。只使用MySQL支持的PURGE或自动过期机制删除已经不被复制与恢复需要的日志；不要用rm直接删活动Binlog，也不要在未核对副本时按日期猜。
本文于 2026 年 9 月按官方文档核对。命令和配置只展示判断方法，不代表可在任意生产环境直接复制；发行版、云平台、网络拓扑和业务写入不同，执行前必须确认对象、权限、备份和带外恢复入口。
专属资产：可删/不可删Binlog判定表
| 现象/阶段 | 要判断什么 | 需要的证据 | 安全边界 |
|---|---|---|---|
| 当前活动文件 | 服务正在写入 | SHOW MASTER STATUS | 不可直接删除 |
| 副本尚未读取 | 复制仍依赖 | 各副本source log pos/GTID | 保留到全部越过 |
| 备份后产生 | 时间点恢复链 | 最近全备与恢复目标 | 按RPO保留 |
| 已归档且无依赖 | 候选清理 | 校验归档与恢复 | 用PURGE执行 |
| 未知文件 | 可能不属于实例或链路 | 配置、索引和文件头 | 先调查不清理 |
这张表要求每个结论至少有两个相互独立的证据，例如“服务监听+外部连接”“设备延迟+业务耗时”“备份文件+隔离恢复”。单一控制台绿灯、单次截图或一个User-Agent都可能误导，不能作为完成依据。
为什么常见的一键处理容易失败
运维问题通常跨越控制台、操作系统、应用和外部依赖。重启、全放行、清缓存或重装会改变多个变量，并可能清掉最有价值的现场。正确顺序是先定时间线和影响范围，再确认最靠近故障的证据层，最后做可回滚的最小动作。
对于有数据库、订单、表单、队列或用户上传的站点，还要先判断当前是否仍在写入。回滚旧快照、切回旧主机或恢复旧数据库前，必须处理变更期间的新数据；否则技术状态恢复了，业务数据却可能倒退。
六步安全执行流程
1. 确认对象与基线
记录df/inode、MySQL状态、只读/写入能力和业务错误；先限制批量写入、导入或异常重试，避免边排查边继续填满。
每一步都要写明执行时间、操作者、原始结果和预期；涉及删除、覆盖、网络规则或服务停止时，先确认备份与回滚命令。
2. 保留恢复入口
用MySQL命令列出Binlog和当前写入位置，核对log_bin_basename与index；文件系统列表只作辅助，不替代数据库视图。
每一步都要写明执行时间、操作者、原始结果和预期；涉及删除、覆盖、网络规则或服务停止时，先确认备份与回滚命令。
3. 取得直接证据
逐个核对复制拓扑、延迟、GTID或文件位置，确认离线副本、灾备和数据同步工具是否仍依赖旧日志。
每一步都要写明执行时间、操作者、原始结果和预期；涉及删除、覆盖、网络规则或服务停止时，先确认备份与回滚命令。
4. 只做最小变更
核对最近一次可恢复全备、增量链和目标RPO；如果没有可用全备，删除旧Binlog可能直接失去时间点恢复能力。
每一步都要写明执行时间、操作者、原始结果和预期；涉及删除、覆盖、网络规则或服务停止时，先确认备份与回滚命令。
5. 验证业务与副作用
确定边界后使用PURGE BINARY LOGS TO/BEFORE，先小批执行并观察；长期使用binlog_expire_logs_seconds等机制，但保留期必须大于最大故障发现与恢复窗口。
每一步都要写明执行时间、操作者、原始结果和预期；涉及删除、覆盖、网络规则或服务停止时，先确认备份与回滚命令。
6. 重启或跨峰复验
清理后验证数据库写入、副本延迟、备份任务、时间点恢复样本和磁盘增长率；设置空间与预计耗尽时间双告警。
每一步都要写明执行时间、操作者、原始结果和预期；涉及删除、覆盖、网络规则或服务停止时，先确认备份与回滚命令。
不应直接照做的五种处理
- rm -f直接删除Binlog
- 只看日期不查副本位置
- 空间满时立刻重启数据库
- 保留期短于备份与发现窗口
- 清理后不做恢复样本
这些做法并非永远错误，而是缺少适用条件。若确需执行，应在变更单中写清目标、影响范围、停止阈值、备份位置、回滚命令和预计恢复时间；高风险动作先在副本或小流量上演练。
回滚触发与数据边界
出现核心写入失败、持续5xx、管理员入口丢失、数据校验不一致、尾延迟越过停止阈值或监控失明时，应停止继续扩大变更。回滚前确认新旧环境各自产生了哪些写入，保留日志和配置差异；回滚后用相同请求和同一时间窗口重测，而不是只看首页恢复。
如果故障根因尚未确认但必须先恢复服务，可以采用限流、摘除单节点、恢复上一配置或临时切流等缓解措施，并明确它只是临时处置。恢复后仍要完成根因分析和复发验证，不能把“重启后正常”写成最终原因。
验收清单
- [ ] 活动文件已识别
- [ ] 所有副本位置已核对
- [ ] 备份链完整
- [ ] PURGE边界有记录
- [ ] 数据库可正常写入
- [ ] 复制无新错误
- [ ] 恢复样本成功
- [ ] 磁盘增长告警生效
验收应由另一位维护者按记录复现至少一项关键检查，并覆盖重启、真实高峰或等价受控负载。所有失败项都记录实际值与时间，不使用“基本正常”“应该没问题”作为关闭条件。
相关资料与隔离测试入口
站内可继续参考磁盘满清理、快照与备份、磁盘IO排查。需要搭建副本验证配置时，可查看美国轻量云和美国弹性云服务器的实时规格；先确认库存、价格和适用条件，不把测试环境当备份或生产容灾。
常见问题
Binlog可以手工删除吗？
不应直接用文件系统删除。MySQL还维护索引和复制/恢复关系，应使用官方PURGE或过期机制。
只保留一天可以吗？
取决于RPO、备份频率、最大复制延迟和故障发现时间。一天若短于任一窗口，就可能破坏恢复或复制。
expire设置后为什么没有马上删除？
过期检查与文件轮转、版本和配置有关。先核对变量、当前时间和日志轮转，不要重复手工删除。
磁盘已100%还能PURGE吗？
可能因元数据或临时空间不足而失败。先停止增长并安全释放非数据库空间，必要时扩盘；不要删除未知数据库文件。
清理Binlog会影响主库数据吗？
不会直接删除表数据，但会影响副本追赶和时间点恢复。风险在恢复链，不在当前查询结果。