新特性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(检查一下)
上一篇:内网环境NTP服务及时间同步(CentOS6.x)配置和部署


下一篇:第68节:Java中的MYSQL运用从小白到大牛