xtrabackup是MySQL热备首选工具，因其支持不锁表备份InnoDB、持续监听redo log、物理备份恢复快、支持流式压缩，且需开启innodb_log_file_size和innodb_flush_log_at_trx_commit=1。
为什么 xtrabackup 是 MySQL 热备的首选工具
它能在不锁表、不中断业务写入的前提下，完整复制 InnoDB 数据文件和日志，靠的是对 redo log 的持续监听与追加。MyISAM 表虽会加读锁（短时间），但绝大多数生产库以 InnoDB 为主，所以实际影响极小。比 mysqldump 快得多，也比直接拷贝数据目录安全——后者在崩溃时大概率损坏。
- 备份过程不依赖 SQL 层，绕过锁、事务、字符集转换等干扰
- 支持流式备份（
--stream）和压缩（--compress），节省磁盘和网络开销 - 备份出来的是物理文件，恢复就是“还原+重放日志”，比逻辑导入快一个数量级
- 唯一硬性前提：MySQL 必须开启
innodb_log_file_size和innodb_flush_log_at_trx_commit=1（否则可能丢日志）
xtrabackup 全量备份命令怎么写才不出错
最简可用命令是：xtrabackup --backup --target-dir=/path/to/backup，但它默认用当前用户权限连接 MySQL，容易因权限不足失败。
- 必须提前创建专用账号，最小权限只需：
RELOAD, PROCESS, LOCK TABLES, REPLICATION CLIENT -
--user和--password不建议明文写在命令里，应通过~/.my.cnf配置，且该文件权限必须是600，否则xtrabackup拒绝读取 - 若 MySQL 运行在非标准端口或 socket 路径，必须显式指定：
--port=3307或--socket=/var/run/mysqld/mysqld.sock - 备份目标目录必须为空，否则报错
already exists；但可以是不存在的路径，xtrabackup会自动创建
备份后不做 --prepare 就恢复，99% 会失败
全量备份只是“原始镜像+未刷盘的日志片段”，必须执行 xtrabackup --prepare 才能将数据恢复到一致状态。跳过这步直接 --copy-back，MySQL 启动时会报 InnoDB: Database page corruption 或直接拒绝启动。
-
--prepare是只读操作，可离线做，不影响原库 - 如果备份时用了
--compress，恢复前得先--decompress，再--prepare，顺序不能反 - 增量备份也必须先
--prepare基础全量，再把增量日志合并进去，最后才统一--prepare一次 - 注意磁盘空间：
--prepare会临时占用和数据目录相当的空间，别在根分区只剩几 GB 时跑
如何验证热备是否真正可用
备份成功不等于能恢复。线上常见陷阱是：备份过程没报错，但恢复后发现主从同步断了、GTID 不连续、或者某个大表缺失索引。
- 恢复后必须执行
mysqlcheck --all-databases --check，重点看status: OK和警告数 - 对比原库和恢复库的
SELECT COUNT(*)和CHECKSUM TABLE（仅适用于小表，大表用采样） - 如果开了 GTID，检查
SELECT @@global.gtid_executed是否与备份时记录的xtrabackup_binlog_info中的 GTID 集一致 - 最关键一步：在测试机上拉起从库，执行
START SLAVE，观察Seconds_Behind_Master是否归零且稳定
热备不是设好定时任务就完事了，每次备份后那三行验证命令才是决定你半夜能不能睡觉的关键。尤其注意 xtrabackup_binlog_info 和 xtrabackup_galera_info（如果用 Galera）这两个文件，它们一旦被误删或内容不准，整个恢复链就断了。
