MySQL主从备份应优先选稳定从库，停SQL线程保障一致性；逻辑备份用mysqldump加--single-transaction和--master-data=2；物理备份用xtrabackup配--slave-info与--safe-slave-backup；备份后须验证恢复与归档。

在 MySQL 主从环境中做备份，核心原则是：避免在主库上直接执行耗资源的备份操作，优先选择从库备份，同时确保备份的一致性和可恢复性。这样做既能减轻主库压力，又能保证业务写入不受影响。

选从库备份，但要确认复制状态稳定

从库备份的前提是复制延迟小、IO 和 SQL 线程都为 Yes，且 Seconds_Behind_Master 接近 0。否则备份可能包含不完整或过期的数据。

• 登录从库执行：SHOW SLAVE STATUS\G，检查 Slave_IO_Running 和 Slave_SQL_Running
• 若延迟较大，可先暂停写入主库（或业务低峰期操作），等从库追平后再备份
• 建议在备份前加锁确保一致性：在从库执行 STOP SLAVE SQL_THREAD;，备份完成再 START SLAVE SQL_THREAD;

用 mysqldump 做逻辑备份（适合中小数据量）

mysqldump 简单可靠，支持单库、多库、按表导出，并能自动记录 binlog 位置，便于后续搭建新从库或时间点恢复。

• 推荐命令（含 GTID 或 binlog 信息）：
  mysqldump --single-transaction --master-data=2 --routines --triggers --databases db1 db2 > backup.sql
• --single-transaction 保证 InnoDB 表一致性，无需锁表
  --master-data=2 把 CHANGE MASTER 语句注释输出，方便恢复后快速配置复制
• 如开启 GTID，加上 --set-gtid-purged=ON，确保 GTID 信息完整

用 xtrabackup 做物理备份（适合中大型生产环境）

xtrabackup 备份快、占用资源可控、支持增量和压缩，是高可用场景下的主流选择。注意必须在从库上运行，并关闭 SQL 线程防止备份期间数据变动。

• 全量备份示例：
  xtrabackup --backup --target-dir=/data/backup/full_$(date +%F) --slave-info --safe-slave-backup
• --slave-info 自动记录主库 binlog 位置到 xtrabackup_slave_info
--safe-slave-backup 会自动暂停 SQL 线程，备份完再恢复，保障一致性
• 备份后别忘了 xtrabackup --prepare，尤其是做了增量备份时

备份后验证与归档不能少

备份文件是否损坏、能否成功恢复，必须定期验证。只存不测等于没备。

• 抽样恢复测试：在测试环境还原一次备份，确认数据完整、服务可启、复制可配
• 校验关键信息：对比备份中的 binlog 文件名/位置与主库当前状态是否合理
• 归档策略要明确：本地保留 7 天，异地（如对象存储）保留 30 天，所有备份打上时间戳和实例标识