mysql5.7如何实现增量备份_基于LSN序列号的增量备份策略-mysql教程-PHP中文网

MySQL 5.7原生不支持LSN增量备份，必须用XtraBackup；mysqldump是逻辑备份，不感知LSN，无法识别页级变更；mysqlbinlog基于binlog事件，粒度为事务/行，非数据页LSN，仅支持PITR而非物理增量。

mysql5.7如何实现增量备份_基于lsn序列号的增量备份策略

MySQL 5.7 原生不支持基于 LSN 的增量备份 —— 必须用 xtrabackup（或已废弃的 innobackupex），mysqldump 和 mysqlbinlog 都不走 LSN 路线。

为什么 mysqldump 不行

mysqldump 是逻辑备份工具，它读取表数据并生成 SQL 语句，完全不感知 InnoDB 的 LSN。即使加了 --single-transaction，它也只是靠 MVCC 快照保证一致性，和数据页的物理修改时间无关。所以它无法判断“哪些页自上次备份后被改过”——这是 LSN 增量的核心前提。

执行 mysqldump 时看不到任何 LSN 相关参数或输出
它无法跳过未修改的数据页，备份体积始终是全量级
恢复后需重放所有 SQL，不能跳过已存在的页

为什么 mysqlbinlog 也不算 LSN 增量

mysqlbinlog 解析的是二进制日志（binlog），记录的是 SQL 语句或行变更事件（取决于 binlog_format），不是数据页级别的物理变更。它的粒度是事务/语句/行，不是 InnoDB 数据页的 LSN。

binlog 没有 LSN 字段，只有 position 和 gtid
它能做时间点恢复（PITR），但不是“只备份被修改过的页”，而是“备份所有变更事件”
如果只靠 binlog，你必须从上一个全备开始重放，中间任意 binlog 文件损坏就断链

真正基于 LSN 的增量：xtrabackup 工作流

xtrabackup（MySQL 5.7 推荐用 percona-xtrabackup-24）才是唯一利用 InnoDB LSN 实现物理增量的工具。它通过比对每个数据页头部的 LSN 与基准备份的 to_lsn，只拷贝 LSN 更大的页。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

全量备份后，xtrabackup 在 xtrabackup_checkpoints 文件中记录 to_lsn
增量备份命令必须指定 --incremental-basedir=/path/to/full/，它会读该目录下的 to_lsn 作为起点
增量备份结果目录里也有自己的 xtrabackup_checkpoints，含新的 to_lsn，供下一次增量使用
恢复时必须按顺序：全量 → 增量1 → 增量2 → … → 应用 redo log → 准备（--apply-log）→ 恢复

示例关键命令：

xtrabackup --user=backup_user --password='xxx' --backup --target-dir=/backup/full/
xtrabackup --user=backup_user --password='xxx' --backup --incremental --incremental-basedir=/backup/full/ --target-dir=/backup/inc1/
xtrabackup --user=backup_user --password='xxx' --backup --incremental --incremental-basedir=/backup/inc1/ --target-dir=/backup/inc2/

容易被忽略的三个硬性前提

LSN 增量不是配好命令就能跑通，以下三点任一缺失都会导致备份失败或恢复不一致：

innodb_file_per_table=ON：必须启用，否则系统表空间（ibdata1）无法按页隔离，xtrabackup 无法精确识别哪些页被修改
备份用户要有 REPLICATION CLIENT 权限：用于获取当前 LSN 和 binlog 位置，缺它会在 --backup 阶段报错 Failed to get LSN
全量备份必须先 --prepare 过（哪怕只是空跑）：否则其 xtrabackup_checkpoints 中的 to_lsn 可能为 0 或无效值，导致后续增量误判为“无变更”

LSN 增量的本质是页级物理快照链，不是日志流拼接——理解这点，才能避开把 binlog 当成 LSN 增量的常见误操作。