MySQL主从复制之基于GTID及多线程

一、Mysql 5.6 复制管理工具
官方下载：http://dev.mysql.com/downloads/tools/utilities/#downloads
mysqlreplicate 快速启动复制
mysqlrplcheck 快速检查复制环境
mysqlrplshow 显示复制拓扑
mysqlfailover 故障转移
mysqlrpladmim 管理工具
二、GTID详解
MySQL 5.6 的新特性之一，是加入了全局事务 ID (GTID) 来强化数据库的主备一致性，故障恢复，以及容错能力。
官方文档：http://dev.mysql.com/doc/refman/5.6/en/replication-gtids.html
GTID（Global Transaction Identifier）称为全局事务标示符，是由mysql服务器自动管理的在原始master上提交事务时被创建。GTID需要在全局的主-备拓扑结构中保持唯一性，每一个 GTID 代表一个数据库事务。GTID由两部分组成： GTID = source_id：transaction_id
source_id： 用于标示源服务器，用server_uuid来表示，在首次启动时 MySQL 会调用 generate_server_uuid() 自动生成一个 server_uuid，并且保存到MySQL数据目录下auto.cnf中，MySQL 5.6 用 128 位的 server_uuid 代替了原本的 32 位 server_id 的大部分功能，全局唯一的 server_uuid 的一个好处是：可以解决由 server_id 配置冲突带来的 MySQL 主备复制的异常终止（BUG #33815?）在MySQL 5.6，Slave 向 Master 申请 binlog 时，会首先发送自己的 server_uuid，Master用Slave发送的server_uuid代替server_id 作为 kill_zombie_dump_threads 的参数，终止冲突或者僵死的 BINLOG_DUMP 线程。

transaction_id： 则是根据在源服务器上第几个提交的事务来确定。transaction_id 是一个从 1 开始的自增计数，表示在这个主库上执行的第 n 个事务。MySQL 会保证事务与 GTID 之间的 1 : 1 映射。
GTID的生命周期：

1. 事务在主库上执行并提交给事务分配一个GTID（由主库的uuid和该服务器上未使用的最小事务序列号），该GTID被写入到binlog中。
2. 备库读取relaylog中的GTID，并设置session级别的GTID_NEXT的值，以告诉备库下一个事务必须使用这个值
3. 备库检查该GTID是否已经被其使用并记录到他自己的binlog中。slave需要担保之前的事务没有使用这个gtid，也要担保此时已读取GTID，但未提交的事务也不能使用这个GTID.
4. 由于GTID_NEXT非空，slave不会去生成一个新的GTID，而是使用从主库获得的GTID。这可以保证在一个复制拓扑中的同一个事务GTID不变。

由于GTID在全局的唯一性，通过GTID，可以在自动切换时对一些复杂的复制拓扑很方便的提升新主库及新备库，例如通过指向特定的GTID来确定新备库复制坐标。当然，使用GTID也有一些限制：

1. 事务中的更新包含非事务性存储引擎，这可能导致多个GTID分配给同一个事务。
2. create table…select语句不被支持，因为该语句会被拆分成create table 和insert两个事务，并且这个两个事务被分配了同一个GTID，这会导致insert被备库忽略掉。
3. 不支持CREATE/DROP临时表操作

可以看到，支持GTID的复制对一些语句都有一些限制，M