mysql5.6的gtid功能_mysql 5.6 的新特性：GTID 复制

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  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 [email protected]‘192.168.%.%‘ identified by ‘[email protected]‘

# 从库上执行

change master to

master_host=‘192.168.1.60‘,

master_user=‘repl‘,

master_password=‘[email protected]‘,

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  ; # 清空master.info ,relay-log.info 的内容

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

4.start slave ;

gtid模式下的主从不同步

GTIDS的故障切换

本文出自 “SQLServer MySQL” 博客，谢绝转载！

原文：http://dwchaoyue.blog.51cto.com/2826417/1559764