必须显式设置expire_logs_days=7、log_bin指向独立目录、MySQL用户有读权限，并用rsync -avz --delete --checksum --partial同步；同步前执行FLUSH LOGS，同步后校验checksum；全量备份需带--master-data=2以绑定binlog坐标。
不能直接 rsync MySQL 数据目录，但可以安全同步 binlog 文件——前提是配置、权限、校验三者都到位。
rsync 同步 binlog 前必须确认 expire_logs_days 和 log_bin 路径
binlog 文件被自动清理是异地同步失败最常见原因。默认 expire_logs_days = 0 表示“不主动删”，但磁盘满时 MySQL 会强制 purge，导致 rsync 找不到前序日志，mysqlbinlog --start-position 恢复链断裂。
- 必须显式设置
expire_logs_days = 7（或更长，按 RPO 要求定），写入/etc/my.cnf的[mysqld]段并重启生效 -
log_bin必须指向独立目录（如/data/mysql/binlog/），避免和数据文件混在一起；否则 rsync 会误扫或权限冲突 - 确认 MySQL 用户对该目录有读权限：
ls -ld /data/mysql/binlog/应显示 owner 是mysql，且至少含r-x
rsync 命令必须带 --delete、--checksum 和 --partial
只用 rsync -avz 同步 binlog 目录，大概率在某次网络中断后留下半截文件，后续恢复时 mysqlbinlog 解析失败，报错 Invalid replication event size 或直接跳过。
-
--delete：确保目标端只保留当前有效的 binlog 文件集，防止旧日志堆积干扰恢复点判断 -
--checksum：强制内容比对，哪怕时间戳和大小一致也重传，防静默损坏（尤其跨数据中心传输） -
--partial：断点续传必需，避免因超时中断后整个文件重传，浪费带宽和时间 - 完整命令示例：
rsync -avz --delete --checksum --partial --progress /data/mysql/binlog/ user@backup-server:/backup/binlog/
同步脚本里要加 FLUSH LOGS + mysqlbinlog --verify-binlog-checksum 校验
binlog 文件正在被写入时直接 rsync，可能拷出不完整的事务片段。不校验就传走，异地备份等于白做。
- 每次同步前执行：
mysql -e "FLUSH LOGS;"，强制生成新 binlog 文件，确保正在写的那个已关闭 - 同步完成后，在备份端运行：
mysqlbinlog --verify-binlog-checksum /backup/binlog/mysql-bin.000042，输出无报错才算有效 - 若校验失败，脚本应退出并告警，而不是继续下一轮；可加重试逻辑（最多 2 次），超限则停服检查
- 注意：MySQL 5.7+ 默认开启
binlog_checksum = CRC32，若源库关了该选项，备份端校验会失败
异地恢复时，mysqlbinlog 的起始位置必须来自全量备份的 MASTER_LOG_FILE 和 MASTER_LOG_POS
只有一堆 binlog 文件没用。没有全量备份的坐标，你根本不知道从哪条日志、哪个 position 开始重放。
- 全量备份（
mysqldump）必须带--master-data=2，它会在 SQL 文件头写入类似-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000041', MASTER_LOG_POS=12345; - 恢复流程是：先导入 dump 文件 → 再用
mysqlbinlog --start-file=mysql-bin.000041 --start-position=12345接续重放 → 最终数据才完整 - 别指望靠
SHOW MASTER STATUS查当前位置来恢复——那是主库此刻状态，不是备份那一刻的状态
真正难的不是 rsync 命令本身，而是把 FLUSH LOGS 的时机、expire_logs_days 的保留窗口、以及全量备份与 binlog 的坐标绑定这三件事串成闭环。漏掉任意一环，异地备份就只是“看起来有”，而不是“真能用”。
