MySQL 主从备份应优先选稳定从库，停 SQL 线程保障一致性；逻辑备份用 mysqldump 加 –single-transaction 和 –master-data=2；物理备份用 xtrabackup 配 –slave-info 与 –safe-slave-backup；备份后须验证恢复与归档。
在 MySQL 主从环境中做备份，核心原则是： 避免在主库上直接执行耗资源的备份操作，优先选择从库备份，同时确保备份的一致性和可恢复性 。这样做既能减轻主库压力，又能保证业务写入不受影响。
选从库备份，但要确认复制状态稳定
从库备份的前提是复制延迟小、IO 和 SQL 线程都为 Yes，且 Seconds_Behind_Master 接近 0。否则备份可能包含不完整或过期的数据。
- 登录从库执行：
SHOW SLAVE STATUSG，检查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 天，所有备份打上时间戳和实例标识
