SQL GTID 模式下 binlog_gtid_simple_recovery 的恢复加速实践

binlog_gtid_simple_recovery=on能加速gtid恢复，因其仅读取最老和最新两个binlog的previous-gtids事件并结合gtid_executed表推算，避免全量扫描；但要求binlog完整、gtid_executed表一致且mysql≥5.7.7。

binlog_gtid_simple_recovery 为什么能加速 GTID 恢复？

MySQL 在实例重启时，需要重新扫描 binlog 文件来确定 gtid_executed 的最终值。默认行为（binlog_gtid_simple_recovery=OFF）会从第一个 binlog 扫到最新一个，耗时随 binlog 文件数量线性增长——几十个文件就可能卡住几秒甚至更久。

设为 ON 后，MySQL 只读取**最老和最新两个 binlog 文件**的 Previous-GTIDs Event，再结合 mysql.gtid_executed 表或 gtid_executed 系统变量做推算，跳过中间所有文件。本质是用元数据换时间，前提是 binlog 文件没被手动删改、gtid_executed 表未损坏。

• binlog_gtid_simple_recovery=ON 要求 MySQL 5.7.7+，且必须配合 gtid_mode=ON 和 enforce_gtid_consistency=ON
• 如果启用了 log_bin_trust_function_creators=OFF 或存在不安全的函数写 binlog，可能导致 Previous-GTIDs 不连续，此时开启该参数反而会算错 gtid_executed
• 线上建议先在从库验证：修改后重启，检查 select @@global.gtid_executed; 是否与关闭时一致；再比对 SHOW MASTER STATUS; 中的 Executed_Gtid_Set

如何安全启用 binlog_gtid_simple_recovery=ON

不能直接改配置重启——GTID 模式下，若 mysql.gtid_executed 表内容与实际 binlog 不一致，MySQL 会拒绝启动并报错 Error 3098 (HY000): The table mysql.gtid_executed is not ready to be used。

关键动作是让 gtid_executed 表和 binlog 状态对齐。常见做法是执行一次 RESET MASTER，但这会清空所有 binlog，仅适用于刚初始化或可接受主从重建的场景。

• 生产环境更稳妥的方式是：先停写，执行 FLUSH LOGS，再用 mysqlbinlog --base64-output=DECODE-ROWS -v 检查最新 binlog 结尾是否有完整的 Previous-GTIDs event
• 确认无误后，在 my.cnf 中添加 binlog_gtid_simple_recovery=ON，然后重启
• 重启失败时，错误日志里大概率出现 Found invalid Previous-GTIDs log event 或 GTID set mismatch，此时需临时关掉该参数，再人工修复 mysql.gtid_executed 表（如用 INSERT INTO mysql.gtid_executed ... SELECT 补全缺失区间）

哪些情况会让 binlog_gtid_simple_recovery 失效或变慢

它不是银弹。当 MySQL 发现无法通过首尾两个 binlog 推出准确结果时，会自动 fallback 到完整扫描模式，日志里会出现 Warning: binlog_gtid_simple_recovery was disabled because of missing or invalid Previous-GTIDs event。

典型诱因包括：

• 手动用 rm 删除过中间 binlog 文件（哪怕只是 rm -f mysql-bin.000012），导致 Previous-GTIDs 链断裂
• 使用了 mysqlbinlog --flashback 或第三方工具解析 binlog 后重放，但没保留 Previous-GTIDs event
• expire_logs_days 自动清理后，最老 binlog 被删，而 mysql.gtid_executed 表里记录的 GTID 区间横跨已删除文件
• 升级前是 MySQL 5.6（无 GTID），升级后没做 RESET MASTER 就直接启 GTID，旧 binlog 里压根没有 Previous-GTIDs event

验证是否真生效：看启动日志和耗时

别只信配置文件。MySQL 启动后，第一件事是查错误日志里有没有 Recovery completed 行，以及它前面是否带 using simple GTID recovery 字样。

如果看到的是 Using full GTID recovery，说明没走加速路径——这时候得回头检查上面提到的链路完整性问题。

• 对比开启前后重启耗时：用 systemctl restart mysqld && journalctl -u mysqld -n 50 | grep "Recovery completed"，看时间戳差
• 注意 mysqld 进程状态：如果卡在 Starting MySQL 超过 10 秒，大概率正在扫 binlog，立刻 kill -SIGUSR1 触发堆栈输出，确认是不是卡在 Log_event::read_log_event
• 线上灰度建议选低峰期从库：改完配置后，用 SELECT SLEEP(1); 确保连接正常，再观察 SHOW SLAVE STATUSG 中 Retrieved_Gtid_Set 和 Executed_Gtid_Set 是否持续更新

真正难的不是开开关，而是确保那两个 binlog 文件里的 Previous-GTIDs 是连得上的。断点一旦存在，加速就成摆设，还可能掩盖更深层的 binlog 管理问题。