Notes

Exploring note

0%

一主多从，主备切换逻辑

发表于 更新于 分类于
本文字数： 4.8k 阅读时长 ≈ 8 分钟
主库出问题，从库怎么办

A和A’互为主备，从库B、C、D指向的是主库A。一主多从的设置，一般用于读写分离，主库负责所有的写入和一部分读，其他的读请求则由从库分担。相比于一主一备的切换流程，一主多从结构在切换完成后，A’会成为新的主库，从库B、C、D也要改接到A’。

基于位点的主备切换

把节点B设置成节点A’的从库的时候，需要执行一条change master命令： 

1
2
3
4
5
6
7
CHANGE MASTER TO 
MASTER_HOST=$host_name 
MASTER_PORT=$port 
MASTER_USER=$user_name 
MASTER_PASSWORD=$password 
MASTER_LOG_FILE=$master_log_name 
MASTER_LOG_POS=$master_log_pos
  • master_host、master_port、master_user、master_password四个参数，分别代表了主库A’的IP、端口、用户名、密码。
  • master_log_file、master_log_pos参数，表示要从主库的master_log_name文件的master_log_pos这个位置的日志继续同步。这个位置就是同步位点，是主库对应的文件名和日志偏移量。

原来节点B是A的从库，本地记录的也是A的位点。但是相同的日志，A的位点和A’的位点是不同的，从库B切换的时候，需要先经过“找同步位点”逻辑。

同步位点设置

切换过程中不能丢数据，找位点的时候，总是要找一个“稍微往前”的，然后再通过判断跳过那些在从库上已经执行过的事务：

  1. 等待新主库A’把中转日志relay log全部同步完成；
  2. 在A’上执行show master status命令，得到当前A’上最新的File和Position；
  3. 取援助库A故障的时刻T；
  4. 用mysqlbinlog工具解析A’的File，等得到T时刻的位点。

    mysqlbinlog File –stop-datetime=T –start-datetime=T;

end_log_pos后面的值假设为’123’，表示的就是A’这个实例，在T时刻写入新的binlog的位置，把这个值123作为$master_log_pos，用在节点B的change master命令里。

同步位点不精确

在T时刻，主库A已经执行完成了一个insert语句插入了一行数据R，并且已经将binlog传给了A’和B，然后再传完的瞬间主库A的主机掉电了。

  1. 在从库B上，由于同步了binlog，R这一行已经存在；
  2. 在新主库A’上，R这一行也已经存在，日志是写在A的end_log_pos值123对应的位置之后；
  3. 在从库B上执行change master命令，指向A’的File文件的123位置，会把插入R这一行数据的binlog又同步到从库B去执行。

    从库B的同步线程会报告Duplicate entry ‘id_of_R’ for key ‘PRIMARY’错误，提示出现了主键冲突，然后停止同步。

解决方案

切换任务的时候，主动跳过错误的两种方法：

  • 主动跳过一个事务：

set global sql_slave_skip_counter=1; start slave;

sql_slave_skip_counter跳过的是一个event，但MySQL不能只执行一半的事务，跳过了一个event，就会跳到这个事务的末尾。

切换过程中，可能会不止重复执行一个事务，需要在从库B刚开始接到新主库A’时，持续观察，每次碰到这些错误就停下来，执行一次跳过命令，直到不再出现停下来的情况，以此来跳过可能涉及的所有事务。

  • 设置slave_skip_errors参数，直接跳过指定的错误：

在执行主备切换时，经常遇到的两类错误：1062错误是插入数据时唯一键冲突；1032错误是删除数据时找不到行。

把slave_skip_errors设置为“1032,1062”，中间碰到这两个错误时直接跳过。
只有主备切换过程中，直接跳过1032和1062错误时无损的，等主备间的同步关系建立按成，并稳定执行一段时间之后，需要把这个参数设置为空，以免之后真的主从数据不一致被跳过。

GTID

MySQL5.6版本引入了GTID，解决主备切换复杂易错的问题。

GTID全称是Global Transaction Identifier，全局事务ID，是一个事务在提交的时候生成的，是这个事务的唯一标识，由两部分组成，格式是：GTID=server_uuid:gno;

  • server_uuid是一个实例第一次启动时自动生成的，是一个全局唯一的值；
  • gno是一个整数，初始值是1，每次提交事务的时候分配给这个事务，并加1。

官方文档定义格式：GTID=source_id:transaction_id;

  • source_id就是server_uuid；
  • transaction_id容易造成误解，用gno代替。

    MySQL中transaction_id是指事务id，事务id是在事务执行过程找那个分配的，即使这个事务回滚了，事务id也会递增，而gno是在事务提交的时候才会分配。
    从效果上看GTID往往是连续的，用gno表示更容易理解。

