xtrabackup 备份时 mysql 仍可写入，因其对 innodb 表采用热备机制（复制 redo log + 物理拷贝），仅在结尾对 myisam 表加短暂全局读锁；需确保主库以 innodb 为主、fast_shutdown=1、避免 read_only 从库未清理 relay log 等问题。
为什么 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
