mysql如何利用xtrabackup进行跨机扩容_mysql物理备份迁移

必须加–slave-info才能正确恢复为新从库，否则缺失binlog位置和GTID导致CHANGE MASTER TO失败；需清空datadir、禁用innodb_fast_shutdown、修复权限、替换MASTER_HOST为真实IP。

备份时必须加 --slave-info 才能正确恢复为新从库

跨机扩容本质是搭建新从库，不是单纯还原数据。不加 --slave-info，xtrabackup 不会记录主库的 binlog 位置和 GTID（如果启用），恢复后无法执行 CHANGE MASTER TO。

常见错误现象：恢复完直接启动 mysql，发现 SHOW SLAVE STATUS 报错 Error 2006 (HY000): MySQL server has gone away 或复制线程一直 Connecting —— 实际是没配对 binlog 坐标。

• 必须在备份命令末尾显式加上 --slave-info（即使源库不是从库，只要目标要当从库就得加）
• 如果源库启用了 GTID，额外加 --gtid，否则恢复后 gtid_executed 为空，START SLAVE 会失败
• 备份完成后检查 xtrabackup_slave_info 文件是否生成，里面应有 CHANGE MASTER TO 完整语句

恢复前要清空目标机 datadir 并禁用 innodb_fast_shutdown

物理备份还原不是“覆盖文件”那么简单。InnoDB 在 shutdown 时若 innodb_fast_shutdown=1（默认值），会跳过 buffer pool 刷盘和 log 清理，导致恢复时 innobackupex --apply-log 报错 ibdata1 size mismatch 或崩溃。

使用场景：目标机是全新部署或重用旧实例；路径如 /var/lib/mysql 必须完全干净，不能残留旧 ib_logfile* 或未 purge 的 undo 表空间。

• 停掉目标 MySQL：systemctl stop mysqld
• 清空 datadir（比如 rm -rf /var/lib/mysql/*），别只删库目录留日志文件
• 临时设置 innodb_fast_shutdown = 0（写进 /etc/my.cnf 的 [mysqld] 段），再启动一次 MySQL 让它彻底 clean shutdown，然后立刻停掉
• 最后才执行 xtrabackup --copy-back

--copy-back 后必须用 chown mysql:mysql 且不能跳过 --rsync 阶段

权限错乱是跨机还原最常被忽略的问题。xtrabackup 在目标机执行 --copy-back 时，所有文件属主是执行命令的用户（比如 root），而 mysqld 进程以 mysql 用户运行，一启动就报错 Can't open the mysql.plugin table 或 InnoDB: Operating system error number 13（权限拒绝）。

性能影响：如果跳过 --rsync 直接用 --copy-back，大库（>100GB）会因单线程拷贝变慢 3–5 倍；--rsync 支持多线程增量同步，适合首次还原后反复调试。

• 还原后立即执行：chown -R mysql:mysql /var/lib/mysql（路径按实际 datadir 调整）
• 确认 my.cnf 中 user = mysql 已配置，且 socket、pid-file 路径属主也是 mysql
• 首次还原建议加 --rsync 参数：xtrabackup --copy-back --rsync，避免卡在大 ibdata1 拷贝上

启动后 CHANGE MASTER TO 的 host 必须填主库真实 IP，不能用 localhost

这是新手最容易栽的坑。恢复完以为只要执行备份里 xtrabackup_slave_info 的语句就行，但里面写的 MASTER_HOST='localhost' 是源库视角的配置，迁到新机器后必须手动改成主库可访问的 IP 或域名，否则 START SLAVE 会连自己（新从库本机）而不是主库。

错误现象：SHOW SLAVE STATUSG 显示 Seconds_Behind_Master: NULL，Slave_IO_Running: Connecting，错误日志反复打印 error connecting to master 'repl@localhost:3306'。

• 打开 xtrabackup_slave_info，把 MASTER_HOST 替换为实际主库 IP，例如 192.168.1.100
• 如果主库开了防火墙，确认目标机 3306 端口能通：telnet 192.168.1.100 3306
• 主库上检查复制账号权限：select host FROM mysql.user WHERE user='repl';，确保包含新从库 IP

备份链路里最脆弱的一环从来不是 xtrabackup 本身，而是 binlog 坐标传递和权限上下文切换——这两个点漏掉任何一个，扩容就卡在 START SLAVE 之前。