停机可接受选冷备，否则必须热备；冷备用mysqldump加锁表，大库需--single-transaction；热备用XtraBackup，须校验innodb_log_file_size一致且禁用symlink；备份后必须定期恢复演练验证有效性。
冷备 vs 热备：停机是否可接受决定备份类型
如果业务能接受短暂停机（比如凌晨维护窗口），mysqldump 配合 FLUSH TABLES WITH READ LOCK 是最简单可靠的冷备方式；一旦要求 7×24 运行，就必须用热备方案，否则锁表会导致应用写入失败甚至超时雪崩。
- 冷备适合小库（
- 热备必须依赖物理备份工具，如
Percona XtraBackup或 MySQL 8.0+ 原生mysqlbackup，它们通过拷贝 InnoDB redo log 和数据文件实现不锁表备份 -
mysqldump --single-transaction虽然不锁表，但只对 InnoDB 有效，且备份期间长事务会导致一致性视图膨胀，可能拖慢性能
mysqldump 参数组合直接影响备份可用性
默认的 mysqldump 输出不具备完整恢复能力，漏掉 --routines、--triggers、--events 会导致存储过程、触发器和事件丢失；而忽略 --set-gtid-purged=OFF 在 GTID 模式下会直接报错无法导入。
- 基础可用组合：
mysqldump --single-transaction --routines --triggers --events --set-gtid-purged=OFF --databases db1 db2 > backup.sql - 大库务必加
--skip-lock-tables（配合--single-transaction已隐含）并避免使用--lock-all-tables - 导出后建议用
head -n 20 backup.sql检查开头是否有SET @@SESSION.SQL_LOG_BIN= 0;—— 若有，恢复时可能意外跳过 binlog，导致主从不一致
Percona XtraBackup 备份失败常见原因
xtrabackup 报错大多不是权限或路径问题，而是 MySQL 运行状态不匹配。比如 innodb_log_file_size 变更后未重启 mysqld，备份会卡在 Copying ib_logfile0 并最终超时；又或者 datadir 下存在 symlink，XtraBackup 默认拒绝处理。
- 执行前先确认：
mysql -e "SHOW VARIABLES LIKE 'innodb_log_file_size';"与ls -lh /var/lib/mysql/ib_logfile*大小一致 - 备份命令必须指定用户和 socket：
xtrabackup --user=root --socket=/var/run/mysqld/mysqld.sock --backup --target-dir=/backup/full_$(date +%F) - 不要直接 rsync 数据目录——InnoDB 文件非原子写入，硬拷贝大概率损坏，必须用
xtrabackup --prepare完成崩溃恢复模拟后才能恢复
备份保留策略必须绑定校验与恢复演练
存了 30 天备份却从没验证过能否还原，等于没备。真实故障时才发现 xbstream 压缩包解不开、mysqldump 里混入了 /*!50718 ... */ 条件注释导致低版本 MySQL 导入失败，这类问题只能靠定期恢复测试暴露。
- 每周至少一次：用
mysql -e "CREATE DATABASE restore_test;"+mysql restore_test 快速验证逻辑备份可读性 - 每月一次：在隔离环境用
xtrabackup --copy-back恢复物理备份，并启动 mysqld 检查SHOW ENGINE INNODB STATUS\G是否有 corruption 报告 - 所有备份文件需附带元信息：
echo "$(date) $(mysql -V) $(mysql -e 'SELECT @@version_comment;')" > backup_20240601.meta
