17370845950

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_20250501_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，增量恢复时可能因表结构变化失败，建议全备后尽快做一次校验
• 生产环境建议配合 备份校验 + 定期恢复演练，光有备份文件不等于能成功还原