xtrabackup报“failed to connect to MySQL server”主因是socket路径不匹配或MySQL用户权限不足，需检查my.cnf中socket路径并显式指定--socket，同时授予RELOAD、PROCESS、SUPER、REPLICATION CLIENT权限。
Percona XtraBackup 是目前 MySQL 生产环境中最主流的物理热备份工具，它能真正实现「不锁表、不停服务」的全量/增量备份。但直接上手容易踩坑——尤其在版本匹配、权限配置和恢复一致性上。
为什么 xtrabackup 命令执行报错 “failed to connect to MySQL server”
这不是网络问题，而是 xtrabackup 默认尝试用 root@localhost 通过 socket 连接 MySQL，但实际环境中往往没配好 socket 路径或用户权限。
- 检查
my.cnf中socket路径是否与xtrabackup默认路径（如/var/lib/mysql/mysql.sock）一致，不一致需显式指定：--socket=/path/to/mysql.sock - MySQL 用户必须有
RELOAD、PROCESS、SUPER、REPLICATION CLIENT权限，仅SELECT不够 - 若用 TCP 连接（如远程备份），必须加
--host、--port、--user、--password，且 MySQL 的bind-address不能是127.0.0.1（否则拒绝远程连接）
备份时加 --backup 还是 --prepare？顺序不能反
--backup 是「拷贝阶段」：把 InnoDB 数据文件、redo 日志、表结构等实时复制出来，期间 MySQL 可读写；--prepare 是「回滚/前滚阶段」：让备份目录达到「一致性可启动状态」，必须离线做，且只能在备份完成后执行。
- 全量备份流程固定为：
xtrabackup --backup --target-dir=/backup/full_$(date +%F)→ 拷贝完成 →xtrabackup --prepare --target-dir=/backup/full_2026-05-07 - 如果跳过
--prepare直接还原，MySQL 启动会失败，并报错InnoDB: Database page corruption on disk - 增量备份必须基于已
--prepare的全量备份目录，且增量包自身也需先--prepare（带--apply-log-only），最后才对全量目录做最终--prepare
恢复后 MySQL 启动失败，提示 Table 'mysql.plugin' doesn't exist
这是典型的数据目录权限/结构不完整问题。XtraBackup 恢复的是数据文件，但不会自动重建 mysql 系统库的缺失表（尤其是从低版本备份恢复到高版本时）。
- 确认恢复目标目录（如
/var/lib/mysql）下是否有完整的mysql/、performance_schema/、sys/子目录，缺任何一个都可能启动失败 - 若原实例启用了
innodb_file_per_table=OFF，备份中ibdata1包含系统表空间，恢复时必须连同该文件一起放回，不能只恢复单个库目录 - 恢复前务必清空目标数据目录（
rm -rf /var/lib/mysql/*），但不要删目录本身；恢复后用chown -R mysql:mysql /var/lib/mysql重置属主 - MySQL 8.0+ 实例恢复后首次启动，建议加
--initialize-insecure初始化系统表（仅限恢复场景，非新建实例），否则mysql.plugin表可能为空
用 xtrabackup 恢复后 binlog 位点丢失，怎么保证主从断点续传
物理备份本身不记录 binlog 文件名和 position，但 xtrabackup 在备份结束时会把当前 binlog 位置写入 xtrabackup_binlog_info 文件。这个文件必须保留并用于后续主从配置。
- 备份完成后立即查看：
cat /backup/full_2026-05-07/xtrabackup_binlog_info，输出类似mysql-bin.000012 1987456 - 恢复到新实例后，启动 MySQL 前先停掉
slave（如果已配置），再执行：CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000012', MASTER_LOG_POS=1987456; - 注意：该位点是备份「结束时刻」的位点，不是开始时刻，所以主从同步不会丢数据，但会重放备份期间产生的事务（这是正确行为）
- 如果备份过程中有 GTID 开启，应优先使用
xtrabackup_galera_info或xtrabackup_binlog_info中的GTID_EXECUTED值，而非手动解析 binlog
--prepare 本质是模拟 MySQL 启动时的 redo 应用 + undo 回滚过程；而恢复后第一次启动，MySQL 仍会再走一遍 recovery 流程——这两遍不能冲突，否则就卡死在 opening tables 阶段。 
