percona xtrabackup才是真正的物理备份工具，mysqldump仅为逻辑备份；xtrabackup通过直接拷贝innodb数据文件并记录binlog位点（需--slave-info或--dump-slave=2），实现主从初始化的物理一致性快照，而mysqldump无法保留物理结构且不自带精确位点信息。
mysqldump 是逻辑备份，Percona XtraBackup 才是物理备份。如果你看到教程里用 mysqldump 初始化主从，那它根本不是物理备份——别被标题误导。
物理备份初始化主从的核心目的只有一个：在从库上还原出和主库**完全一致、带 binlog 位点信息**的快照，然后让从库从那个精确位置开始拉取日志。这比逻辑导入快得多，尤其对大库（100GB+）几乎是唯一可行方案。
为什么不用 mysqldump 做物理备份初始化？
mysqldump 导出的是 SQL 文本，导入是逐条执行 INSERT/CREATE，过程慢、锁表久、无法保留原始数据页结构；它也不自带 binlog position，你得手动 SHOW MASTER STATUS 配合 --master-data=2 才能拿到位点——但这仍是逻辑层快照，不是物理一致性点。
而 Percona XtraBackup 直接拷贝 InnoDB 数据文件（ibdata1、.ibd），同时记录 binlog 文件名和 position（或 GTID），整个过程对主库只加短暂 FLUSH TABLES WITH READ LOCK，几乎不影响业务。
备份时必须加 --slave-info 或 --dump-slave=2
这个参数决定你能不能跳过手动查 SHOW MASTER STATUS。它会让备份生成一个 xtrabackup_slave_info 文件，里面包含：CHANGE MASTER TO 所需的完整语句，包括 MASTER_LOG_FILE 和 MASTER_LOG_POS（或 MASTER_AUTO_POSITION=1）。
- 如果主库已开启 GTID，用
--dump-slave=2（XtraBackup 8.0+ 推荐） - 如果主库用传统 binlog position，用
--slave-info - 千万别漏——否则你得自己连主库执行
SHOW MASTER STATUS，且必须确保备份期间没新写入，否则位点就错
还原后必须 --apply-log + --copy-back，顺序不能反
备份出来的目录只是“冷拷贝”，InnoDB 事务未提交的部分还在 redo log 里。必须先 xtrabackup --apply-log 回滚未提交事务、前滚已提交但未刷盘的变更，才能得到一致性快照。
-
--apply-log只读操作，可离线做，不碰原库数据目录 -
--copy-back是覆盖式还原，目标目录必须为空，且 MySQL 进程必须停止 - 还原后记得改权限：
chown -R mysql:mysql /var/lib/mysql，否则启动失败报Can't open the mysql.plugin table
从库配置里 relay-log 路径要和 backup 里的实际路径匹配
XtraBackup 备份中继日志（relay log）默认不备份，但 --slave-info 会记录当前 SQL 线程执行到哪个 relay log 文件。如果从库 my.cnf 中 relay-log 路径和备份时不一样（比如备份时是 /var/lib/mysql/mysql-relay-bin，但你配成了 /data/mysql/relay-bin），START SLAVE 会报错 Could not find first log file name in binary log index file。
- 最稳妥做法：还原后直接用备份里生成的
xtrabackup_slave_info内容执行CHANGE MASTER TO - 不要手敲，复制粘贴，尤其注意单引号、分号、空格
- 确认
relay-log路径与my.cnf一致，或干脆删掉该配置项，用默认值
--apply-log 是否成功完成？还原后 mysql 用户权限有没有被覆盖？这些地方一错，Slave_IO_Running: No 就卡死在那里，查日志只会看到模糊的 “connection refused” 或 “log file not found”。