启动一个MySQL实例的时候，加上参数gtid_mode=on和enforce_gtid_consistency=on；就可以启动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。

set gtid_next=’aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee:10’;
begin;
commit;
set gtid_next=automatic;
start slave;

每个MySQL实例都维护了一个gtid集合，用来对应“这个实例执行过的所有事务”。通过show master status命令查看，对应的Executed_Gtid_set参数值。

在binlog文件开头，有一个Previous_gtids，用于记录生成这个binlog的时候，实例的Executed_gtid_set。启动时只需要解析最后一个文件，就可以知道该实例所有的GTID集合，也可以快速的定位GTID在哪个文件。

基于GTID的主备切换

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

1
2
3
4
5
6
CHANGE MASTER TO 
MASTER_HOST=$host_name 
MASTER_PORT=$port 
MASTER_USER=$user_name 
MASTER_PASSWORD=$password 
master_auto_position=1
  • master_auto_position=1表示这个准备关系使用的是GTID协议。

当前时刻，实例A’GTID集合记为set_a，实例B的GTID集合记为set_b。在实例B上执行start slave命令，取binlog的逻辑如下：

  1. 实例B指定主库A’，基于准备协议建立连接。
  2. 实例B把set_b发给主库A’。
  3. 实例A’算出set_a与set_b的差集，也就是所有存在于set_a，但是不存在于set_b的GTID的集合，判断A’本地是否包含了这个差集需要的所有binlog事务。
    a. 如果不包含，表示A’已经把实例B需要的binlog给删掉的了，直接返回错误；
    b. 如果确认全部包含，A’从自己的binlog文件里面，找出第一个不在set_b的事务，发给B；
  4. 之后就从这个事务开始，往后读文件，按顺序取binlog发给B去执行。

设计思想之一：在基于GTID的主备关系里，系统认为只要建立了主备关系，就必须保证主库发给备库的日志是完成的。因此，如果实例B需要的日志已经不存在，A’就拒绝吧日志发给B。

如果一个新的从库接上主库，但需要的binlog已经没了，解决方案：

  1. 如果业务允许主从不一致的情况，可以在主库上先执行show global variables like ‘gtid_purged’，得到主库已经删除的GTID集合，假设是gtid_purger1；然后先在从库上执行reset master，再执行set global gtid_purged=’gtid_purged1’；最后执行start slave，就会从主库现存的binlog开始同步。binlog缺失的那一部分，数据在从库上可能会有丢失，造成主从不一致。
  2. 如果需要主从数据一致，通过重新搭建从库来做。
  3. 如果有其他的从库保留有全量的binlog的话，可以把新的从库先接到这个保留了全量的binlog的从库，追上日志以后，如果有需要，再接回从库。
  4. 如果binlog有备份的情况，可以先在从库上应用缺失的binlog，然后再执行start slave。

对比区别：基于位点的协议，是由备库决定的，备库指定哪个位点，主库就发哪个位点，不做日志的完整性判断。

GTID同时解决了循环复制的问题。

GTID模式下，一主多从主备切换，从库B、C、D只需要分别执行change master命令指向实例A’即可。找位点的工作在实例A’内部已经自动完成。对于HA系统的开发人员非常友好。

之后整个系统就由新主库A’写入，主库A’的自己生成的binlog中的GTID集合格式是：server_uuid_of_A’:1-M。

从库(包括备库)的GTID集合的整体格式为：server_uuid_of_A:1-N,server_uuid_of_A’:1-M。

GTID和在线DDL

索引缺失引起的性能问题，可以通过在线加索引来解决。考虑到要避免新增索引对主库性能造成影响，可以先在备库加索引，然后再切换。

在双M结构下，备库执行的DDL语句也会传给主库，为了避免传回后对主库造成影响，要通过set sql_log_bin=off关掉binlog。binlog并没有记录下这一更新，导致数据和日志不一致。

解决：假设互为主备关系的库是实例X和实例Y，当前主库是X，并且都打开了GTID模式，主备切换流程：

  • 在实例X上执行 stop slave。

  • 在实例Y上执行DDL语句。这里不需要关闭binlog。

  • 执行完成后，查出这个DDL语句对应的GTID，并记为server_uuid_of_Y:gno。

  • 到实例X中执行以下语句序列：

    set GTID_NEXT=”server_uuid_of_Y:gno”;
    begin;
    commit;
    set gtid_next=automatic;
    start slave;

    这样模拟一个空事务既可以让实例Y的更新有binlog记录，同时也可以确保不会在实例X上执行这条更新。

  • 接下来，执行完主备切换，照着上述流程再执行一遍即可。