mysql 5.6 的新特性：

MySQL 5.6 包含了一个复制的新功能，enabling DevOps teams to reliably scale-out their MySQL infrastructure across commodity hardware,

rel="nofollow">Global Transaction Identifiers (GTIDs)功能，

为了解决以下问题：

-能够无缝的故障恢复和master与slave的切换

-能把slave指向新的master

-减少手工干预和降低服务故障时间

什么是GTID

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的复制原理。

GTID复制与普通复制模式的最大不同就是不需要指定二进制文件名和位置。

当主机挂了之后我们从众多的备机中提升一台备机为主机后，其他备机只需要执行

change master to

master_host='192.168.12.23',

master_user='repluser',

master_password='123456',

master_auto_position=1;

就可以快速实现同步(前提是新主机上有用户名repluser),传统的复制模式需要查找复制的二进制文件名

和位置，这个极为费时间，繁琐。

那么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复制搭建：

主库配置：

binlog_format = mixed

connect_timeout = 1000

expire_logs_days = 10

innodb_additional_mem_pool_size = 16M

innodb_buffer_pool_size =100M

key_buffer_size = 50M

log_output = table

master_info_repository = table

master_verify_checksum = on

max_connect_errors = 1000

max_connections = 800

relay_log_info_repository = table

skip_name_resolve = 1

slave_parallel_workers = 2

#以下几项是开启gtid的必须项，否则mysql无法启动

enforce_gtid_consistency = true

gtid_mode = on

log_slave_updates = true

log_bin = mysqllog

从库配置：

binlog_format = mixed

connect_timeout = 1000

expire_logs_days = 10

innodb_additional_mem_pool_size = 32M

innodb_buffer_pool_size = 300M

key_buffer_size = 100M

log_output = table

master_info_repository = table

master_verify_checksum = on

max_connect_errors = 1000

max_connections = 800

relay_log_info_repository = table

skip_name_resolve = 1

slave_parallel_workers = 2

replicate_wild_do_table = db_vip%.%

#以下几项是开启gtid的必须项，否则mysql无法启动

enforce_gtid_consistency = true

gtid_mode = on

log_slave_updates = true

log_bin = mysqllog

# 主库上执行创建复制用户

Grant replication slave ,replication client  on  *.* to repl@'192.168.%.%' identified by 'Toney@163.com'

# 从库上执行

change master to

master_host='192.168.1.60',

master_user='repl',

master_password='Toney@163.com',

master_auto_position=1;

# 开启复制

start slave   ;

show slave status 参数解释：

Retrieved_Gtid_Set: 724afcc2-29d6-11e4-9902-000c290c0121:1-13

Executed_Gtid_Set: 724afcc2-29d6-11e4-9902-000c290c0121:1-13,

934024ce-29db-11e4-9923-000c296cf315:1-8

Retrieved_Gtid_Set：从主库上复制过来的最新的gtid

Executed_Gtid_Set：从库执行的过的最新的gtid，这里有两个gtid，一个主库产生的，一个从库自己的

mysql> show global variables like  '%gtid%';

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

| Variable_name            | Value                                                                               |

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

| enforce_gtid_consistency | ON                                                                                  |

| gtid_executed            | 724afcc2-29d6-11e4-9902-000c290c0121:1-13,

934024ce-29db-11e4-9923-000c296cf315:1-8 |

| gtid_mode                | ON                                                                                  |

|                |                                                                                     |

| gtid_purged              |                                                                                     |

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

gtid的相关状态变量解释：

gtid_executed：GTID_EXECUTED  表示已经在该实例上执行过的事务； 执行RESET MASTER 会将该变量置空;

我们还可以通过设置GTID_NEXT执行一个空事务，来影响GTID_EXECUTED

GTID_NEXT：是SESSION级别变量，表示下一个将被使用的GTID

在内存中也维护了与GTID_PURGED， GTID_OWNED, GTID_EXECUTED相对应的全局对象gtid_state。

gtid_state中维护了三个集合，其中logged_gtids对应GTID_EXECUTED， lost_gtids对应GTID_PURGED，owned_gtids对应GTID_OWNED

gtid_mode：on 表示开始gtid模式

gtid_owned：正在执行的gtid

gtid_purged：中级日志中已经删除的gtid

gtid复制模式下主从不同步故障：

一下操作请务必在从库上执行

1.stop slave  ;

2.reset  master  ; # # 使gtid_executed 变量变为空

3.set global  gtid_purged='724afcc2-29d6-11e4-9902-000c290c0121:1-15' ;#这个gtid 是在从库上执行报错的gtid

4.start slave ;

========================2014/11/03补充=====================================================

gtid复制原理：

当从库链接主库的时候会扫描自己的二进制日志文件，找到从主库中传过来的最后一个uuid，

然后将这个uuid发送到主库，主库接收到这个uuid后，将uuid之后的uuid发送到从库，从而完成

主从同步。

在静止的生产库中按照以上的方式搭建gtid是没有问题的，但是在生产库中

是不行的，因为在刚开始的从库中，二进制日志文件中没有uuid的，默认情况下

会将主库中的所有的uuid都发送到从库(或者直接报错,从库需要的位置在主库中找不到)，这就造成主从不一致。

那么如何在初次中搭建gtid复制呢，

其实在在初次复制中，不需要搭建gtid，只需要主从两边都开启参数

enforce_gtid_consistency = true

gtid_mode = on

就行了，

在从库上执行

change master to master_host='192.168.53.63',master_port=3307,master_user='rep',

master_password='Welcome@123',master_auto_position=0,master_log_file='mysqllog.000001',master_log_pos=719;

start slave  ;

就可以开启gtid复制了,

当在整个复制架构中主库挂掉了，另外一台从库提升为主库,只需要执行

change master to master_host='192.168.53.63',master_port=3306,master_user='rep',

master_password='Welcome@123',master_auto_position=1;

当前从库链接新的主库，并且实现了无缝的数据对接,

gtid模式下的主从不同步

http://wenku.baidu.com/link?url=0hiDS4uu9pxH2erW-OX7Yv9fxdF0Y7x4dOcS7K2ZouFo4jJdr-lvuosD-mm0Btd5CHtfPLW9jQjlvFLs7Dl70cmgzsdFTScZuxH7jF1vByW

GTIDS的故障切换

http://www.topthink.com/topic/3674.html

http://www.tuicool.com/articles/NjqQju

***program/310852.html

http://blog.sina.com.cn/s/blog_53b13d95010180nf.html

http://www.it165.net/database/html/201308/4419.html