想了想还是专门开了一节来总结这个问题:
5.7.6 以下中默认
simplified_binlog_gtid_recovery=flase
5.7.6 以上中默认
binlog_gtid_simple_recovery=true
默认值就是最合理的设置
因为参数名更改了所以下面统称 simple_recovery 来代替
一 Gtid 关闭
simple_recovery=flase
5.7.6 以下: 这种方式一定得到正确的 Gtid 集合
重启 MySQL 需要扫描全部的 BINLOG 来获得正确的 GTID 集合
purge binlog
或者超过参数 expire_logs_days 参数设置不触发全 BINLOG 扫描, 由上层函数控制因为不支持在线的 GTID 更改
5.7.6 以上: 这种方式一定得到正确的 Gtid 集合
重启 MySQL 扫描全部的 BINLOG
purge binlog
或者超过参数 expire_logs_days 参数设置触发全 BINLOG 扫描
simple_recovery=true
5.7.6 以下: 这种情况可能得不到正确的 GTID 集合
重启 Mysql 不扫描全部的 BINLOG, 只扫描第一个和最后一个 BINLOG
purge binlog
或者超过参数 expire_logs_days 参数设置不触发全 BINLOG 扫描, 由上层函数控制
5.7.6 以上: 由于有每个 BINLOG 都有 Previous gtid Event 的支持能够得到正确的 GTID 集合
重启 Mysql 不扫描全部的 BINLOG, 只扫描第一个和最后一个 BINLOG
purge binlog
或者超过参数 expire_logs_days 参数设置不触发全 BINLOG 扫描, 只扫描第一个和最后一个 BINLOG
二 Gtid 打开
simple_recovery=flase
5.7.6 以下: 这种方式一定得到正确的 GTID 集合
重启 MySQL 不扫描全部的 BINLOG, 如果是中途打开 GTID, 重启任然需要扫描多个 BINLOG 因为需要找到 Previous gtid Event
purge binlog 或者超过参数 expire_logs_days 参数设置不触发全 BINLOG 扫描, 如果是中途打开 GTID 重启, 任然需要扫描多个 BINLOG 因为需要找到 Previous gtid Event
5.7.6 以上: 这种方式一定得到正确的 GTID 集合
重启 Mysql 不扫秒全部的 BINLOG, 如果是中途打开 GTID 重启任然需要扫描多个 BINLOG 因为需要找到 GTID EVENT
purge binlog
或者超过参数 expire_logs_days 参数设置不触发全 BINLOG 扫描, 如果是中途打开 GTID 重启任然需要扫描多个 BINLOG 因为需要找到 GTID EVENT
simple_recovery=true
5.7.6 以下: 这种情况可能得不到正确的 GTID 集合
重启 Mysql 不扫描全部的 BINLOG, 只扫描第一个和最后一个 BINLOG
purge binlog
或者超过参数 expire_logs_days 参数设置不扫描全部 GTID, 只扫描第一个和最后一个 BINLOG
5.7.6 以上: 由于有每个 BINLOG 都有 Previous gtid Event 的支持能够得到正确的 GTID 集合
重启 Mysql 不扫描全部的 BINLOG, 只扫描第一个和最后一个 BINLOG
purge binlog
或者超过参数 expire_logs_days 参数设置不触发全 BINLOG 扫描, 只扫描第一个和最后一个 BINLOG
三本节总结
5.7.6 以下保持默认设置 simplified_binlog_gtid_recovery=flase, 但是这会导致过多的 BINLOG 扫描, 况且 5.6 没有 mysql.gtid_executed 的支持, 从库必须开启 log_slave_updates, 这会带来性能影响所以还是少用 GTID
5.7.6 以上由于对每个 BINLOG 都有 Previous gtid Event 的支持 binlog_gtid_simple_recovery=true 是合理的设置, BINLOG 扫描非常的快因为只是第一个和最后一个 BINLOG 文件而已
可以看到 Gtid 也越来越成熟了这部分的逻辑在函 MYSQL_BIN_LOG::init_gtid_sets 中前文已经提到过, 这里就不看代码了
此外在 5.7 的官方文档中对 binlog_gtid_simple_recovery=true 有如下警告的描述:
- If this option is enabled, gtid_executed and gtid_purged may be
- initialized incorrectly in the following situations:
- The newest binary log was generated by MySQL 5.7.5 or older, and
- gtid_mode was ON for some binary logs but OFF for the newest binary log.
- A SET GTID_PURGED statement was issued on a MySQL version
- prior to 5.7.7, and the binary log that was active at the time of the SET
- GTID_PURGED has not yet been purged.
- If an incorrect GTID set is computed in either situation, it will remain incorrect
- even if the server is later restarted, regardless of the value of this option.
如果将参数设置为 true 可能在老版本中得不到正确的 GTID 集合, 也是前面讨论的
学习完本节至少能够学习到:
binlog_gtid_simple_recovery/simplified_binlog_gtid_recovery
是如何影响 BINLOG 文件的扫描的的
5.7.6 以下应该如何设置
5.7.6 以上应该如何设置
来源: https://yq.aliyun.com/articles/530324