MySQL 结合 binlog 做容灾，核心是利用 binlog 的逻辑日志特性，实现主库故障后快速恢复数据一致性，同时支持时间点恢复（PITR）和跨机房/跨云的数据同步。关键不在于单纯开启 binlog，而在于规范配置、可靠归档、定期验证和配套的切换流程。
确保 binlog 正确启用与关键参数配置
binlog 必须启用且配置合理，否则容灾链路从源头就不可靠：
log_bin = ON：必须显式开启（如 log_bin = /data/mysql/binlogs/mysql-bin），路径需有足够空间和独立磁盘 binlog_format = ROW：推荐使用 ROW 格式，避免语句级复制在主从或恢复时因函数、临时表等导致不一致 binlog_row_image = FULL：确保所有列变更都被记录，为精确回滚和审计提供基础 expire_logs_days = 7（或用 binlog_expire_logs_seconds）：设置合理保留周期，既防磁盘满，又保障足够恢复窗口；生产建议至少保留 3–7 天 sync_binlog = 1：每次事务提交都刷盘，牺牲少量性能换取 binlog 不丢失，容灾场景强烈推荐构建可靠的 binlog 归档与存储机制
本地 binlog 只是临时缓存，容灾依赖的是**可长期保存、异地可用、校验完整**的归档副本：
使用 mysqlbinlog --read-from-remote-server 或 rsync + rotate 定期拉取并压缩归档到对象存储（如 S3、OSS）或独立备份服务器 归档文件命名需含时间戳和 server_id，例如：mysql-bin.000042_20240520143000_s12345.gz 每次归档后生成 SHA256 校验值并落库或写入元数据文件，便于后续恢复前验证完整性 避免仅依赖 MySQL 自动 purge，归档完成后才执行 PURGE BINARY LOGS设计可验证的容灾恢复流程
没有验证的恢复方案等于纸上谈兵。容灾恢复应覆盖两种典型场景：
全量+增量恢复：先用最近一次物理备份（如 xtrabackup）恢复基础数据，再按顺序重放归档 binlog 到指定位置（mysqlbinlog | mysql），最后用 SHOW BINLOG EVENTS 确认位点一致 时间点恢复（PITR）：通过 mysqlbinlog --stop-datetime 或 --stop-position 截断重放，适用于误删、逻辑错误等场景；务必提前在测试环境演练跳过 DDL/DML 的组合操作 每次恢复演练后，比对关键业务表的行数、checksum 和样本数据，确认逻辑一致性，不只看 SQL 是否执行成功配合高可用架构实现自动/半自动容灾切换
binlog 是数据底座，但容灾生效还需上层协同：
主从架构中，从库开启 relay_log_recovery = ON 和 skip_slave_start = OFF，确保崩溃重启后能自动续传 使用 MHA、Orchestrator 或自研探活工具监控主库状态；检测失败后，选取延迟最小、binlog 最新的从库提升为主，并更新 DNS/VIP/配置中心 切换后立即检查新主库的 SHOW MASTER STATUS，确认其 binlog 位置已连续，避免断点；旧主恢复后应作为从库重新接入，而非直接上线 应用层需支持连接重试与读写分离路由动态刷新，避免因切换出现长时间写失败
