全量备份必须加--single-transaction和--master-data=2：前者保证InnoDB一致性，后者记录binlog位点以支持增量恢复；GTID模式需加--set-gtid-purged=ON；binlog恢复需准确定位position或时间点，并注意日志保留与环境验证。
全量备份用 mysqldump 但必须加这几个关键参数
不加 --single-transaction 和 --master-data=2 的全量备份，基本没法做可靠增量恢复。前者保证 InnoDB 表一致性（避免锁表），后者把备份时刻的 binlog 文件名和位置写进 dump 文件里，这是后续接 binlog 的唯一锚点。
常见错误是只导出数据不记录位点，或者用了 --lock-all-tables 导致业务卡死。生产环境务必用：
mysqldump --single-transaction --master-data=2 --all-databases > full_backup.sql
-
--single-transaction仅对 InnoDB 有效；MyISAM 表仍需--lock-all-tables，但建议别混用引擎 -
--master-data=2输出的是带注释的 CHANGE MASTER 语句，恢复前得手动去掉注释或用sed -n '/CHANGE MASTER/,/;/p'提取 - 如果实例启用了 GTID，改用
--set-gtid-purged=ON，否则恢复时可能报错GTID_PURGED cannot be changed
从 mysql-bin.000001 开始追 binlog 做增量恢复
binlog 不是日志文件列表，而是按序号滚动的二进制流。所谓“从某点开始”，本质是定位到某个 position 或某个 GTID set。全量备份里的 CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=12345 就是起点。
用 mysqlbinlog 解析并重放：
mysqlbinlog --start-position=12345 mysql-bin.000001 | mysql -u root -p
- 别直接
cat mysql-bin.000001—— 这是二进制格式，会乱码甚至损坏终端 - 如果跨多个 binlog 文件（比如恢复到最新），用
--start-datetime="2024-05-01 10:00:00"比记 position 更稳妥，但要注意时区是否和 MySQL server 一致 - 遇到
ERROR 1062 (23000): Duplicate entry？说明已存在相同主键——要么加--skip-gtids（GTID 模式下），要么先清空目标库再恢复
mysqldump 备份后 binlog 被 purge 导致断点丢失
MySQL 默认不会无限保留 binlog，expire_logs_days 或 binlog_expire_logs_seconds 到期后自动删除旧文件。如果全量备份后超过这个时间才做增量，mysql-bin.000001 可能已被删，备份里的 position 就失效了。
- 查当前 binlog 列表：
SHOW BINARY LOGS;，确认备份依赖的文件还在 - 临时延长保留时间：
SET GLOBAL binlog_expire_logs_seconds = 604800;（7天），但只是运行时生效，记得写进my.cnf - 更稳妥的做法：每次全量备份后，立刻用
FLUSH BINARY LOGS切新文件，并把新文件名记为“下一个增量起始点”
恢复时跳过误删的库或表，别硬扛 mysqlbinlog 全量重放
线上误删一个表，不需要从全量备份 + 所有 binlog 一路重放到现在。可以用 mysqlbinlog 精确提取某段操作，再过滤掉无关内容。
例如，只想恢复 user 库在 10:00–10:05 的变更：
mysqlbinlog --database=user --start-datetime="2024-05-01 10:00:00" --stop-datetime="2024-05-01 10:05:00" mysql-bin.000002 | mysql -u root -p
-
--database是“只输出指定库的事件”，不是“只解析该库的 binlog”——它仍会扫描整个文件，性能无优化 - 真正高效的方式是先用
mysqlbinlog --base64-output=DECODE-ROWS -v查看具体 event 的end_log_pos，再用--start-position/--stop-position精确定界 - 如果 binlog 格式是
ROW，恢复前确保目标库结构一致，否则INSERT INTO ... VALUES (@1,@2)会报错
最常被忽略的一点：所有恢复操作都应在从库或离线环境验证通过后再上生产。线上主库直接重放 binlog，等于把过去所有写操作再跑一遍——包括那个 DROP TABLE。
