一.简单介绍一下主从复制模式
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 接着继续复制；
