物理备份不一定需停库，但多数场景需停库；唯一热备方案是percona xtrabackup或mysqlbackup，通过监听redo log与拷贝脏页实现一致性，备份时加全局读锁仅阻塞写操作。
物理备份必须停库吗？
不一定，但绝大多数场景下需要停库。MySQL 的物理备份本质是直接复制数据文件（如 ibdata1、.ibd、mysql-bin.* 等），如果实例正在运行且有未刷盘的脏页、未提交事务或正在写入的 redo log，直接拷贝会导致文件状态不一致，恢复后大概率报错 Tablespace is missing for table 或启动失败。
唯一可不停机的物理备份方式是使用 mysqlbackup（MySQL Enterprise Backup）或 Percona XtraBackup —— 它们通过监听 redo log 流 + 拷贝内存中脏页的方式实现一致性热备。开源环境基本只用后者。
-
mysqld进程必须可访问，且用户需有RELOAD、PROCESS、SUPER权限 - 备份期间会加全局读锁（
FLUSH TABLES WITH READ LOCK），只阻塞写，不影响读，所以“热”是相对的 - 备份完成后会自动释放锁，但锁持有时间取决于数据量和 IO 速度
用 Percona XtraBackup 做一次完整备份
这是目前最主流、最可靠的 MySQL 物理备份方案，支持 MySQL 5.7/8.0、Percona Server、MariaDB。注意：XtraBackup 8.0+ 只兼容 MySQL 8.0，若用 MySQL 5.7 必须用 XtraBackup 2.4。
安装后执行：
xbbackup --user=root --password=xxx --backup --target-dir=/backup/full_$(date +%F)
关键点：
-
--backup表示执行备份（不是还原）；--prepare才是还原前的恢复准备步骤 -
--target-dir必须是空目录，不能是已存在的备份路径 - 默认会备份所有数据库，加
--databases="db1 db2"可指定库 - 备份过程生成
xtrabackup_binlog_info和xtrabackup_checkpoints，记录 binlog 位置和 LSN，用于后续增备或搭建从库
如何验证物理备份是否可用？
不能只看文件有没有拷出来，必须走完「恢复流程」并验证能启动、能查数据。常见误判是备份成功了，但没做 --prepare 就直接复制到 datadir 启动，结果报 InnoDB: Operating system error number 2 in a file operation。
正确验证步骤：
- 先执行
xbbackup --prepare --target-dir=/backup/full_2024-06-01（该操作不依赖 MySQL 实例） - 停止目标 MySQL：
systemctl stop mysqld - 清空原
datadir（如/var/lib/mysql），再用rsync -av /backup/full_2024-06-01/ /var/lib/mysql/ - 改权限：
chown -R mysql:mysql /var/lib/mysql - 启动：
systemctl start mysqld，观察错误日志是否有InnoDB: Starting crash recovery或ready for connections
如果启动成功，连上去执行 SELECT COUNT(*) FROM some_table，确认数据行数与备份前一致。
增量备份怎么接在全量后面？
增量备份依赖全量备份的 to_lsn 值，这个值存在 xtrabackup_checkpoints 文件里。每次增备都必须基于上一次（全量或上次增备）的 prepared 状态目录来打。
实操顺序：
- 全备后先
--prepare（此时backup_type = full-prepared） - 等一段时间后，执行增备：
xbbackup --incremental --incremental-basedir=/backup/full_2024-06-01 --target-dir=/backup/inc_2024-06-02 - 增备也必须
--prepare，但命令稍不同：xbbackup --prepare --apply-log-only --target-dir=/backup/full_2024-06-01（先合并全备），再xbbackup --prepare --apply-log-only --target-dir=/backup/full_2024-06-01 --incremental-dir=/backup/inc_2024-06-02 - 最后去掉
--apply-log-only再跑一次--prepare，得到最终可恢复的全量目录
漏掉 --apply-log-only 会导致后续增量无法合并，报错 lsn is higher than the last checkpoint。
物理备份真正难的不是执行命令，而是理解每个环节的 LSN 链路、锁行为和 prepare 时机。很多故障不是备份失败，而是跳过了验证或混淆了 prepare 阶段——比如把未 prepare 的增备目录直接当全量用了。
