必须先开启binlog，否则无法实现增量备份；需配置log-bin、server-id、expire_logs_days等参数并重启mysql，全量备份须用--flush-logs和--master-data=2确保定位点，增量则靠flush-logs后mv归档已关闭的binlog文件。
必须先开 binlog，否则增量无从谈起
MySQL 的“实时日志备份”本质就是二进制日志（binlog）的归档，不是 MySQL 自带的“增量备份功能”，而是靠 binlog 记录所有写操作来实现。如果 my.cnf 里没启用 log-bin，后面所有脚本、定时任务都白搭。
确认方式：mysql -e "show variables like 'log_bin';" 返回 ON 才算生效。
-
log-bin=/var/log/mysql/binlog—— 路径建议用绝对路径，且确保mysql用户有写权限 -
server-id=100—— 主从或后续恢复时必须唯一，单机也别设为 1（避免和默认冲突） -
expire_logs_days=7—— 控制自动清理天数，不设可能撑爆磁盘 - 别加
binlog-do-db或binlog-ignore-db—— 容易漏库，全量备份 + 全量 binlog 最稳妥
改完重启 mysqld，检查 ls /var/log/mysql/binlog.* 是否生成新文件。
全量备份脚本要带 --flush-logs 和 --master-data=2
单纯用 mysqldump 导出 SQL 不够，必须让备份文件里明确记录“这个全备截止到哪个 binlog 文件和位置”，否则恢复时找不到起点。
关键参数组合缺一不可：
-
--flush-logs：强制滚动当前binlog，保证备份后产生的新操作全在新日志里 -
--master-data=2：在导出 SQL 开头插入CHANGE MASTER TO MASTER_LOG_FILE='...', MASTER_LOG_POS=...注释行 -
--single-transaction：对 InnoDB 表做一致性快照，不锁表 -
--routines --triggers --events：否则存储过程、事件等元数据会丢失
示例命令片段：mysqldump --defaults-extra-file=/etc/mysql/backup.cnf --all-databases --single-transaction --routines --triggers --events --flush-logs --master-data=2 | gzip > /backup/full_$(date +%Y%m%d_%H%M%S).sql.gz
注意：--defaults-extra-file 指向一个仅含账号密码的配置文件（如 [client] user=backup_user password=xxx），避免密码泄露到进程列表。
增量备份 = 定期 mysqladmin flush-logs + 归档旧 binlog 文件
所谓“实时日志备份”，实际就是把已关闭的 binlog 文件（比如 binlog.000001）拷走存起来。不能直接复制正在写的文件（binlog.000002），会损坏。
标准做法是两步原子操作：
- 执行
mysqladmin --defaults-extra-file=/etc/mysql/backup.cnf flush-logs—— 关闭当前日志，创建新编号日志 - 立即
mv /var/log/mysql/binlog.000001 /backup/incr/（原名保留）—— 只搬刚被关闭的那个
不要用 cp + rm，因为 rm 后再 cp 可能漏掉中间写入；也不要 rsync 正在写的文件。脚本里务必用 mv，它在同分区下是原子重命名。
补充建议：
- 增量脚本运行频率取决于 RPO（比如每小时一次）
- binlog 文件本身不压缩，但归档后可用 gzip 压缩节省空间
- 检查 ls -lt /var/log/mysql/binlog.* | head -n 5 确认滚动是否正常
恢复时最容易错的是 binlog 应用顺序和起始位置
全量恢复完，接着应用 binlog 时，必须严格按时间顺序，且第一个 binlog 要从全备记录的 MASTER_LOG_POS 开始，而不是从头跑。
典型错误：
- 直接
mysqlbinlog binlog.000001 | mysql—— 会重放全备之前的操作，导致主键冲突或数据重复 - 跳过某个
binlog—— 链断裂，恢复到中间状态 - 用错
--start-position或--stop-datetime参数，范围不对
正确做法：
先解压全备：zcat full_20260612_020000.sql.gz | mysql
再查该文件里注释：grep "CHANGE MASTER TO" full_20260612_020000.sql → 得到 MASTER_LOG_FILE='binlog.000005', MASTER_LOG_POS=12345
然后：mysqlbinlog --start-position=12345 /backup/incr/binlog.000005 | mysql
再按序追加后续文件：mysqlbinlog /backup/incr/binlog.000006 | mysql ……
真正麻烦的点不在备份，而在恢复验证——你得知道哪条语句出错了、有没有跨事务边界截断、GTID 模式下是否要跳过事务。这些细节不提前测，线上出事就来不及了。
