MySQL增量备份必须依赖binlog且以全量备份为前提，需确认log_bin=ON、binlog_format=ROW、server-id唯一非0；全备时用--master-data=2记录binlog位置；增量用mysqlbinlog按时间或位置提取，限定--database，恢复须严格按全量→增量顺序执行。
MySQL 增量备份不是独立操作，它必须依赖 binlog，且只能在完成一次全量备份后才有意义。没有全量备份打底，增量备份文件本身无法单独恢复数据。
确认 binlog 是否启用并配置正确
增量备份的底层支撑是 MySQL 的二进制日志，mysqlbinlog 工具读取的就是它。如果 binlog 未开启或格式不对，增量备份直接失效。
- 检查是否启用：
SHOW VARIABLES LIKE 'log_bin';—— 返回ON才有效 - 确认格式为
ROW：SHOW VARIABLES LIKE 'binlog_format';——STATEMENT格式在部分场景（如非确定性函数）下无法精确还原，生产环境必须设为ROW - 验证
server_id唯一且非 0：SHOW VARIABLES LIKE 'server_id';—— 主从或备份链依赖此值，重复会导致mysqlbinlog解析失败 - 配置项应写入
/etc/my.cnf或/etc/mysql/my.cnf中的[mysqld]段落：log-bin = mysql-bin<br>binlog-format = ROW<br>server-id = 1
改完需重启 MySQL
执行全量备份并记录 binlog 位置
增量备份不是“从现在开始记”，而是“从上次全备结束那一刻开始记”。因此全量备份时必须锁定并记录当时的 binlog 文件名和偏移量，否则后续增量无法衔接。
- 推荐用
mysqldump+--single-transaction --master-data=2组合：mysqldump -u root -p --single-transaction --master-data=2 client > /backup/client-full-$(date +%F).sql -
--master-data=2会在导出 SQL 头部插入类似CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000003', MASTER_LOG_POS=154;的注释，这就是关键位置标记 - 不要手动执行
FLUSH LOGS后再备份——这会提前切换binlog，导致位置不连续；让--master-data自动处理更可靠 - 物理冷备也可用，但必须在
FLUSH TABLES WITH READ LOCK;+SHOW MASTER STATUS;后立即打包，且锁要保持到 tar 结束
用 mysqlbinlog 提取指定时间段的增量变更
mysqlbinlog 是唯一能解析并重放 binlog 的官方工具，它不生成新备份文件，而是把二进制日志转成可执行的 SQL 流。注意：它不能“只导出 INSERT”，而是完整还原所有 DML/DDL 操作。
- 按时间范围提取（推荐，易理解）：
mysqlbinlog --start-datetime="2026-06-09 02:00:00" --stop-datetime="2026-06-10 01:59:59" /var/lib/mysql/mysql-bin.000003 /var/lib/mysql/mysql-bin.000004 > /backup/incr-20260609.sql - 按位置点提取（更精确，适合脚本化）：
mysqlbinlog --start-position=154 --stop-position=123456 /var/lib/mysql/mysql-bin.000003 > /backup/incr-pos.sql - 务必加
--database=client限定库，避免其他库的变更污染目标恢复集 - 不要直接用
mysqlbinlog输出重定向到数据库（如| mysql -u...），先保存为 SQL 文件，人工校验内容后再导入——误删语句可能被完整重放
恢复时顺序不能错：全量 → 增量 →（可选）新 binlog 截断点
恢复不是“把所有增量 SQL 一股脑执行”，而是一条严格的时间线回放。跳过某份增量、颠倒顺序、或在增量中间插入新写入，都会导致数据不一致甚至主键冲突。
- 先恢复全量：
mysql -u root -p client - 再按时间先后顺序依次导入增量文件：
mysql -u root -p client - 如果要恢复到某个精确时间点（比如误删前 1 秒），需用
mysqlbinlog提取到该时刻，并在 SQL 中手动去掉最后一行误操作（如DROP TABLE） - 恢复完成后，立刻执行
FLUSH LOGS;切换新binlog，避免旧日志被循环覆盖，也便于下次增量起点明确
真正容易被忽略的不是命令怎么写，而是 binlog 生命周期管理：日志文件默认不会自动清理，磁盘爆满会导致 MySQL 写入阻塞；但删早了又会让增量链断裂。必须用 EXPIRE_LOGS_DAYS 或 PURGE BINARY LOGS 配合备份策略定期清理，且确保待清理的日志已全部归档——这是线上环境最常出问题的一环。
