BACKUP_ADMIN 是 MySQL 8.0 物理热备的刚性依赖，不可省略；它替代已移除的 SUPER 权限，专用于启用 backup lock，缺失将导致 xtrabackup 卡在 “Waiting for backup lock” 而不报错；必须显式授予 ON .，且需与 RELOAD、LOCK TABLES 等库级权限分条授权，否则权限失效。
BACKUP_ADMIN 是 MySQL 8.0 物理热备的刚性依赖，不是可选项
MySQL 8.0 彻底移除了 SUPER 权限，而 BACKUP_ADMIN 是替代它执行备份锁（backup lock）的唯一权限。没有它，xtrabackup 在 --single-transaction 模式下 fallback 到 FTWRL（FLUSH TABLES WITH READ LOCK）时会直接失败，日志里只显示 “Waiting for backup lock” 卡住，不会报错，但备份永远不动。
这个权限必须显式授予，且只能用 ON *.* 方式——它不支持库级限定，也不接受反引号包裹的库名。哪怕你只备份 `myapp`，授权语句也必须写成：
GRANT BACKUP_ADMIN ON *.* TO 'bkp'@'localhost';
常见错误包括：
- 漏授
BACKUP_ADMIN，只给了RELOAD和LOCK TABLES（8.0 下这两者已无法替代SUPER） - 误写为
GRANT BACKUP_ADMIN ON `myapp`.*（语法合法但权限不生效） - 与
RELOAD/LOCK TABLES混在同一条GRANT语句中却用了ON *.*（导致后两者实际未绑定到具体库，后续 FTWRL 失败）
为什么不能把 BACKUP_ADMIN 和 RELOAD/LOCK TABLES 合并在一条 GRANT 里
MySQL 8.0 的权限模型要求：不同作用域的权限必须分开授权。例如：
-
BACKUP_ADMIN、REPLICATION CLIENT、PROCESS是全局权限 → 必须ON *.* -
RELOAD和LOCK TABLES是库级权限 → 必须明确指定目标库，如ON `app_db`.*
如果你写成：
GRANT RELOAD, LOCK TABLES, BACKUP_ADMIN ON *.* TO 'bkp'@'localhost';
那 RELOAD 和 LOCK TABLES 实际没绑定任何库，后续执行 FLUSH TABLES WITH READ LOCK 时静默失败。正确做法是分两条：
GRANT RELOAD, LOCK TABLES ON `app_db`.* TO 'bkp'@'localhost';<br>GRANT BACKUP_ADMIN, REPLICATION CLIENT, PROCESS ON *.* TO 'bkp'@'localhost';
验证 BACKUP_ADMIN 是否真正生效的三个关键检查点
仅靠 SHOW GRANTS 不够，要结合行为验证：
- 执行
xtrabackup --backup --target-dir=/tmp/test --user=bkp --password=xxx，观察日志是否出现Using backup lock（说明BACKUP_ADMIN起效）；若看到FTWRL或卡在Waiting for backup lock，说明权限缺失或错配 - 手动登录 MySQL，执行
SELECT * FROM performance_schema.keyring_component_status;—— 如果报错Access denied，说明缺少SELECT ON performance_schema.keyring_component_status（XtraBackup 8.0+ 某些场景会读取该表，需额外授权） - 运行
mysql -u bkp -p -e "SELECT 1;"确认账号能连通；再执行mysql -u bkp -p -e "SHOW MASTER STATUS;"验证REPLICATION CLIENT是否可用（BACKUP_ADMIN单独无法替代它）
BACKUP_ADMIN 权限本身不涉及数据读写，但它开启的是整个物理备份流程的“门禁”
这个权限不让你读一行数据、不让你删一张表，但它决定了 XtraBackup 能否安全地暂停 InnoDB 内部状态、获取一致性快照。一旦它失效，备份就退化为不可靠的逻辑快照或直接阻塞。生产环境里最容易被忽略的一点是：BACKUP_ADMIN 授权后，必须确保 MySQL 用户密码未过期、账户未锁定、host 匹配（'bkp'@'localhost' 和 'bkp'@'127.0.0.1' 是两个不同用户），否则权限存在但根本连不进去——这种问题在 OpenEuler 等默认启用 strict host 检查的系统上尤其常见。
