主从复制不是增量备份，因其不可离线、不可校验、不可隔离恢复；可靠增量备份需结合全量备份与主库 binlog 归档，并严格配置 server-id、log-bin 路径、expire_logs_days 等参数。
支持，但主从复制本身不是备份手段，而是增量数据同步机制；真正的增量备份依赖 binlog + 定期归档，主从只是辅助验证和快速切换的冗余通道。
为什么主从 ≠ 增量备份
主从复制实时拉取并重放 binlog，看起来像“持续增量”，但它不具备备份的三个基本属性：可离线、可校验、可隔离恢复。一旦主库误删库、从库也会跟着执行（除非启用了 read_only=1 且未被绕过），更无法回退到某时间点——它只是另一份运行中的副本。
- 主从延迟或中断时，从库数据已落后，不能当作“最新备份”直接使用
- 从库没做
FLUSH LOGS或PURGE BINLOGS管理，binlog文件可能被自动清理，导致无法还原中间状态 - 没有备份元数据（如
CHANGE MASTER TO记录的位置点），你甚至不知道该从哪个mysql-bin.0000xx的哪个POS开始恢复
真正能用于增量备份的组合方案
必须把主从架构里的 binlog 抽出来单独归档，配合定期全量备份，才构成可靠增量策略：
- 全量备份用
mysqldump --single-transaction --flush-logs --master-data=2（InnoDB）或xtrabackup --backup，生成带MASTER_LOG_FILE和MASTER_LOG_POS的快照 - 每天定时拷贝新增的
binlog文件（如cp /var/lib/mysql/mysql-bin.* /backup/binlogs/），并用mysqlbinlog --base64-output=DECODE-ROWS -v抽样检查内容是否可读 - 严禁在从库上直接
PURGE MASTER LOGS—— 从库的binlog是它自己的，不是主库的；归档应只在主库操作，且需确认所有从库已同步完毕
容易被忽略的关键配置坑
很多线上故障源于 binlog 配置不闭环，不是没开，而是开了却失效或不可用：
-
server-id必须全局唯一，主从不能重复，否则复制中断且无明确报错 -
log-bin路径目录必须由mysql用户可写，且磁盘不能和数据目录共用同一物理卷（避免 I/O 争抢或单点故障） -
expire_logs_days=7很好，但若全量备份周期是 14 天，就会导致旧 binlog 被删、增量链断裂 —— 这个值必须 ≥ 最长备份保留周期 - 使用
mysqldump --master-data=2备份后，务必检查输出 SQL 文件里是否有CHANGE MASTER TO行；若为空，说明log-bin没生效或 mysqldump 运行时没权限读取
真正落地时，最常出问题的不是技术不会用，而是 binlog 归档脚本没加锁、没校验 md5、没监控文件是否为空，结果某天发现最近三天的 mysql-bin.0000xx 全是 0 字节 —— 此时主库又刚被误 truncate，那就只能翻备份日志祈祷了。
