mysql全量+增量备份能跑起来的前提是binlog必须开启、server-id必须设为非零唯一值、binlog_format必须为row，三者缺一不可；否则增量部分直接失效。
MySQL全量+增量备份能跑起来，前提是binlog必须开、server-id必须设、格式必须是ROW——缺一不可。其他配置再花哨，这三项没配对，增量部分直接失效。
确认 binlog 已启用且参数合规
增量依赖binlog，但光有log-bin不够，三个关键点必须同时满足：
-
log-bin=mysql-bin：路径和前缀要明确，不能只写log-bin（会默认用主机名，导致后续mysqlbinlog找不到文件） -
server-id=1：值必须是非0整数，且在集群中唯一；设为0或留空，binlog会静默关闭 -
binlog_format=ROW：STATEMENT模式下某些操作（如UUID()、NOW()）无法精确重放，恢复可能出错
验证命令：SHOW VARIABLES LIKE 'log_bin';返回ON，再查SELECT @@binlog_format;确认是ROW。
全量备份必须带 --master-data=2 和 --single-transaction
不加这两个参数，增量就断链。常见错误是只导出SQL却没记录位点，或锁表导致备份期间业务中断：
-
--master-data=2：在备份文件开头写入CHANGE MASTER TO语句，含File和Position，这是后续增量定位的唯一依据 -
--single-transaction：对InnoDB生效，保证备份一致性；MyISAM表仍会锁，若混用引擎，需改用--lock-all-tables - 别漏
--flush-logs：强制生成新binlog文件，让增量从干净起点开始，避免混入旧日志
典型命令：mysqldump -uroot -p --all-databases --single-transaction --master-data=2 --flush-logs > /backup/full_$(date +%Y%m%d).sql
增量备份不是“定时拷贝 binlog”，而是按位点/时间切片
直接cp /var/lib/mysql/mysql-bin.000003看似省事，但实际恢复时极易出错——你不知道这个文件里哪些事件属于全量之后，哪些是之前残留的：
- 推荐方式：用
mysqlbinlog按时间或位置提取，例如mysqlbinlog --start-datetime="2026-08-09 10:00:00" /var/lib/mysql/mysql-bin.000003 > inc_0910.sql - 更稳妥做法：全量备份后立即执行
SHOW MASTER STATUS;记下File和Position，增量从该点开始读取 - 注意
expire_logs_days设置：若设太小（如1），旧binlog被自动清理，中间增量链就断了
恢复时顺序和权限常被忽略
恢复失败多数不是语法问题，而是环境细节没对齐：
- 恢复全量前，必须停库或确保无写入；否则新数据会覆盖备份中的旧状态
- 导入全量SQL时，
mysql客户端要加-f（force）参数，跳过因重复建库/表导致的报错 - 执行
mysqlbinlog | mysql时，目标库用户需有REPLICATION CLIENT权限，否则mysqlbinlog无法读取binlog元信息 - 跨版本恢复（如5.7→8.0）慎用逻辑备份：系统表结构变更可能导致
mysql_upgrade失败
真正麻烦的从来不是命令本身，而是binlog文件权限不对、SELinux拦截mysqlbinlog读取、或备份路径磁盘满导致mysqldump静默截断——这些不会报错，但恢复出来是残缺数据。
