xtrabackup能热备份是因为直接操作InnoDB物理文件和redo log，不锁表；MyISAM仍需全局锁；流式备份传输的是xbstream/tar打包的物理文件；加密表空间需XtraBackup 8.0+配合密钥环。
为什么 xtrabackup 能不锁表做热备份
因为 InnoDB 的崩溃恢复机制允许它在备份过程中持续写入，xtrabackup 利用这个特性：一边拷贝数据文件（如 ibdata1、.ibd），一边持续读取并保存 redo log 的变化。只要备份结束前把增量 redo 补上，就能还原出一致性快照。
关键点在于：xtrabackup 不依赖 MySQL 的 SQL 层，而是直接操作 InnoDB 的物理文件和日志，所以不会触发 FLUSH TABLES WITH READ LOCK（除非你显式加 --lock-ddl 或备份 MyISAM 表）。
- MyISAM 表仍需全局只读锁 —— 如果库中混用 MyISAM，热备会卡在锁表阶段
- 备份期间 DDL（如
ALTER TABLE）可能被阻塞，尤其在 8.0+ 中涉及原子 DDL 时，xtrabackup会等其完成才继续 - redo 日志必须持续追到备份结束时刻，否则
apply-log阶段会报错log sequence number check failed
xtrabackup --stream 流式备份到底传什么
流式模式不是“把 SQL 导出来”，而是把物理文件打包成 tar 或 xbstream 格式，边打包边 stdout 输出 —— 所以你能用管道直接压缩或传到远程。
xbstream 是官方推荐格式，支持并发、断点续传和元数据标记；tar 更通用但无法跳过损坏块，也不带校验信息。
- 必须加
--parallel=4配合流式，否则默认单线程，吞吐极低 -
--stream=xbstream时，--compress有效；但--stream=tar时不支持在线压缩，得靠gzip |外部处理 - 远程备份命令常见错误：漏掉
--no-timestamp，导致xbstream解包时找不到子目录，报cannot open dir
xtrabackup --backup --stream=xbstream --parallel=4 --target-dir=/tmp/backup/ | ssh user@backup-host "xbstream -x -C /backup/20240520/"
备份后 apply-log 报错 page_log_seq_no 不匹配怎么办
这通常说明备份过程中 redo 日志被覆盖（比如 innodb_log_file_size 太小 + 写入太猛），或者 xtrabackup 没来得及把最后几段 redo 拷全就结束了。
根本原因不是备份失败，而是 apply-log 阶段发现数据页的 LSN 和日志里记录的不一致，拒绝强行合并。
- 先检查备份日志末尾有没有
completed OK!，如果没有，说明备份中途被 kill 或磁盘满 - 用
xtrabackup --prepare --target-dir=...重试时，加上--use-memory=2G（至少为可用内存 50%），避免因内存不足跳过部分日志解析 - 如果确认是 redo 覆盖，唯一办法是缩短备份窗口：减小单次备份量、避开业务高峰、或调大
innodb_log_file_size
MySQL 8.0+ 下 xtrabackup 备份加密表空间失败
8.0.14+ 默认开启 innodb_redo_log_encrypt 和表空间加密（ENCRYPTION='Y'），而 xtrabackup 2.4.x 完全不识别加密逻辑，会直接跳过加密表空间，且不报错 —— 导致恢复后缺失几张表。
目前只有 Percona XtraBackup 8.0+ 支持解密备份，且要求 MySQL 启动时已加载密钥环插件（keyring_file 或 keyring_vault），且备份命令显式指定 --keyring-file-data。
- 检查是否加密：查
INFORMATION_SCHEMA.INNODB_TABLESPACES的ENCRYPTION列 - Percona XtraBackup 8.0 必须和 MySQL 8.0 主版本号严格一致（如 MySQL 8.0.33 → 用 xtrabackup 8.0.33）
- 即使配置了 keyring，
xtrabackup仍可能因权限问题读不到密钥文件，报failed to load keyring，此时要确认运行用户对keyring_file_data路径有读权限
apply-log 成功把所有 redo 对齐到每个数据页的那一瞬间。这个瞬间，依赖日志没丢、LSN 没断、密钥没藏太深。 
