超大数据库（50GB+）必须用xtrabackup做物理热备，因其全程无锁、专为InnoDB优化；innobackupex因对MyISAM加全局读锁已被8.0+废弃；需配合--parallel与--compress协同降IO压力；备份后须立即--prepare，否则恢复失败；注意SELinux上下文权限。
直接上结论：超大数据库（50GB+）必须用 xtrabackup 做物理热备，mysqldump 在这种量级下不是慢的问题，是根本不可控——备份窗口拉长、锁表风险高、恢复时间动辄数小时，线上业务扛不住。
为什么不能只用 innobackupex？
innobackupex 是 Perl 封装脚本，对 MyISAM 表会触发 FLUSH TABLES WITH READ LOCK，哪怕只有一张 MyISAM 表，整个库在备份非 InnoDB 文件阶段都会被全局只读锁住。超大库下这个锁可能持续几十秒甚至几分钟，足以触发业务告警。而纯 xtrabackup 只处理 InnoDB/XtraDB，全程无锁，更适合以 InnoDB 为主的现代生产环境。
- 确认引擎类型：
SELECT table_schema, table_name, engine FROM information_schema.tables WHERE table_schema NOT IN ('mysql','information_schema','performance_schema','sys'); - 如果结果里没有
MyISAM，就别用innobackupex，直接上xtrabackup - MySQL 8.0+ 必须用
percona-xtrabackup-80包，xtrabackup二进制文件名是xtrabackup（不是xtrabackup_80） -
innobackupex在 8.0+ 版本中已被废弃，Percona 官方明确不维护
--parallel 和 --compress 必须配着用
单线程备份 TB 级数据，IO 和 CPU 都浪费；但盲目开多线程又容易打满磁盘带宽，拖慢线上查询。关键是让压缩和并行协同工作，把瓶颈从磁盘 I/O 转移到 CPU，反而更稳。
-
--parallel=4+--compress+--compress-threads=2是 100–500GB 库的实测甜点组合 - 压缩能减少 40%–60% 备份体积，同时降低写盘压力；压缩线程数建议设为并行数的一半，避免 CPU 争抢
- 不要加
--stream=xbstream直接远程传输——xbstream 流式压缩在断网或管道阻塞时容易卡死，且无法断点续传 - 真要远程备份，先本地完成，再用
rsync --partial --progress同步，可控性高得多
备份后必须立刻 --prepare，不能“先存着再说”
刚备份出来的目录不是即用状态，它只是“带 redo log 的原始页拷贝”，里面混着未提交事务、部分写入页、回滚段残留。不 --prepare 就去恢复，MySQL 启动直接报错 InnoDB: Database page corruption on disk 或卡死在 crash recovery 阶段。
-
xtrabackup --prepare --target-dir=/data/backup/full这一步必须在备份完成后立即执行（最好同一台机器，避免网络延迟） - 全量备份准备耗时 ≈ 备份耗时的 30%–50%，增量备份准备必须基于上一次全量 prepare 后的目录，否则报
Invalid backup: missing xtrabackup_checkpoints - 准备过程可中断，但中断后必须重新从头开始 —— 它不支持增量 prepare
- 准备完检查
/data/backup/full/xtrabackup_binlog_info和xtrabackup_checkpoints是否存在且内容合理（尤其是backup_type = full-prepared）
最容易被忽略的是权限和 SELinux：备份目录若挂载在 /backup 这类非标准路径，xtrabackup 可能因 SELinux 上下文受限写失败，错误信息是 Failed to open file ... Permission denied；别急着关 SELinux，先用 chcon -t mysqld_db_t /backup 修正上下文更安全。
