binlog 归档是什么
时间点恢复（PITR）的命脉是 binlog 全量归档：全量备份只能恢复到备份那一刻，之后的所有变更都依赖 binlog 重放。常见做法是两条腿走路——定时用 rsync 拷贝新增的 binlog 文件，再加上 mysqlbinlog --raw --stop-never 从主库实时流式拉取到备份机，两者互相补位，任何一条链路断了都还有另一条。
基本信息
| 归档对象 | mysql-bin.* 系列 binlog 文件 |
|---|---|
| 方式一 | rsync 定时拷贝新增文件，实现简单 |
| 方式二 | mysqlbinlog --read-from-remote-server --raw --stop-never 流式拉取 |
| 权限 | 远程拉取需要 REPLICATION SLAVE 或 REPLICATION CLIENT |
| 保留策略 | 至少覆盖两次全量备份之间的所有 binlog |
典型使用场景
- 搭建时间点恢复能力的第一步
- 全备之间发生误删数据，需要回滚到具体时刻
- 审计要求保留一段时间的变更记录
- 机房搬迁或实例迁移时同步日志链路
- 排查归档是否中断，确认恢复能力仍然存在
两种归档方式
两种归档方式
# 方式一：定时 rsync 拷贝新增文件（简单）
rsync -a --include='mysql-bin.*' --exclude='*' \
/var/lib/mysql/ /data/binlog_archive/
# 方式二：流式实时拉取到备份机
mysqlbinlog --read-from-remote-server --raw --stop-never \
--host=10.0.0.10 --user=repl_backup --password='***' \
--result-file=/data/binlog_archive/ mysql-bin.000039
# 校验：与服务器上的日志列表逐一核对
mysql -uroot -p -e "SHOW BINARY LOGS;"方式与注意点
| 方式 | 优点 | 注意事项 |
|---|---|---|
| rsync 拷贝 | 实现简单，不额外占用复制连接 | 要考虑文件仍在写入的情况 |
| 流式拉取 | 接近实时，能立刻跟上新日志 | 需要复制权限与稳定网络 |
| 校验清单 | 定期与日志列表对比 | 核对文件数量与大小是否一致 |
| 分层目录 | 按日期与实例组织 | 恢复时定位文件更快 |
| 保留期 | 覆盖两次全备之间 | 过早清理会导致无法完整重放 |
归档目录建议按「日期/实例」分层，并附带校验值清单：恢复时能快速确认文件完整性，也能一眼看出哪一天的归档缺失。
归档盘不要与数据库同机：主机级故障会让 binlog 与数据一起丢失，归档的意义直接归零，至少放到不同的故障域。
流式拉取进程必须纳入监控：它退出后不会自动续上，等到需要恢复时才发现最后几个文件缺失，届时代价极高。