新特性GTID

什么是GTID

每提交一个事务，当前的执行过程都会拿到一个唯一的标识符，此标识符不仅对其源mysql 实列是唯一的而在给定的复制环境中的所有mysql 实列也是唯一的，所哟的事务与其GTID 之间都是唯一对应的。 同样的GTID不能被执行两次，如果有同样的GTID，会自动被skip掉。

GTID组成

GTID = SOURCEID:SEQUENCEID SOURCEID 是服务器的唯一标识($datadir/auto.cnf 中存储)，通常是服务器的serviceuuid SEQUENCEID:SequenceNumber 是MySQL 内部的一个事物编号，一个MySQL 不会重复的顺序号（保证服务器内唯一）

5.7开启GTID

gtid_mode=ON(必选)
enforce-gtid-consistency（必选）
log_bin=ON（可选）--高可用切换，最好设置ON
log-slave-updates=ON（可选）--高可用切换，最好设置ON

gtid_mode的几个参数的设置

 OFF：不产生GTID，Slave 只接受不带GTID 的事物

 OFF_PERMISSIVE 不产生GTID,Slave 接受不带GTID 事物也接受带GTID的事物

 ON_PERMISSIVE  产生GTID，Slave 接受不带GTID事物也接受带GTID的事物

 ON 产生GTID，SLAVE 只接受带GTID的事物

GTID 的限制：

1. 由于GTID 的复制是依赖事务的，所以使用GTID 时，有些MySQL 特性不支持，如果事务混合多个存储引擎时候，会产生多个GTID。
2. 主从库的表引擎不一致，会导致数据比一致，如果从库的引擎不一致，会导致数据不一致 基于GTID 模式复制，
3. 不支持 create table .... select 语句。因为使用基于行模式的复制，该语句实际上被记录为两个单独的事件，一个是创建表，另 外一个将原来表的数据插入到刚刚创建的新表中 3 不支持create_temporary table 和drop temporary table。
4. sql_slave_skip_counter 不支持

不推荐在GTID 模式的实例上进行mysql_upgrade 原因： mysqlupgrade 的过程要创建 或修改系统表（非实物引擎），所以不建议在开启GTID 模式的实列上使用带有--write-binlog 选项的mysqlupdate

GTID的应用：

1.搭建主从（复制账号已经授予，并且GTID 已经开启）

第一种 master 运行不久，所有的binlog 保存完整，针对这种情况下，可以使用类似上面的方法搭建。 利用以上的方法搭建，简单快捷。 缺点是如果 Binlog 相对比较多，slave 同步时间相对较长，可能导致网络压力过大。

change master to master_host=192.168.5.100,master_port=3306, master_user='czg'\
master_password='123456',master_auto_position=1;

第二种 当数据量比较大，可能不适合第一种方法，或者我们最原始的binlog 日志已经删除，无法从头开始获取所有的的GTID信息，那么需要从master上获取数据相应的gtid 范围，然后在slave 上设置(gtid_purged) 的方式来跳过这些GTID，最后通过CHANGE MASTER 的方式来搭建主从。

具体的方式如下： GTID 添加从库有两种方法： 1 如果你的master所有的gtid 安装slave后，直接change master 到master 原来是直接从naster 所有的gtid并执行 优点是简单， 缺点是如果binlog 比较太多，数据完全同步需要的时间会很长， 并且master一开始就启用了GTID，适合那些新建不久的数据库。 2: master 或者其他slave的备份搭建的新的slave 原理:获取master的数据和这些数据对应的GTID 范围，然后通过在slave设置@@GLOBAL GTID_PURGED 从而跳过备份包含的 GTID 范围然后通过在slave设置。 优点：操作是可以避免第一种方案的不足 缺点相对比较复杂。适合较大的数据集的情况

具体的方法如下： -- MySQLdumper：在备份时候需要指定 --master-data -- 导出的语句中包括 set @@GLBAL.GTID_PURGED

使用MySQLdumper备份的方式 第一步：在备份时候需要指定 --master-data=2 导出的语句中包括 set @@GLBAL.GTID_PURGED='XXXXXXa:1'; 第二步：恢复的时候先在slave上执行一个reset master； 第三部：导入数据后做change master to

Percona xtrabackup （具体怎么备份参照xbackup 部分）Xtrbackup_binloginfo 包含了GTID的信息 - 在做从库恢复后，需要手工设置，set global gtidpurged='XXXXXXa:1'; - 恢复后 执行change master to

2.跳过错误的方法：

stop slave
set gtid_next='d787d787-bb44-11e6-9019-000c29276043：7';
begin;commit;
set gtid_next='automatic';
show master status（检查一下）