mysql之 MySQL 主从基于 GTID 复制原理概述

一、 什么是GTID （ Global transaction identifiers ）：

MySQL-5.6.2开始支持，MySQL-5.6.10后完善，GTID 分成两部分，一部分是服务的UUid,UUID保存在mysql数据目录的auto.cnf文件中,

这是一个非常重要的文件，不能删除，这一部分是不会变的。另外一部分就是事务ID了，随着事务的增加，值一次递增,如下图

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

| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |

| binlog.000029 | 23556 | | | 724afcc2-29d6-11e4-9902-000c290c0121:1-362 |

GTID:724afcc2-29d6-11e4-9902-000c290c0121:1-362

UUID:724afcc2-29d6-11e4-9902-000c290c0121

transactionId:1-362

在整个复制架构中GTID 是不变化的,即使在多个连环主从中也不会变。

例如：ServerA --->ServerB ---->ServerC 

GTID从在ServerA ,ServerB,ServerC 中都是一样的。

二、 GTID的工作原理：

1、master更新数据时，会在事务前产生GTID，一同记录到binlog日志中。

2、slave端的i/o 线程将变更的binlog，写入到本地的relay log中。

3、sql线程从relay log中获取GTID，然后对比slave端的binlog是否有记录。

4、如果有记录，说明该GTID的事务已经执行，slave会忽略。

5、如果没有记录，slave就会从relay log中执行该GTID的事务，并记录到binlog。

6、在解析过程中会判断是否有主键，如果没有就用二级索引，如果没有就用全部扫描。

三、 GTID的优点：

1.一个事务对应一个唯一ID，一个GTID在一个服务器上只会执行一次

2.GTID是用来代替传统复制的方法，GTID复制与普通复制模式的最大不同就是不需要指定二进制文件名和位置

3.减少手工干预和降低服务故障时间，当主机挂了之后通过软件从众多的备机中提升一台备机为主机

那么GTID复制是怎么实现自动同步，自动对应位置的呢？

例如：ServerC <-----ServerA ----> ServerB 

主机ServerA 

备机:ServerB,ServerC

当主机ServerA 挂了之后 ，此时ServerB执行完了所有从ServerA 传过来的事务，

ServerC 延时一点。这个时候需要把 ServerB 提升为主机 ，Server C 继续为备机。

当ServerC 链接ServerC 之后,首先在自己的二进制文件中找到从ServerA 传过来的最新的GTID，

然后将这个GTID 发送到ServerB ,ServerB 获得这个GTID之后,就开始从这个GTID的下一个GTID

开始发送事务给ServerC。这种自我寻找复制位置的模式减少事务丢失的可能性以及故障恢复的时间。

四、 GTID的限制：

1.不支持非事务引擎

2.不支持create table ... select 语句复制(主库直接报错)

原理：（ 会生成两个sql，一个是DDL创建表SQL，一个是insert into 插入数据的sql。

由于DDL会导致自动提交，所以这个sql至少需要两个GTID，但是GTID模式下，只能给这个sql生成一个GTID ）

3.不允许一个SQL同时更新一个事务引擎表和非事务引擎表

4.在一个复制组中，必须要求统一开启GTID或者是关闭GTID

5.开启GTID需要重启（5.7除外）

6.开启GTID后，就不再使用原来的传统复制方式

7.对于create temporary table 和 drop temporary table语句不支持

8.不支持sql_slave_skip_counter

文章可以转载，必须以链接形式标明出处。

本文转自 张冲andy 博客园博客，原文链接：  http://www.cnblogs.com/andy6/p/6979590.html ，如需转载请自行联系原作者