mysql原理~GTID综合

1 简介
  就是全局事务ID(global transaction identifier ) 属于全局唯一
2 构成
   uuid+transaction_id
3 格式
   7a07cd08-ac1b-11e2-9fcf-0010184e9e08:1-N
    binlog SET @@SESSION.GTID_NEXT= ''
4 概念和变量解读
   1 Previous-GTIDs 可以看出,每个binlog开头都记录着从GTID开启到这个binlog之前的binlog文件GTID执行事务的总和,即便不开启GTID,也会记录
   2 gtid_executed表
    1 状态:不可以手动更改
    2 内容:已经执行过的事务GTID总和,RESET MASTER会清空此值
    3 mysql5.6记录在内存中,所以需要开启中继日志记录进行持久化(GTID_LOG_EVENT)
       mysql5.7 为一个innodb_table实现持久化 从库就不需要开启中级日志了
4 触发更改内容(适用于gtid_executed gtid_purged变量)
     1 set global gtid_purged='' 常见于搭建从库
     2 reset master 清空 executed表
    3 gtid_purged 状态:可以手动更改 内容:已经被删除的binlog的事务GTID,它是GTID_EXECUTED的子集
    4 gtid_owned 状态:不可以手动更改 内容:当前执行的事务GTID  
    5 binlog_gtid_simple_recovery 状态:可以手动更改 内容:这个选项设置为真，会提升mysql执行恢复的性能。因为这样mysql-server启动和binlog日志清理更快。该参数为真时，mysql-server只需打开最老的和最新的这2个binlog文件，gtid_purged参数的值和            gtid_executed 参数的值可以根据这些文件中的Previous_gtids_log_event 或者 Gtid_log_event计算得出。这确保了当mysql-server重启或清理binlog时，只需打开2个binlog文件。默认为真.目的是针对binlog的lost_gtid加快扫描操作
    6 gtid_executed_compression_period 状态:可以手动更改 内容:进行压缩,减少空间占用,默认值为1000，表示每执行1000个事务后进行一次压缩,针对gtid_executed表的压缩
    7 主从相关
      1 Retrieved_Gtid_Set 接收到的GTID事务 注意接收到的GTID事务有可能不一致
       2 Executed_Gtid_Set 已经执行的GTID事务包括自然同步和手动purge两部分
5 mysql 5.6开启GTID
    gtid-mode = ON
    enforce-gtid-consistency=1
    log-slave-updates=1
    binlog_format=row
6  mysql 5.7.6在线开启GTID
   主从都需要执行
   实现步骤：
   1. 所有的Server执行
      set @@global.enforce_gtid_consistency = warn; 
      特别注意： 这一步是关建的一步使用不能出现警告。
  2.所有的server上执行：
     set @@global.enforce_gtid_consistency = on;
  3.所有的Server上执行（不关心最先最后，但要执行完）：
     set @@global.gtid_mode = off_permissive;
  4. 执行：
    set @@global.gtid_mode=on_permissive; 
    实质在这一步骤生的日志都是带GTID的日志了，这个步骤号称是不关心任何节点，但从实管理上推荐在slave上先执行，然后再去master上执行。
  5. 确认传统的binlog复制完毕,该值为0
    show status like 'ongoing_anonymous_transaction_count';
    需要所有的节点都确认为0.
  6. 所有节点进行判断 show status like 'ongoing_anonymous_transaction_count'; 为零
      所有的节点也可以执行一下: flush logs; 用于切换一下日志。
  7. 所有的节点启用gtid_mode
     set @@global.gtid_mode=on
  8. 把gtid_mode = on相关配置写入配置文件
      gtid_mode=on
      enforce_gtid_consistency=on
  9. 启用Gtid的自动查找节点复制：
     stop slave;
     change master to master_auto_position=1;
     start slave;
     注意点:1 只有版本大于5.7.6的mysql才能支持在线从传统复制切换到GTID复制
                 2 关于gtid_mode选项名词说明,控制新事物产生是什么模式
                 GTID_MODE = OFF : 不产生Normal_GTID，只接受来自master的ANONYMOUS_GTID
                 GTID_MODE = OFF_PERMISSIVE : 不产生Normal_GTID，可以接受来自master的ANONYMOUS_GTID & Normal_GTID
                 GTID_MODE = ON_PERMISSIVE : 产生Normal_GTID，可以接受来自master的ANONYMOUS_GTID & Normal_GTID
                 GTID_MODE = ON : 产生Normal_GTID，只接受来自master的Normal_GTID
                 3 GTID在线切换不必考虑主从是否一致性生成GTID日志,因为并不影响同步,只有最后一步才会真正的采用GTID同步
   补充
    1 GTID和并行复制是两个东西,即便不开GTID,binlog也会包含并行复制所需要的东西
    2 跨版本开启GTID复制有可能有问题,不推荐这么玩,先用传统复制,然后在线进行切换
    3 reset master 会清空 gtid_purged gtid_executed 内容,谨慎操作
    4 mysqldump 对于GTID模式下的导出 包含两部分操作
        1 set_log_bin = 0 对于导入操作不生成本地的GTID操作
        2 手动执行set global gitd_purged = ‘ ’ 导入被删除的事务集合,更新目的库gtid_purged+gtid_executed变量
        3 如果不想导出GTID的相关信息 可以增加 --set-gtid-purged=OFF(不推荐)
        4 如果采用导出第一次搭建从库,请先执行reset master 清空GTID 相应表,防止之前遗留导致获得错误的GTID集合
   5 master_auto_position 是如何寻找位置的
        1 从库发送gtid_executed集合到master
        2 master根据从库发送的gtid_executed扫描binlog
        3 从最新binlog开始向前扫描,根据每个binlog开头的Previous-GTIDs的记录判定是否为需要记录,以此类推
        4 寻找到相应的binlog发送给salve
   6  高可用切换

      1 如果在高可用主从切换,旧从指向新主后,不用再提供binlog和postion,根据以上扫描机制就能获取最新数据
       2 记住高可用下一定要在新主应用完relay-log后进行reset master。然后新master的binlog就包含了应用旧主的binlog内容,保住旧从指向新主不会出现数据缺失导致错误的情况

       3 切换完成后旧主通过show slave status 就会发现有多个GTID记录,包含旧主和新主

转载于:https://www.cnblogs.com/danhuangpai/p/11332555.html