MySQL增量备份依赖binlog记录变更操作，需开启log_bin、设置唯一server_id和推荐ROW格式；流程分position（记录文件名+位置）和GTID（记录事务集合）两种模式；须确保binlog保留时长覆盖全备间隔，禁用手动删除，DDL可能影响恢复，需校验与演练。
MySQL 增量备份不是直接“备份变化的数据”，而是依赖二进制日志（binlog）记录所有数据变更操作，通过保存 binlog 文件或其中的指定位置（position / GTID），在全量备份基础上重放后续操作来还原到某一时刻的状态。
增量备份的前提：开启并配置 binlog
没有 binlog，MySQL 就无法知道“哪些语句执行过”，也就谈不上增量。必须确认以下配置已生效：
-
log_bin = ON（或指定路径如
/var/lib/mysql/mysql-bin） - server_id 唯一且非 0（主从和 GTID 必需）
- 建议设置 binlog_format = ROW（更安全、可精确还原，避免语句级不确定性）
- 可选但推荐：expire_logs_days = 7（自动清理旧 binlog，防磁盘占满）
典型增量备份流程（基于 position）
适用于大多数场景，逻辑清晰、兼容性好：
- 先做一次全量备份（如用
mysqldump --single-transaction --master-data=2或mysqlbackup），备份中会记录当时 binlog 文件名和 position（例如mysql-bin.000012+1984） - 备份完成后，定期（如每小时）用
mysqlbinlog截取新产生的 binlog 片段：mysqlbinlog --start-position=1984 mysql-bin.000012 > inc_20240501_1000.sql - 后续新增的 binlog 继续按文件+position 追加截取，形成多个增量文件
GTID 模式下的增量备份（更现代、易管理）
开启 gtid_mode = ON 后，每个事务有唯一 GTID（如 uuid:1-15），备份时记录当前 SELECT @@global.gtid_executed; 的值：
- 全量备份后，记下当时的 GTID 集合（如
aaaabbbb-cccc-dddd-eeee-ffffffffffff:1-100） - 恢复时，用
mysqlbinlog --include-gtids='aaaabbbb-cccc-dddd-eeee-ffffffffffff:101-200'提取对应事务 - 优势：无需关心 binlog 文件切换、position 跳变；支持多线程复制、故障切换更可靠
关键注意事项
增量备份不是“设好就不管”，几个容易出错的点要盯紧：
- binlog 必须保留足够久：如果全备是 3 天前做的，而 binlog 只保留 1 天，那中间 2 天的增量就永远丢了
-
不要手动删除 binlog 文件：必须用
PURGE BINARY LOGS或配置expire_logs_days，否则 MySQL 元数据会不一致 - DDL 语句（如 ALTER TABLE）也写入 binlog，增量恢复时可能因表结构变化失败，建议全备后尽快做一次校验
- 生产环境建议配合 备份校验 + 定期恢复演练，光有备份文件不等于能成功还原
