深入理解MySQL 5.7 GTID系列(七)

作者:高鹏(重庆八怪)

原文地址:

深入理解MySQL 5.7 GTID系列文章共十篇,本文为第七篇

想了想还是专门开了一节来总结这个问题:

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以上应该如何设置

推荐文章

深入理解MySQL 5.7 GTID系列(六)

深入理解MySQL 5.7 GTID系列(五)

深入理解MySQL 5.7 GTID系列(四)

深入理解MySQL 5.7 GTID系列(三)

深入理解MySQL 5.7 GTID系列(二)

深入理解MySQL 5.7 GTID系列(一)

yangyidba
我还没有学会写个人说明!
上一篇

[多图]苹果 AirPods Max 详细拆解

你也可能喜欢

评论已经被关闭。

插入图片