mysql原理 ~ GTID集合

GTID
1 简介
   就是全局事务ID(global transaction identifier )
2 构成
   uuid+transaction_id
3 格式
  7a07cd08-ac1b-11e2-9fcf-0010184e9e08:1-N
  解析两个binlog 分析记录格式
  binlog1
  #171228 11:14:33 server id 71 end_log_pos 120 CRC32 0x0d525104 Start: binlog v 4, server v 5.6.21-r5436-log created 171228 11:14:33
  # at 120
  #171228 11:14:33 server id 71 end_log_pos 231 CRC32 0xa8f24351 Previous-GTIDs
  # UUID:1-798040662,
  # UUID:1-518
  binlog2
  # at 4
  #180102 10:35:05 server id 71 end_log_pos 120 CRC32 0x8f29d513 Start: binlog v 4, server v 5.6.21-r5436-log created 180102 10:35:05
  # at 120
  #180102 10:35:05 server id 71 end_log_pos 231 CRC32 0x64845fb6 Previous-GTIDs
  # UUID:1-799601894,
  # UUID:1-518
  Previous-GTIDs 可以看出,每个binlog开头都记录着从GTID开启到这个binlog之前的binlog文件GTID执行事务的总和
  注意:

 1 即便binlog文件被清理,也不会影响这个值

 2 每个文件尤其只有开头一个 3 使用这个值，可以便于快速判断GTID是否位于当前binlog文件中
  相关变量解析
      gtid_executed 状态:不可以手动更改 内容:已经执行过的事务GTID总和,RESET MASTER会清空此值
      gtid_purged 状态:可以手动更改 内容:已经被删除的binlog的事务GTID,它是GTID_EXECUTED的子集
      gtid_owned 状态:不可以手动更改 内容:当前执行的事务GTID
      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文件。
    mysql 5.7.6后默认为真 属于优化参数
    gtid_executed_compression_period 状态:可以手动更改 内容:进行压缩,减少空间占用,默认值为1000，表示每执行1000个事务后进行一次压缩

4 mysql 5.6开启GTID
  gtid-mode = ON
  enforce-gtid-consistency=1
  log-slave-updates=1
  binlog_format=row
  注意点
  1 mysql5.6只能重启才能使GTID生效
5 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同步

xtarbackup如何利用GTID搭建从库
 1 xtarbackup备份(在其中一个从库中)
 2 xtarbackup --apply-log and copy-back
 3 察看info信息
 xtarbackup_info
 4 手动purge
 reset master;
 清除gtid_executed表信息;
 SET GLOBAL gtid_purged='UUID-transationid'
4 进行同步
 change master to auto_position=1
5 start slave
GTID 主从相关
Retrieved_Gtid_Set 接收到的GTID事务 注意接收到的GTID事务有可能不一致
Executed_Gtid_Set 已经执行的GTID事务包括自然同步和手动purge两部分
GTID主从不一致情况
如何跳过错误
stop slave;
set gtid_next="冲突的GTID号";
begin;commit;
set gtid_next="AUTOMATIC";
start slave;
补充
1. 假设现在我们要找GTID=$A，那么MySQL的扫描顺序为： 从最后一个binlog开始扫描（即：bin.004）
2. bin.004的Previous-GTIDs=1-120，如果$A=140 > Previous-GTIDs,那么肯定在bin.004中
3. bin.004的Previous-GTIDs=1-120，如果$A=88 包含在Previous-GTIDs中,那么继续对比上一个binlog文件 bin.003,然后再循环前面2个步骤，直到找到为止
MHA架构
mha0.56支持5.6以上的GTID自动切换,日志会自动生成change语句

GTID 本身的限制