MySQL主从复制之GTID模式介绍

GTID同步在建立复制的时候，将传统复制由人为指定binlog的pos位点改为了 MASTER_AUTO_POSITION=1 自动获取binlog的pos位点。

Enjoy GreatSQL :)

1.Mysql cluster: share-nothing,分布式节点架构的存储方案，以便于提供容错性和高性能。

需要用到mysql cluster安装包，在集群中的每一个机器上安装。

有三个关键概念：Sql节点（多个），数据节点（多个），管理节点（一个），数据节点之间采用的是同步复制来保证各节点之间的数据一致性。

同步复制：

a) Master执行提交语句时，事务被发送到slave，slave开始准备事务的提交。

b) 每个slave都要准备事务，然后向master发送OK(或ABORT)消息，表明事务已经准备好（或者无法准备该事务）。

c) Master等待所有Slave发送OK或ABORT消息，如果Master收到所有 Slave的OK消息，它就会向所有Slave发送提交消息，告诉Slave提交该事务；如果 Master收到来自任何一个Slave的ABORT消息，它就向所有 Slave发送ABORT消息，告诉Slave去中止事务。

e) 每个Slave等待来自Master的OK或ABORT消息。如果Slave收到提交请求，它们就会提交事务，并向Master发送事务已提交 的确认；如果Slave收到取消请求,它们就会撤销所有改变并释放所占有的资源，从而中止事务，然后向Masterv送事务已中止的确认。

f) Master收到来自所有Slave的确认后，就会报告该事务被提交（或中止），然后继续进行下一个事务处理。

由于同步复制一共需要4次消息传递，故mysql  cluster的数据更新速度比单机mysql要慢。所以mysql cluster要求运行在千兆以上的局域网内，节点可以采用双网卡，节点组之间采用直连方式。

2.主从（Master-Slave）: 主从机器上安装mysql community（普通版）就可以。

主从之间是通过mysql的replication来保证数据的一致性。相对mysql cluster的数据同步方式来讲是异步的。

Replication：主节点要开启binlog，设置一个唯一的服务器id（局域网内唯一）；从节点设置服务器id，binlog记录了master上的所有 *** 作，会被复制到从节点的relaylog并在从节点上回放。

GTID 对于单源复制还是很方便，但是对于多源复制，这里就需要特别注意：

要先停止所有的从库 stop slave

然后清理本机所有的 GTID，reset master

再进行 SET @@GLOBAL.GTID_PURGED='xxxxx' gtid 设置

这里就会引入一个问题，如果是级联复制的情况下，reset master 的时候，会把本机的所有 binlog 清理掉。如果下一级的从库存在延迟，没有及时的把 binlog 传过去，就会造成主从中断，这里我们该怎么避免呢？看这里：

做 reset master 的时候，先看看下游的从库是否存在很大的延迟。如果存在，把当前的 binlog 和后面未同步的 binlog 全部备份下；

待添加好从库的 channel 后，再把未同步的 binlog 文件手动拷贝到 binlog 目录；

更新下 mysql-bin.index 文件；

注意，binlog 不能同名，需要手动更新下文件。

---