物理流备份是直接复制MySQL数据文件并配合binlog实时传输的物理备份方式，本质为“原样搬走运行中的数据库”，不经过SQL解析，恢复快且精度高，但要求主从版本一致、InnoDB引擎、启用innodb_file_per_table和binlog_format=ROW。
物理流备份是什么，它和逻辑备份根本不是一回事
物理流备份指直接复制 MySQL 的数据文件（如 ibd、frm）并配合 binlog 实时传输，本质是“把磁盘上正在跑的数据库原样搬走”。它不经过 SQL 解析，不依赖 mysqldump 或 mysqlpump，速度更快、恢复更准，但要求主从版本一致、存储引擎兼容（InnoDB 为主）、且必须启用 innodb_file_per_table 和 binlog_format=ROW。
常见误操作：用 mysqldump --single-transaction 生成的 SQL 文件当“物理备份”——这其实是逻辑备份，无法支撑秒级 RPO 的异地灾备。
- 物理流备份核心组件：xtrabackup（Percona）或 mysqlbackup（MySQL Enterprise Backup），二者都支持流式输出（
--stream=xbstream）+ 网络传输 - 必须开启
gtid_mode=ON，否则跨机房主从切换时位点难以对齐 - 备份过程中不能执行
ALTER TABLE ... REBUILD或DROP TABLESPACE，否则 xtrabackup 可能卡住或校验失败
如何用 xtrabackup 实现带压缩的异地流备份
流备份不是“先本地存再 rsync”，而是边备份边发往异地。关键在 --stream + ssh 或 nc 管道组合，避免中间落盘占用空间。
典型命令（主库执行）：
xtrabackup --backup \ --stream=xbstream \ --compress \ --target-dir=/tmp/backup/ \ | ssh user@dr-site-ip "xbstream -x -C /data/mysql_restore/ && xtrabackup --decompress --target-dir=/data/mysql_restore/ && xtrabackup --prepare --target-dir=/data/mysql_restore/"
注意：--prepare 必须在异地完成，不能在主库做；--decompress 和 --prepare 顺序不能颠倒，否则恢复时报错 Log block checksum mismatch。
- 压缩用
--compress（默认 qpress），不是 gzip —— xtrabackup 内置压缩器对大页更友好 - 若网络不稳定，加
--throttle=100（单位 MB/s）控速，避免夯住主库 IO - 不要用
rsync同步备份目录：xtrabackup 流备份期间文件未闭合，rsync 会复制出损坏状态
异地恢复后如何安全接入灾备链路
恢复完只是“有数据”，不代表能当从库用。必须补全 GTID、重放 binlog、跳过主键冲突，并验证复制一致性。
关键步骤：
- 启动 MySQL 前，确认
datadir下有完整xtrabackup_binlog_info文件，里面记录了备份结束时的mysql-bin.000001:12345位置 - 启动后执行
RESET MASTER，再SET GLOBAL gtid_purged = 'xxx'（值来自xtrabackup_binlog_info中的 GTID_SET） - 用
CHANGE MASTER TO ... MASTER_AUTO_POSITION = 1接入主库，别用MASTER_LOG_FILE手动指定——GTID 模式下这个参数会被忽略 - 检查
SHOW SLAVE STATUS\G中Seconds_Behind_Master是否持续为 0，且Retrieved_Gtid_Set和Executed_Gtid_Set差值稳定收敛
容易被忽略的是：灾备实例的 server_id 必须与主库及其它从库全局唯一，否则复制中断后无法自动重连。
为什么不能只靠物理流备份，还得配 binlog 归档
物理流备份解决的是“某时刻全量快照”，但两次备份之间产生的变更（比如备份间隔 6 小时），只能靠 binlog 补齐。如果灾备中心网络断开超过一个备份周期，没归档的 binlog 丢失，就无法做到 RPO ≈ 0。
实操建议：
- 在主库配置
expire_logs_days = 7，同时用mysqlbinlog --read-from-remote-server定期拉取并压缩存到对象存储（如 S3、OSS） - 归档脚本必须校验
mysqlbinlog --base64-output=decode-rows -v输出是否可解析，防止因磁盘满导致 binlog 写半截 - 灾备恢复时，先还原最近一次物理备份，再按时间顺序重放归档 binlog，最后才接实时复制
最常踩的坑：误以为 xtrabackup 自带 binlog 传输功能，其实它只负责备份时刻的 binlog 位置，不传后续日志——这部分得自己搭管道或用第三方工具（如 Maxwell、Canal）补位。
