必须用xtrabackup-80配qpress，mysql 8.0.33+须加--no-server-version-check；缺qpress导致--decompress报错，不加该参数会卡在连接阶段，且innodb_log_file_size配置必须与实际文件大小一致。
必须用 xtrabackup-80（或 xtrabackup-84）匹配 MySQL 8.x，且 qpress 缺一不可；MySQL 8.0.33+ 不加 --no-server-version-check 会卡死在连接阶段。
安装 xtrabackup-80 和 qpress 为什么总出错？
常见错误现象：yum install percona-xtrabackup-80 后 xtrabackup --version 显示 2.4.x 或报 Unsupported MySQL version；--compress 备份后，--decompress 报 qpress: command not found 或静默失败。
根本原因：Percona 官方源只提供 percona-xtrabackup-80，不带 qpress；而启用 --compress 时，xtrabackup 会在后台调用 qpress 命令。没装它，备份看似成功，解压直接崩。
- 先启用 EPEL：
yum install -y epel-release - （可选但推荐）换清华源加速：
sed -i 's|^mirrorlist=|#mirrorlist=|; s|^#baseurl=http://download.example.com|baseurl=https://mirrors.tuna.tsinghua.edu.cn/epel|' /etc/yum.repos.d/epel.repo - 再装两个包：
yum install -y percona-xtrabackup-80 qpress - 验证：
xtrabackup --version应输出含8.0.x based on MySQL 8.0.xx；qpress -h不报错
MySQL 用户权限和配置文件怎么配才连得上？
xtrabackup 不是“连上就行”，它需要特定权限完成锁表、刷日志、读 binlog 位置等动作。仅靠 root@localhost 也不保险——如果 MySQL 启用了 caching_sha2_password 认证，又没配兼容方式，--defaults-file 里的用户会连不上。
- 在 MySQL 中创建专用用户并授权：
GRANT RELOAD, PROCESS, LOCK TABLES, REPLICATION CLIENT, SUPER ON *.* TO 'bkpuser'@'localhost'; -
--defaults-file必须指向含[client]段的配置文件（如/etc/my.cnf），里面要明确写user = bkpuser和password = xxx；不能只靠环境变量或命令行传参 - 若用 socket 连接失败，
xtrabackup默认 fallback 到 TCP，但前提是my.cnf里[client]段有host = 127.0.0.1，否则可能连错或超时
全量备份命令里 --no-server-version-check 真的不能省？
MySQL 8.0.33+ 与 xtrabackup-80（8.0.32+）存在 handshake 兼容性 bug。不加这个参数，命令会卡在 Connecting to MySQL server host: localhost，无报错、无退出、日志也空——看起来像挂起，其实是协议握手失败。
正确全备命令示例：
xtrabackup \ --backup \ --target-dir=/data/backup/full_$(date +%Y%m%d_%H%M%S) \ --defaults-file=/etc/my.cnf \ --no-server-version-check \ --parallel=4
-
--no-server-version-check是 MySQL 8.0.33+ 的硬性要求，不是可选项 -
--parallel=4可提升速度，但值不宜超过 CPU 核心数 - 全备后必须立即执行
--prepare，否则无法用于恢复或增量 - 增量备份必须基于已
--prepare的全量目录，不能直接对原始全备目录操作
innodb_log_file_size 配置不一致会引发什么问题？
备份中途报 Cannot open /var/lib/mysql/ib_logfile0，大概率是 my.cnf 中 innodb_log_file_size 的值与磁盘上实际 ib_logfile0 文件大小不一致。
这不是备份脚本的问题，而是 MySQL 实例本身的配置漂移。检查方法：
- 查配置：
grep innodb_log_file_size /etc/my.cnf - 查实际：
ls -lh /var/lib/mysql/ib_logfile0 - 两者必须严格相等；若不一致，需先停库、删除旧日志文件、修改配置、再启库，否则任何
xtrabackup操作都可能失败
这个点容易被忽略，因为错误信息不指向配置项本身，而表现为“文件打不开”。
