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 归档是否中断