mysql传统复制(postion)与GTID原理解析

大家都知道,mysql的复制其实都是基于日志文件的,不管什么复制,都离不开日志文件的同步,那它是怎么同步的,靠什么同步的,从节点怎么知道要从哪块进行同步
以传统的主从复制为例:

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开始复制,以后就自己去读取上一次同步到哪一块,接着同步.

4:pos与GTID有什么区别?

两者都是日志文件里事件的一个标志,如果将整个mysql集群看作一个整体,pos就是局部的,GTID就是全局的.

上图就是一个mysql节点的集群,一主两从,在master,slave1,slave2日志文件里的pos,都各不相同,就是一个event,在master的日志里,pos可能是700,而在slave1,slave2里,pos可能就是300,400了,因为众多slave也可能不是同时加入集群的,不是从同一个位置进行同步.
而GTID,在master,slave1,slave2各自的日志文件里,同一个event的GTID值都是一样的.

为什么要有这个区分呢?
大家都知道,这整个集群架构的节点,通常情况下,是master在工作,其他两个结点做备份,而且,各个节点的机器,性能不可能完全一致,所以,在做备份时,备份的速度就不一样,当master突然crash掉之后,马上会启用从节点机器,接管master的工作,当有多个从节点时,选择备份日志文件最接近master的那个节点
现在就出现情况了,当salve1变成主节点,那slave2就应该从slave1去获取日志文件,进行同步.

如果使用的是pos,三者的pos不一致,slave2怎么去获取它当前要同步的事件在slave1里的pos呢,很难.
所以就有了GTID,全局的,将所有节点对于同一个event的标记完全一致,当master crash掉之后,slave2根据同一个GTID直接去读取slave1的日志文件,继续同步.

GTID配置:

所有节点上都要进行设置
vim /etc/my.cnf

gtid-mode=ON      #开启GTIDenforce-gtid-consistencylog-bin=mysql-bin   #开启二进制文件系统server-id=1         #必须为1-231之间的一个正整数值,各个值节点不能一致

在从节点上mysql设置:

 mysql>change master to master_host='xxxxxxx',master_user='xxxxxx',master_password='xxxxx',MASTER_AUTO_POSITION=1; mysql> start slave;#重启io线程,刷新状态mysql> stop slave io_thread;mysql> start slave io_thread;

master_host master_user master_password 与主从复制一致,
唯一不一致的是使用了MASTER_AUTO_POSITION参数
当使用 MASTER_AUTO_POSITION 参数的时候，MASTER_LOG_FILE，MASTER_LOG_POS参数不能使用
如果想要从GTID配置回pos,再次执行这条语句,不过把MASTER_AUTO_POSITION置为0

测试:

切换目录到 /var/lib/mysql/ 下,默认日志文件都在这
如果不在,你也不知道在哪,就用命令

find mysql-bin.000001 / | grep mysql-bin.000001

查看主节点日志文件:

mysql> show master status;

[root@server5 mysql]# pwd/var/lib/mysql[root@server5 mysql]# mysqlbinlog mysql-bin.000012

上面的命令输出我截取了一个event

pos状态下的日志:

这一个event开始的pos是 4 结束pos是 123

从节点同一个event日志:

这一个event的开始pos是201,没有记录自己的终止pos

因为从节点去同步主节点日志时,记录的 end_log_pos 值是主节点的end_log_pos 的值,以便于下次接着同步.

GTID模式日志:
主节点显示:

从节点显示:

下一个事物的 GTID:7e1d4211-516c-11e7-9ec8-525400bd1441:6 ,它是按GTID去找event的