MySQL binlog 是什么
二进制日志记录实例上所有数据变更，是按时间点恢复与主从复制的基础。它按文件顺序追加写入，每个文件有编号与位点坐标，恢复时从某个坐标开始顺序回放。日志格式分 STATEMENT、ROW 与 MIXED 三种，8.0 默认使用 ROW。
基本信息
| 开启方式 | 启动参数中打开日志，8.0 起默认开启 |
|---|---|
| 存储位置 | 由 datadir 与日志文件名前缀决定 |
| 过期控制 | binlog_expire_logs_seconds，默认 2592000 秒即 30 天 |
| 归档要求 | 备份系统应把日志持续复制到独立存储，防止清理造成断链 |
| 查看工具 | mysqlbinlog 解析为可读语句或行事件 |
查看与维护
查看与维护
SHOW VARIABLES LIKE 'log_bin'; -- 确认是否开启
SHOW BINARY LOGS; -- 日志文件列表与大小
SHOW MASTER STATUS; -- 8.2 起请改用 SHOW BINARY LOG STATUS
FLUSH BINARY LOGS; -- 切换新文件便于归档
SHOW VARIABLES LIKE 'binlog_expire_logs_seconds'; -- 过期时间三种日志格式
| 格式 | 记录内容 | 特点 |
|---|---|---|
| STATEMENT | 原始 SQL 语句 | 体积小，但依赖执行环境一致 |
| ROW | 行级前后镜像变化 | 结果确定，体积较大，为默认推荐 |
| MIXED | 按语句自行选择 | 兼顾体积与确定性，行为较复杂 |
典型使用场景
- 时间点恢复：还原全量备份后从备份坐标开始回放，精确停在目标时刻
- 主从复制：从库读取主库日志并重放，保持数据同步
- 审计追溯：分析某段时间内的变更来源，定位异常数据的写入者
- 数据订阅：把日志作为变更流，同步到下游分析或缓存系统
- 增量归档：按日志文件粒度持续搬运到独立存储，形成可回放的连续序列
直接删除 binlog 文件会破坏复制与时间点恢复；清理应通过日志清理语句或过期参数进行，并确保备份侧已经归档。
日志文件与数据文件分开存放很有必要：同盘存放时一次磁盘故障会同时损失数据与其恢复所需的日志，恢复链直接断裂。
归档与清理的注意点
- 归档任务要持续运行：日志文件被切换后应立即搬运，不能等过期前才补
- 清理前先确认备份侧已完整接收，并保留足够的回溯跨度
- 清理动作要留记录：记下清理到哪个文件，便于事后判断恢复边界
- 日志切换到新文件有助于归档与保留策略的边界管理