MySQL日志归档需围绕可追溯、低影响、易恢复设计，区分binlog、error log、slow log等类型，按时间+空间双维度分级制定策略，通过cron+shell或logrotate自动化执行，并验证归档可用性、联动备份与故障恢复流程。
MySQL 日志归档方案不是简单“把旧日志删掉”，而是围绕可追溯、低影响、易恢复三个核心目标来设计。关键在于区分日志类型、设定合理生命周期、自动化执行，并与备份策略对齐。
明确归档对象：哪些日志必须管？
MySQL 中需归档的主要日志包括：
- 二进制日志（binlog）：用于主从同步和基于时间点的恢复，归档频率和保留时长直接影响 RPO（恢复点目标）
- 错误日志（error log）：记录启动、崩溃、连接异常等关键事件，建议按天轮转 + 压缩归档，保留 90 天以上
- 慢查询日志（slow query log）：性能分析依据，开启时建议配合 long_query_time 控制粒度，归档前可做简单聚合统计
- 通用查询日志（general log）：通常不建议长期开启，如临时启用，务必当天归档并关闭
设定归档策略：时间 + 空间双维度控制
避免“一刀切”保留或删除。推荐按业务重要性分级制定策略：
- 生产核心库 binlog：保留最近 7 天活跃日志 + 归档过去 30–90 天的压缩包（如 gzip），存于独立 NAS 或对象存储
- 错误日志：每日切割，保留 14 天在线，其余自动压缩为 error-20240501.gz 形式，保留 90 天
- 慢日志：每 6 小时切割一次，当日归档，保留原始日志 7 天 + 每日汇总报告（如 top 10 慢SQL）30 天
- 所有归档文件添加统一前缀（如 mysql-prod-binlog-）和时间戳，便于脚本识别和清理
用轻量脚本+系统机制实现自动化
不依赖第三方工具也能稳定运行。常用组合：
- MySQL 内置：
SET GLOBAL expire_logs_days = 7（仅控制 binlog 自动清理，不归档） - Linux cron + shell 脚本：每天凌晨执行，完成 rotate → compress → move → cleanup 四步
- 示例逻辑片段：
find /var/lib/mysql/logs/ -name "mysql-bin.*" -mtime +7 -exec gzip {} \; -exec mv {}.gz /backup/mysql/binlog/ \; - 配合 logrotate 工具管理错误日志和慢日志，配置 rotate 90、compress、dateext 等参数
验证与联动：归档不是终点
归档后必须验证可用性，并与整体运维流程打通：
- 每周随机抽取一个归档 binlog 包，解压后用
mysqlbinlog解析头 10 行，确认格式未损坏 - 将归档路径纳入备份监控项（如 Zabbix 检查目录大小突降或文件数异常）
- 在故障恢复 SOP 中明确写入：“若需 PITR，优先从 /backup/mysql/binlog/ 加载归档 binlog”
- DBA 排查问题时，应习惯先查归档错误日志目录，再看当前日志，避免遗漏历史上下文
