mysql5.6的gtid功能_MySQL5.6 新特性之GTID

1.mysql5.6在复制方面的新特性：

(1).支持多线程复制:事实上是针对每个database开启相应的独立线程,即每个库有一个单独的(sql thread).针对这样的改进,如果我们想实现多线程复制,无疑要对现存的数据库结构进行重新设计,分库分表.对于压力都集中在个别database的,多线程并发复制特性就没有意义.

(2).支持启用GTID,在配置主从复制,传统的方式里,你需要找到binlog和POS点,然后change master to指向.在mysql5.6里,无须再知道binlog和POS点,只需要知道master的IP/端口/账号密码即可,因为同步复制是自动的,mysql通过内部机制GTID自动找点同步.

(3).基于Row复制只保存改变的列,大大节省Disk Space/Newwork resources和Memory usage.

(4).支持把Master 和Slave的相关信息记录在Table中,原来是记录在文件里,记录在表里,增强可用性

(5).支持延迟复制

注：

关于 server_uuid 的解释：服务器身份ID。在第一次启动Mysql时，会自动生成一个server_uuid并写入到数据目录下auto.cnf文件里，官方不建议修改。

[root@client102 ~]# cat /home/mysql/data/auto.cnf

[auto]

server-uuid=14be3ddd-4e92-11e3-8335-000c299c1b31

关于GTID的解释： 全局事务标识符。当开启这个功能时，每次事务提交都会在binlog里生成一个唯一的标示符，它由server_uuid和事务ID组成。首次提交的事务ID为1，第二次为2，第三次为3，依次类推。

2.mysql主从复制的原理图：[此原理没有变化]

3. MySQL5.6开始主从复制有两种方式：基于日志(binlog)[基于日志的搭建,上篇文章已搭建过];基于GTID(全局事务标识符)

本次配置是基于GTID(全局事务标识符),但其也有劣势,实际生产环境中,暂时不推荐使用

基于GTID(全局事务标识符)的局限性：

(1).GTID同步复制是基于事务。所以Myisam表不支持，这可能导致多个GTID分配给同一个事务。(5.6.9版本已经修改，支持修改Myisam表)

(2).gtid_mode和enforce-gtid-consistency=true 必须同时使用，不同时使用，启动Mysql报错。

(3).无法修改myisam表的数据，会提示"Updates to non-transactional tables are forbidden when disable-gtid-unsafe-statements"   --> 这个我测试5.6.14,是可以正常修改数据,所以这点劣势待定,大家可以分享测试结果

(4).不支持对临时表操作：CREATE TEMPORARY TABLE、DROP TEMPORARY TABLE     --> 这个劣势,5.6.14也可以做,大家可以测试,留言反馈，最近，在5.6.19上测试，是不可以操作，以前5.6.14可能测试有误，这里补充一下。

(5).不支持CREATE TABLE ... SELECT语句。因为该语句会被拆分成create table 和insert两个事务，并且这个两个事务被分配了同一个GTID，这会导致insert被备库忽略掉[这条语句在游戏数据库用的比较多，通常用来将大表分成小表]

=======================================================================================

概念：

GTID即全局事务ID(global transaction identifier)，GTID实际上是由UUID+TID组成的。其中UUID是一个MySQL实例的唯一标识。TID代表了该实例上已经提交的事务数量，并且随着事务提交单调递增，所以GTID能够保证每个MySQL实例事务的执行(不会重复执行同一个事务，并且会补全没有执行的事务)。下面是一个GTID的具体形式：

4e659069-3cd8-11e5-9a49-001c4270714e:1-77

更具体的说明见官方说明。

GTID意义：

引入GTID的意义是什么？

1)因为清楚了GTID的格式，所以通过UUID可以知道这个事务在哪个实例上提交的。

2)通过GUID可以极方便的进行复制结构上的故障转移，新主设置。很好的解决了下面这个图(图来自高性能MySQL第10章)的问题。

上面图的意思是：Server1(Master)崩溃，根据从上show slave status获得Master_log_File/Read_Master_Log_Pos的值，Server2(Slave)已经跟上了主，Server3(Slave)没有跟上主。这时要是把Server2提升为主，Server3变成Server2的从。这时在Server3上执行change的时候需要做一些计算，这里就不做说明了，具体的说明见高性能MySQL第10章，相对来说是比较麻烦的。

这个问题在5.6的GTID出现后，就显得非常的简单。由于同一事务的GTID在所有节点上的值一致，那么根据Server3当前停止点的GTID就能定位到Server2上的GTID。甚至由于MASTER_AUTO_POSITION功能的出现，我们都不需要知道GTID的具体值，直接使用CHANGE MASTER TO MASTER_HOST='xxx'， MASTER_AUTO_POSITION命令就可以直接完成failover的工作。

原理：

从服务器连接到主服务器之后，把自己执行过的GTID(Executed_Gtid_Set) 、获取到的GTID(Retrieved_Gtid_Set)发给主服务器，主服务器把从服务器缺少的GTID及对应的transactions发过去补全即可。当主服务器挂掉的时候，找出同步最成功的那台从服务器，直接把它提升为主即可。如果硬要指定某一台不是最新的从服务器提升为主， 先change到同步最成功的那台从服务器， 等把GTID全部补全了，就可以把它提升为主了。

测试：

1)复制环境的搭建：具体的复制搭建的步骤可以在网上搜索

因为支持GTID，所以5.6多了几个参数：

mysql> show variables like '%gtid%';

+---------------------------------+-----------+

| Variable_name | Value |

+---------------------------------+-----------+

| binlog_gtid_simple_recovery | OFF |

| enforce_gtid_consistency | OFF |

| gtid_deployment_step | OFF |

| gtid_executed | |

| gtid_mode | OFF |

| gtid_next | AUTOMATIC |

| gtid_owned | |

| gtid_purged | |

| simplified_binlog_gtid_recovery | OFF |

+---------------------------------+-----------+