MySQL 8.0 一致性快照备份需用 --single-transaction（仅限InnoDB）、--master-data=2 和 --set-gtid-purged=ON 确保可恢复性，物理备份须执行 --prepare 才能一致。
MySQL 8.0 的一致性快照备份，核心在于避免备份过程中数据变更导致的逻辑不一致。直接用 mysqldump 加 --single-transaction 是最常用且有效的做法，但仅对 InnoDB 表生效，且依赖事务隔离与无 DDL 干扰 —— 这是多数人踩坑的起点。
为什么 --single-transaction 不总能保证全局一致？
该参数本质是启动一个 REPEATABLE READ 事务，在事务内读取所有表数据。但它只对 InnoDB 表起作用；MyISAM、CSV 或内存表（如 mysql.general_log）仍可能在备份中途被修改。MySQL 8.0 默认只有 mysql.general_log 和 mysql.slow_log 是 CSV 引擎，它们的数据不会被 --single-transaction 保护。
- 如果你的备份包含非 InnoDB 表，必须额外加
--lock-tables或--lock-all-tables（会阻塞写入） -
--single-transaction无法容忍备份期间执行ALTER TABLE、DROP TABLE、TRUNCATE TABLE等 DDL，否则会报错或中断 - 若备份耗时较长，而 binlog 日志轮转频繁，
--master-data记录的位点可能已过期，影响后续基于 binlog 的恢复
如何让 mysqldump 备份真正“可恢复”？
光导出 SQL 不等于能还原成原样。关键是要保留上下文信息，尤其是二进制日志坐标和 GTID 状态，否则无法做时间点恢复或主从搭建。
- 强制加入
--master-data=2：在备份文件开头插入CHANGE MASTER TO语句，记录当前 binlog 文件名与 position - 显式启用 GTID 支持：
--set-gtid-purged=ON（默认值），确保恢复时能正确识别 GTID 集合；若目标实例禁用 GTID，需设为OFF并手动清理 GTID 相关语句 - 排除不可导出/不必要内容：
--skip-log-bin（防止备份中意外开启 binlog）、--no-tablespaces（避免导出表空间定义，减少兼容性问题） - 示例完整命令：
mysqldump -u backup -p --all-databases --single-transaction --master-data=2 --set-gtid-purged=ON > full_backup_$(date +%Y%m%d).sql
物理备份（XtraBackup）的一致性准备阶段不能跳
XtraBackup 的备份文件本身是“不一致”的 —— 因为它只是并发拷贝了不同时间点的 ibd 文件。真正让它可恢复的，是 --prepare 阶段：重放 redo log，回滚未提交事务，使所有数据文件达到备份结束时刻的一致状态。
- 漏掉
--prepare直接--copy-back，MySQL 启动时会拒绝加载，报错类似InnoDB: Database page corruption on disk -
--prepare必须使用与备份时相同的 MySQL 配置（特别是innodb_page_size、innodb_log_file_size），否则可能失败 - 如果要支持增量恢复，备份后务必保留
xtrabackup_binlog_info和xtrabackup_checkpoints文件，它们记录了 LSN 和 binlog 位点
最容易被忽略的是：备份用户权限是否覆盖所有必要操作。比如 BACKUP_ADMIN 权限缺失会导致 --lock-instance-for-backup 失败；REPLICATION CLIENT 缺失则 --master-data 无法获取 binlog 位置 —— 这些错误往往静默发生，直到恢复时才发现位点为空或 GTID 错乱。
