生产环境全量备份应选Percona XtraBackup而非mysqldump，因其支持物理热备、无锁、增量快照；而mysqldump单线程锁表，仅适合小库或逻辑导出。
MySQL 全量备份用 mysqldump 还是 xtrabackup？
生产环境强烈建议用 Percona XtraBackup 做全量备份，mysqldump 仅适合小库或逻辑导出场景。原因很实际：mysqldump 是单线程、锁表（即使加 --single-transaction 也依赖事务隔离级别和长事务）、备份大库极慢且影响业务；而 xtrabackup 支持物理热备、无锁、增量快照、压缩与流式备份。
实操建议：
- 确认 MySQL 使用
InnoDB引擎（xtrabackup不支持纯MyISAM热备） - 安装对应版本的
percona-xtrabackup-80（MySQL 8.0 用 80 版本，5.7 用 24 版本） - 备份命令示例：
xtrabackup --backup --target-dir=/backup/full_$(date +%F_%H%M%S) --user=backup_user --password=xxx
- 执行前确保
backup_user有RELOAD, PROCESS, LOCK TABLES, REPLICATION CLIENT权限
MySQL 差异备份（增量备份）必须基于上一次全量或增量
xtrabackup 没有“差异备份”概念，只有“增量备份”，但它实际效果等价于差异：每次只记录从指定 LSN（日志序列号）之后的数据页变更。关键点在于——你不能随便挑一个时间点做“差异”，必须明确指定 --incremental-basedir 指向上次全量或上次增量的目录。
常见错误现象：
- 误把两个不同全量基础的增量合并，恢复时直接报错
Log sequence number check failed - 增量备份后没保留
xtrabackup_checkpoints文件，导致后续无法判断 LSN 起点 - 用
mysqldump+binlog模拟“差异”，但没校验binlog是否开启、格式是否为ROW、是否跳过 DDL 导致恢复失败
正确做法：
- 第一次增量：
xtrabackup --backup --incremental --target-dir=/backup/inc1 --incremental-basedir=/backup/full_2024-06-01_100000 --user=u --password=p
- 第二次增量（基于第一次增量）：
xtrabackup --backup --incremental --target-dir=/backup/inc2 --incremental-basedir=/backup/inc1 --user=u --password=p
- 每次备份后检查
/backup/xxx/xtrabackup_checkpoints中的to_lsn，它是下一次--incremental-basedir的依据
恢复时必须按顺序 apply 全量 + 所有增量，且不能跳步
物理备份恢复不是“拷回去就能用”。xtrabackup 的恢复分三步：prepare（合并日志、回滚未提交事务）、copy-back（拷贝到数据目录）、chown 启动。其中 --apply-log-only 是关键开关——除最后一次 prepare 外，所有中间步骤都必须加它，否则会把未提交事务前滚，破坏一致性。
Word报告自动生成神器。自动生成专业Word文档报告，支持模板填充、目录生成、表格/图表插入、页眉页脚、多级标题、样式主题、批量邮件合并。当用户需要生成Word报告、创建合同文档、批量生成通知/证书、填充Word模板、制作商业计划书时触发。
典型流程：
- 准备全量：
xtrabackup --prepare --apply-log-only --target-dir=/backup/full_2024-06-01_100000
- 合并第一次增量：
xtrabackup --prepare --apply-log-only --target-dir=/backup/full_2024-06-01_100000 --incremental-dir=/backup/inc1
- 合并第二次增量（最后一次，不加
--apply-log-only）：xtrabackup --prepare --target-dir=/backup/full_2024-06-01_100000 --incremental-dir=/backup/inc2
- 停止 MySQL，清空
datadir，执行：xtrabackup --copy-back --target-dir=/backup/full_2024-06-01_100000
漏掉 --apply-log-only 或顺序颠倒，会导致 mysqld 启动失败，报错如 Tablespace is not found 或 InnoDB: Trying to access page number ... in space 0。
binlog 是差异备份链条里最容易被忽略的一环
即使你用 xtrabackup 做了全量+增量，如果恢复后没重放 binlog，就只能回到最后一次增量的时间点，中间的 DML 全丢。真正的 RPO（恢复点目标）保障靠的是“物理备份 + binlog 流式追平”。
操作要点：
- 全量备份时记下
binlog位置：mysql -e "SHOW MASTER STATUS\G" > /backup/full_2024-06-01_100000/binlog_pos.txt
- 增量备份也要记录对应
binlog位点（通过mysqlbinlog --base64-output=decode-rows -v查找最近的GTID或position） - 恢复完物理备份后，用
mysqlbinlog从全量备份位点开始重放，直到故障前一秒：mysqlbinlog --skip-gtids --include-gtids='...' /var/lib/mysql-bin.000001 | mysql -u root -p
- 若开启 GTID，优先用
--include-gtids，避免 position 错位；否则必须严格按binlog文件顺序 + position 追加
没做这一步，所谓“差异备份”只是心理安慰——你根本不知道丢了最后几分钟的数据。
