为什么 XtraBackup 备份时 MySQL 还能正常写入
因为 XtraBackup 通过复制 InnoDB 的 redo log 并结合数据文件的物理拷贝实现热备，全程不锁表（对 InnoDB 表），只在备份结束前对非 InnoDB 表（如 MyISAM）加短暂 FLUSH TABLES WITH READ LOCK。这意味着业务连接持续可用，但要注意：如果实例中存在大量 MyISAM 表，这个锁等待可能明显拖慢备份完成时间。
实操建议：
确认主库引擎以 InnoDB 为主，SHOW TABLE STATUS查看
Engine列，避免误用在重度 MyISAM 场景 备份前执行
SET GLOBAL innodb_fast_shutdown = 1（默认值），确保 shutdown 是“快速模式”，避免 backup 后 prepare 阶段卡住 不要在从库开启
read_only=ON且未关闭 relay log 清理的情况下直接备份——XtraBackup 会尝试读取
relay-log.info，若文件缺失或权限不足会报错
failed to open relay log info file
全量备份命令与关键参数含义
xtrabackup --backup --target-dir=/data/backup/full_$(date +%F_%H-%M)是最简可用命令，但生产环境必须补全关键选项：
--user和
--password必须显式指定（或改用
~/.my.cnf配置 [xtrabackup] 段），否则会提示
Failed to connect to MySQL server
--parallel=4可提升拷贝速度，但别超过 CPU 核数 × 2；过高反而因 I/O 竞争导致整体变慢
--compact能跳过二级索引页，减小备份体积（但 restore 前必须
--rebuild-indexes）
--no-timestamp不推荐——它会让
--target-dir必须是空目录，容易覆盖旧备份
备份后必须执行 prepare 才能恢复
刚备份完的目录不能直接用于恢复，因为 InnoDB 数据页处于“不一致”状态（redo log 尚未回放）。必须运行
xtrabackup --prepare，否则启动 MySQL 会报错
InnoDB: Database page corruption on disk或反复 crash。
常见操作链：
全量备份后：xtrabackup --prepare --target-dir=/data/backup/full_2024-06-15_10-20如果有增量备份：
xtrabackup --prepare --apply-log-only --target-dir=/data/backup/full_2024-06-15_10-20（先处理全量），再逐个 apply 增量目录
--apply-log-only对最后一个增量可省略，但漏掉会导致恢复时 missing last checkpoint
恢复到新实例时最容易忽略的权限和路径问题
把 prepare 好的备份目录 cp 到目标机器后，不能直接 chown mysql:mysql 就启动。MySQL 8.0+ 默认启用
innodb_directories安全限制，且 datadir 下的
ibdata1、
ib_logfile*文件权限、属主、甚至 SELinux 上下文都必须严格匹配。
典型翻车点：
目标机 MySQL 版本高于备份源（如 8.0.33 备份恢复到 8.0.34）通常安全；但跨大版本（如 5.7 → 8.0）必须用 mysqldump 中转，XtraBackup 不支持 恢复前没清空目标datadir，残留的
mysql系统库会与备份中的冲突，导致启动失败并打印
Table 'mysql.user' doesn't exist使用
cp -a复制时，若源机启用了 ACL 或扩展属性，目标机未安装
attr包会导致权限异常，建议改用
rsync -av --chown=mysql:mysql
