mysql中基于filename pos复制和GTID复制模式的

一.简单介绍一下主从复制模式

1.同步怎样进行的?

master用户写入数据，生成event记到binary log中.

slave接收master上传来的binlog，然后按顺序应用，重现master上的用户操作。

2.靠什么同步的?

主从复制,默认是通过pos复制(postion),就是说在日志文档里,将用户进行的每一项操作都进行编号(pos),每一个event都有一个起始编号,一个终止编号,我们在配置主从复制时从节点时,要输入master的log_pos值就是这个原因,要求它从哪个pos开始同步数据库里的数据,这也是传统复制技术,

MySQL5.6增加了GTID复制,GTID就是类似于pos的一个作用,不过它是整个mysql复制架构全局通用的,就是说在这整个mysql冗余架构中,它们的日志文件里事件的GTID值是一致的.

3.从节点怎么知道要从哪块进行同步?

上面也说了,一开始是自己设置的从主节点的日志文件里的pos开始复制,以后就自己去读取上一次同步到哪一块,接着同步.

二.传统复制和DTID模式复制区别

在mysql的复制架构中（一主多从的架构中），如果master crash，如何让某一个salve竞选为new master?下面分别对基于filename pos和GTID两种复制模式下进行分析对比

分析如下：

使用filename+pos位置点

        当 Master宕机 后，一个 Slave 被 提升为New Master ，如果需要继续维持复制关系，就需要把另外两个Slave的 CHANGE MASTER 指向 New Master ；那问题来了，原来Slave是指向 Master 的 Filename_M + Position_M 的位置，现在要指向 New Master 上新的 Filename_N + Position_N 的位置，这两个位置是比较难对应起来的 ; 此时两个Slave要继续复制（CHANGE MASTER）会比较麻烦。

• 使用GTID

         和上面一样的场景，两个Slave需要重新指向 New Master ，由于 使用了GTID ，目前 Slave-2获取到的日志对应的 GTID=G_2 ，Slave-3 获取到的日志对应的 GTID=G_3 ;此时 New Master 上是存在 G_2 和 G_3 （ 通过选举出来的，获取的日志应该是最多的 ），那两个Slave就可以直接使用 G_2和G_3 这两个GTID，通过指向 New Master 接着继续复制；