如何实现MySQL数据的物理备份_通过XtraBackup工具实现不停机备份恢复-mysql教程-PHP中文网

xtrabackup报“failed to connect to mysql server”主因是socket路径不匹配或mysql用户权限不足，需检查my.cnf中socket路径并显式指定--socket，同时授予reload、process、super、replication client权限。

如何实现mysql数据的物理备份_通过xtrabackup工具实现不停机备份恢复

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 是「回滚/前滚阶段」：让备份目录达到「一致性可启动状态」，必须离线做，且只能在备份完成后执行。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

全量备份流程固定为：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

真正难的不是命令敲对，而是理解每个步骤背后对 InnoDB crash recovery 机制的依赖。比如 --prepare 本质是模拟 MySQL 启动时的 redo 应用 + undo 回滚过程；而恢复后第一次启动，MySQL 仍会再走一遍 recovery 流程——这两遍不能冲突，否则就卡死在 opening tables 阶段。