MySQL主从架构非备份方案但可支撑备份体系，需结合从库物理备份（XtraBackup）、逻辑备份（mysqldump）、主库binlog归档及定期恢复验证。
MySQL 主从架构本身不是备份方案，但可以作为备份体系的重要支撑。真正可靠的备份需要结合主从角色分工、数据一致性保障和恢复验证机制。
利用从库做物理备份（推荐）
在从库上执行物理备份（如 Percona XtraBackup），避免对主库产生性能影响。关键前提是确保从库已追平主库（Seconds_Behind_Master = 0），且 IO/SQL 线程均正常运行。
- 备份前执行 STOP SLAVE SQL_THREAD，暂停 SQL 线程但保持 IO 线程接收 binlog，可获得一个一致的备份点
- 用 xtrabackup --slave-info 记录当前复制位置（包含 Master_Log_File 和 Read_Master_Log_Pos），便于后续恢复后快速重建复制
- 备份完成后执行 START SLAVE SQL_THREAD 恢复同步
从库上定时导出逻辑备份作补充
物理备份恢复快，但逻辑备份（mysqldump 或 mydumper）更灵活，适合单表/单库恢复或跨版本迁移。建议在从库上每日低峰期执行：
- 使用 --single-transaction --master-data=2 保证一致性，并记录备份时刻的 binlog 位置
- 按库或按表拆分导出文件，配合压缩和保留周期（如保留最近 7 天）
- 避免在主库上执行 mysqldump，尤其大表容易引发锁等待和主从延迟
主库保留完整 binlog，支撑时间点恢复（PITR）
仅靠全量备份无法应对误删、误更新等逻辑错误。必须依赖主库持续归档的 binlog，与最近一次全备配合实现精确回退。
- 主库配置 expire_logs_days = 7（或更长），同时将 binlog 同步到独立存储（如 NFS、对象存储）防止主机故障丢失
- 恢复时：先还原最近全备 → 启动 MySQL → 使用 mysqlbinlog 解析并重放 binlog 至故障前一秒
- 建议定期校验 binlog 可读性（如 mysqlbinlog -v binlog.000001 | head -20）
自动化与验证不能少
再完善的备份策略，不验证就等于没备份。需建立闭环机制：
- 用脚本自动检测备份文件完整性（如 xtrabackup_checkpoints 存在、dump 文件含 “Dump completed” 字样）
- 每周至少一次在隔离环境还原备份 + 应用 binlog，验证能否成功启库并查到预期数据
- 监控项包括：备份任务是否超时、从库延迟是否持续 > 60 秒、binlog 归档是否中断
