您好,欢迎访问代理记账网站
移动应用 微信公众号 联系我们

咨询热线 -

电话 15988168939

联系客服
  • 价格透明
  • 信息保密
  • 进度掌控
  • 售后无忧

一主多从的主备切换

如图,原本一个一主多从的服务是这样子的

 

主备切换后的结果

 

基于位点的主备切换

把节点B设置成节点A的从库的时候,需要执行一条change master命令,这条命令有以下6个参数:

  • MASTER_HOSTMASTER_PORTMASTER_USERMASTER_PASSWORD四个参数,分别代表了主库AIP、端口、用户名和密码。
  • 最后两个参数MASTER_LOG_FILEMASTER_LOG_POS表示,要从主库的master_log_name文件的master_log_pos这个位置的日志继续同步。而这个位置就是我们所说的同步位点,也就是主库对应的文件名和日志偏移量。

 

原来节点BA的从库,本地记录的也是A的位点。但是相同的日志,A的位点和A的位点是不同的。因此,从库B要切换的时候,就需要先经过找同步位点这个逻辑。这个点很难精确到,只能取一个大概的位置。考虑到切换过程中不能丢数据,所以我们找位点的时候,总是要找一个稍微往前”的,然后再通过判断跳过那些在从库B上已经执行过的事务。

 

一种取同步位点的方法是这样的:

1. 等待新主库A把中转日志(relay log)全部同步完成;

2. A上执行show master status命令,得到当前A上最新的File Position

3. 取原主库A故障的时刻T

4. mysqlbinlog工具解析AFile,得到T时刻的位点。

当然这个值有时候也是不准确的,考虑以下场景:

假设在T这个时刻,主库A已经执行完成了一个insert 语句插入了一行数据R,并且已经将binlog传给了AB,然后在传完的瞬间主库A的主机就掉电了。那么,这时候系统的状态是这样的:

1. 在从库B上,由于同步了binlogR这一行已经存在;

2. 在新主库A上, R这一行也已经存在,日志是写在123这个位置之后的;

3. 我们在从库B上执行change master命令,指向AFile文件的123位置,就会把插入R这一行数据的binlog又同步到从库B去执行。这时候,从库B的同步线程就会报告 Duplicate entry ‘id_of_R’ for key ‘PRIMARY’ 错误,提示出现了主键冲突,然后停止同步。

在切换任务的时候,要先主动跳过这些错误,有两种解决方法:

  • 主动跳过一个事务。
  • 设置slave_skip_errors参数,直接设置跳过指定的错误。在执行主备切换时,有这么两类错误,是经常会遇到的:1062错误是插入数据时唯一键冲突;1032错误是删除数据时找不到行。因此,我们可以把slave_skip_errors 设置为 “1032,1062”,这样中间碰到这两个错误时就直接跳过。

注意以上只能在主备切换的时候设置,如果完成了后要把这个去掉。

 

GTID

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

GTID=server_uuid:gno

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

在GTID模式下,每个事务都会跟一个GTID一一对应。这个GTID有两种生成方式,而使用哪种方式取决于session变量gtid_next的值。

1. 如果gtid_next=automatic,代表使用默认值。这时,MySQL就会把server_uuid:gno分配给这个事务。

a. 记录binlog的时候,先记录一行 SET @@SESSION.GTID_NEXT=‘server_uuid:gno’;

b. 把这个GTID加入本实例的GTID集合。

2. 如果gtid_next是一个指定的GTID的值,比如通过set gtid_next='current_gtid’指定为current_gtid,那么就有两种可能:

a. 如果current_gtid已经存在于实例的GTID集合中,接下来执行的这个事务会直接被系统忽略;

b. 如果current_gtid没有存在于实例的GTID集合中,就将这个current_gtid分配给接下来要执行的事务,也就是说系统不需要给这个事务生成新的GTID,因此gno也不用加1。

注意,一个current_gtid只能给一个事务使用。这个事务提交后,如果要执行下一个事务,就要执行set 命令,把gtid_next设置成另外一个gtid或者automatic。

 

每个MySQL实例都维护了一个GTID集合,用来对应这个实例执行过的所有事务”。下面举个例子说明GTID的用法,如有一个表t

 

可以看到,事务的BEGIN之前有一条SET @@SESSION.GTID_NEXT命令。这时,如果实例X有从库,那么将CREATE TABLEinsert语句的binlog同步过去执行的话,执行事务之前就会先执行这两个SET命令, 这样被加入从库的GTID集合的,就是图中的这两个GTID

         如果现在X是另外一个Y的从库,在Y上执行了以下指令:

insert into t values(1,1);

并且,这条语句在实例Y上的GTID“aaaaaaaa-cccc-dddd-eeee-ffffffffffff:10”。那么就一定会出现主键冲突。这个时候,就要执行:

把这个GTID加入到库中,这样子X在执行的时候就会跳过这个事务。

 

基于GTID的主备切换

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

master_auto_position=1就表示这个主备关系使用的是GTID协议。MASTER_LOG_FILEMASTER_LOG_POS参数,已经不需要指定了。

我们把现在这个时刻,实例A’的GTID集合记为set_a,实例B的GTID集合记为set_b,那么主备切换的逻辑如下:

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

2. 实例Bset_b发给主库A

3. 实例A算出set_aset_b的差集,也就是所有存在于set_a,但是不存在于set_bGITD的集合,判断A本地是否包含了这个差集需要的所有binlog事务。

a. 如果不包含,表示A已经把实例B需要的binlog给删掉了,直接返回错误;

b. 如果确认全部包含,A从自己的binlog文件里面,找出第一个不在set_b的事务,发给B

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

 

GTID和在线DDL

我们在之前的文章中说到,在双M结构下,备库执行的DDL语句也会传给主库,为了避免传回后对主库造成影响,要通过set sql_log_bin=off关掉binlog。这样操作的话,数据库里面是加了索引,但是binlog并没有记录下这一个更新,是不是会导致数据和日志不一致的情况?这个可以用GTID说明一下。

假设,这两个互为主备关系的库还是实例X和实例Y,且当前主库是X,并且都打开了GTID模式。这时的主备切换流程可以变成下面这样:

  1. 在实例X上执行stop slave
  2. 在实例Y上执行DDL语句。注意,这里并不需要关闭binlog
  3. 执行完成后,查出这个DDL语句对应的GTID,并记为 server_uuid_of_Y:gno
  4. 到实例X上执行以下语句序列:

这样做的目的在于,既可以让实例Y的更新有binlog记录,同时也可以确保不会在实例X上执行这条更新。


分享:

低价透明

统一报价,无隐形消费

金牌服务

一对一专属顾问7*24小时金牌服务

信息保密

个人信息安全有保障

售后无忧

服务出问题客服经理全程跟进