什么是 MySQL 增量备份，它依赖什么
MySQL 本身不提供原生的“增量备份”命令，所谓增量备份，实际是基于
binlog日志的追加式记录：只保存自上次全量备份以来所有执行过的 DML/DDL 操作。因此，启用增量备份的前提是必须开启并正确配置
binlog。
检查是否启用：
SHOW VARIABLES LIKE 'log_bin';返回
ON才有效；同时确认
binlog_format为
ROW或
MIXED（
STATEMENT在某些函数或非确定性语句下可能无法精确回放）。
server-id必须在
my.cnf中设置为非 0 值（如
server-id = 1），否则 binlog 可能被跳过写入 建议配置
expire_logs_days = 7或
binlog_expire_logs_seconds = 604800，避免日志无限堆积 binlog 文件名默认为
hostname-bin.000001形式，恢复时需准确识别起始与终止文件及位置
如何生成全量备份作为增量起点
增量备份不是独立存在的，它必须锚定在一个已知一致的全量备份上。推荐使用
mysqldump配合
--single-transaction和
--master-data=2一次性获取快照 + binlog 位置：
mysqldump --single-transaction --master-data=2 -u root -p database_name > full_backup_$(date +%F).sql
该命令会在导出 SQL 头部插入类似注释：
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000012', MASTER_LOG_POS=154;这个
MASTER_LOG_FILE和
MASTER_LOG_POS就是后续增量恢复的起点坐标。 不要用
--lock-all-tables替代
--single-transaction，前者会阻塞写入，不适合生产环境 如果数据库含 MyISAM 表，
--single-transaction无效，必须改用
--lock-all-tables并接受锁表影响 备份后立即用
mysqlbinlog --base64-output=decode-rows -v mysql-bin.000012 | tail -20确认该 pos 是否真实可读，避免因日志轮转导致位置失效
如何提取指定范围的 binlog 事件做增量恢复
恢复时，你要从全备记录的
MASTER_LOG_FILE和
MASTER_LOG_POS开始，读取到某个故障时间点或新位置为止。核心工具是
mysqlbinlog：
mysqlbinlog --start-position=154 --stop-datetime="2024-05-20 14:23:00" /var/lib/mysql/mysql-bin.000012 /var/lib/mysql/mysql-bin.000013 > incremental.sql
注意：若跨多个 binlog 文件，
--stop-datetime只对最后一个文件生效；更稳妥的是用
--stop-position或组合
--start-file/
--stop-file显式控制边界。 务必加上
--database=database_name过滤库级事件，防止误恢复其他库的操作 若 binlog 是 row 格式，加
--base64-output=decode-rows -v可读性更好，但生成的 SQL 不能直接执行，仅用于分析；真正恢复要用原始二进制解析结果 恢复前先停写或确保无新写入，否则增量 SQL 执行过程中又产生新 binlog，会导致二次混乱
恢复顺序和关键校验点
恢复必须严格按「全量 → 增量」顺序，并且增量部分要保证事务连续性。典型流程是：
mysql -u root -p database_name < full_backup_2024-05-20.sql mysql -u root -p database_name < incremental.sql
但实际中容易忽略三点：
全量恢复后，MySQL 的GTID_EXECUTED或
Executed_Gtid_Set可能与 binlog 位点不一致，若启用了 GTID，应优先用
SET GLOBAL gtid_purged = '...'清除旧 GTID 并用
CHANGE MASTER TO ... GET_MASTER_PUBLIC_KEY=1同步，而非依赖 position 增量 SQL 中若含
DROP DATABASE或
TRUNCATE，会直接破坏全量结果，需提前人工审查
incremental.sql内容 恢复完成后，运行
SELECT @@GLOBAL.GTID_EXECUTED;或
SHOW MASTER STATUS;对比预期位置，确认是否真正“追平”
binlog 是逻辑日志，不是物理快照；一次误删、一个未提交事务的回滚、甚至主从时钟偏差，都可能导致你认定的“截止时间点”其实已经越过了关键操作——所以增量恢复永远要配合业务侧的时间线交叉验证，不能只信日志位置。
