MySQL 启用 binlog 需执行 SHOW VARIABLES LIKE 'log_bin'; 返回 ON；若为 OFF，需在 my.cnf 中配置 log-bin = mysql-bin 并重启服务。
如何确认 MySQL 是否已启用 binlog
没开 binlog，后续所有增量备份都无从谈起。先看关键配置是否生效，而不是直接去翻日志文件。
- 执行
SHOW VARIABLES LIKE 'log_bin';，返回ON才算真正启用；OFF或空值说明没开 -
log_bin变量名本身不带路径，但实际日志文件名由log_bin_basename决定，常见默认是mysql-bin - 如果看到
log_bin是OFF，检查my.cnf（或my.ini）里有没有漏掉log-bin = mysql-bin，注意不是log_bin（ini 文件中等号左边不能有下划线） - 改完配置必须重启 MySQL，仅
SET GLOBAL无法开启 binlog
怎么安全导出 binlog 并保留原始点位信息
用 mysqlbinlog 直接读取正在写入的 binlog 文件风险很高——可能读到半个事务、或被 purge 掉一半。必须配合 FLUSH LOGS 和明确起止位置。
- 先执行
FLUSH LOGS;，让 MySQL 切换到新 binlog 文件，确保当前活跃文件只读不写 - 用
SHOW MASTER STATUS;记下当前File和Position（即“点位”），这是后续恢复的基准 - 导出时用
--read-from-remote-server+--host方式最稳妥，避免本地文件锁问题；若必须读本地文件，加--skip-gtids --base64-output=DECODE-ROWS避免格式错乱 - 不要用
cp直接拷贝mysql-bin.000001这类文件——它们可能被 purge 或正在写入，内容不一致
如何基于 binlog 恢复到指定时间点或事务点
恢复不是简单回放全部 binlog，而是精准截断：起点是你上次全量备份的点位，终点是你想停下的时间或 position。
- 先用
mysqlbinlog --start-datetime="2024-05-20 10:30:00" --stop-datetime="2024-05-20 11:15:00" mysql-bin.000002 | mysql -u root -p按时间恢复（注意时区一致性） - 更精确的做法是用
--start-position和--stop-position，比如从12345到67890；这两个数字来自SHOW BINLOG EVENTS IN 'mysql-bin.000002'查询结果 - 遇到
ERROR 1062 (23000): Duplicate entry不要慌——说明该语句已在全量备份里存在，加--force参数跳过，或提前用grep -v "INSERT INTO xxx VALUES"过滤掉重复插入 - 如果开启了 GTID，必须用
--exclude-gtids或--include-gtids显式控制，否则mysqlbinlog默认会报错退出
为什么备份后还要定期 purge binlog？怎么设才不丢数据
binlog 不 purge 会撑爆磁盘，但 purge 过头会导致无法恢复——关键在和全备周期对齐。
- 设
expire_logs_days = 7前，确认你的全量备份至少每 5 天跑一次；否则某次全备后第 6 天发生故障，binlog 已被删光，只能回退到上上周 - 更可靠的方式是用
PURGE BINARY LOGS TO 'mysql-bin.000010';手动清理，把TO后面的文件名设为「最后一次全备对应 SHOW MASTER STATUS 的 File」的前一个文件 - 监控
SHOW BINARY LOGS;输出的文件数量和最大 file size，单个 binlog 超过 1GB 时要考虑调小max_binlog_size（但别设太小，频繁切换也影响性能） - 注意：
RESET MASTER会清空所有 binlog 并重置序列号，生产环境严禁使用，它不区分新旧，直接归零
点位管理真正的复杂点不在命令怎么写，而在于每次全备后必须人工记录并核对 File 和 Position，且要和 purge 策略、监控告警联动——少记一次，就可能失去某个时间窗口的恢复能力。
