MySQL active/standby switch

一主多从
主备切换

A switching system completes the master-slave switching process of one master and multiple slaves

GTID的全称是Global Transaction Identifier,也就是全局事务ID,是一个事务在提交的时候生成的,是这个事务的唯一标识.它由两部分组成,格式是：

GTID=server_uuid:gno

其中：
server_uuid是一个实例第一次启动时自动生成的,是一个全局唯一的值;
gno是一个整数,初始值是1,每次提交事务的时候分配给这个事务,并加1.

在MySQL的官方文档里,GTID格式是这么定义的：GTID=source_id:transaction_id

在MySQL里面我们说transaction_id就是指事务id,事务id是在事务执行过程中分配的,如果这个事务回滚了,事务id也会递增,而gno是在事务提交的时候才会分配.

基于GTID的主备切换

现在,我们已经理解GTID的概念,再一起来看看基于GTID的主备复制的用法.

在GTID模式下,备库B要设置为新主库A’的从库的语法如下：

CHANGE MASTER TO
MASTER_HOST=$hos{t}_{n}ameMASTE{R}_{P}ORT=$port
MASTER_USER=$use{r}_{n}ameMASTE{R}_{P}ASSWORD=$password
master_auto_position=1

其中,master_auto_position=1就表示这个主备关系使用的是GTID协议.可以看到,前面让我们头疼不已的MASTER_LOG_FILE和MASTER_LOG_POS参数,已经不需要指定了.

我们把现在这个时刻,实例A’的GTID集合记为set_a,实例B的GTID集合记为set_b.接下来,我们就看看现在的主备切换逻辑.

我们在实例B上执行start slave命令,取binlog的逻辑是这样的：

实例B指定主库A’,基于主备协议建立连接.

实例B把set_b发给主库A’.

实例A’算出set_a与set_b的差集,也就是所有存在于set_a,但是不存在于set_b的GITD的集合,判断A’本地是否包含了这个差集需要的所有binlog事务.
a. 如果不包含,表示A’已经把实例B需要的binlog给删掉了,直接返回错误;
b. 如果确认全部包含,A’从自己的binlog文件里面,找出第一个不在set_b的事务,发给B;

之后就从这个事务开始,往后读文件,按顺序取binlog发给B去执行.

其实,这个逻辑里面包含了一个设计思想：在基于GTID的主备关系里,系统认为只要建立主备关系,就必须保证主库发给备库的日志是完整的.因此,如果实例B需要的日志已经不存在,A’就拒绝把日志发给B.

这跟基于位点的主备协议不同.基于位点的协议,是由备库决定的,备库指定哪个位点,主库就发哪个位点,不做日志的完整性判断.

基于上面的介绍,我们再来看看引入GTID后,一主多从的切换场景下,主备切换是如何实现的.

由于不需要找位点了,所以从库B、C、D只需要分别执行change master命令指向实例A’即可.

其实,严谨地说,主备切换不是不需要找位点了,而是找位点这个工作,在实例A’内部就已经自动完成了.但由于这个工作是自动的,所以对HA系统的开发人员来说,非常友好.