Mysql(23)—数据库主从复制的基本原理和步骤

Posted 2021-09-18 刘Java

详细介绍了mysql主从复制的原理和基本流程，以及一些问题的处理方式。

文章目录

• 1 主从复制的原理
• 2 主从切换
• 3 双主互备
• 4 主备延迟
• • 4.1 什么是主备延迟
  • • 4.2 主备延迟的原因
  • 4.3 主备切换策略
  • • 4.3.1 可靠性优先策略
    • 4.3.2 可用性优先策略
  • 1.4. 并行复制

1 主从复制的原理

主从复制可以很好的解决的单点故障，并且可以进行读写分离来减轻数据库的压力。很多情况下主服务器仅作为写入数据服务器，而构建多个从节点来进行数据读取。但主库也可以进行读操作。因此建议：关键业务读写都由主库承担，非关键业务读写分离。

下图就是MySQL主从同步的基本原理，节点A到B这条线的内部流程。

备库B和主库A之间维持了一个长连接。主库A内部有一个线程dump_thread，专门用于服务备库B的这个长连接。

一个事务日志同步的完整过程如下：

在备库B上通过change master命令，设置主库A的IP、端口、用户名、密码，以及要从哪个位置开始请求binlog，这个位置包含文件名和日志偏移量。

1. 在备库B上执行start slave命令，这时候备库会启动两个线程，就是图中的io_thread和sql_thread。其中io_thread负责与主库建立连接。
2. 主库A校验完用户名、密码后，dump_thread开始按照备库B传过来的位置，从本地读取binlog文件的内容，发给B。
3. 备库B的io_thread拿到网络传输过来的binlog内容后，写到本地文件，称为中转日志（relay log）。
4. 备库B的sql_thread读取中转日志，解析出日志里的命令并执行（重放）。

可以看到，MySQL 主从复制是依赖于 binlog。此前一共三个线程参与主从复制，后来由于多线程复制方案的引入，sql_thread演化成为了多个线程。

2 主从切换

下图就是基本的主备切换流程：

在状态1中，客户端的读写都直接访问节点A，而节点B是A的备库，只是将A的更新都同步过来，到本地执行。这样可以保持节点B和A的数据是相同的。

当需要切换的时候，就切成状态2。这时候客户端读写访问的都是节点B，而节点A是B的备库。

在状态1中，虽然节点B没有被直接访问，但是建议把备库节点B，设置成只读模式。有以下几个原因：

1. 有时候一些运营类的查询语句会被放到备库上去查，设置为只读可以防止误操作；
2. 防止切换逻辑有bug，比如切换过程中出现双写，造成主备不一致；
3. 可以用readonly状态，来判断节点的角色。

把备库设置成只读了，还怎么跟主库保持同步更新呢？实际上因为readonly设置对超级(super)权限用户是无效的，而用于同步更新的线程，就拥有超级权限，因此无须担心。

注意，主从切换不是自动进行的，需要人为手动操作，宕机时间长，严重影响线上业务。

3 双主互备

单主多从存在单点故障的问题，从库切换成主库需要作改动。双主即两个数据库互为主备，能保持两个数据库的状态自动同步，在切换的时候就不用再修改主备关系。对任何一个数据库的操作都自动应用到另外一个数据库，始终保持两个数据库数据一致，这样做的意义是既提高了数据库的容灾性，又可以做负载均衡，可以将请求分摊到其中任何一台上，提高网站吞吐量。

如下是在生产环境中用得更多的双M结构。节点A和B之间总是互为主备关系：

可以使用Keepalived 快速实现MySQL双主高可用。在keepalived中2种模式，分别是master->backup模式和backup->backup模式：

1. 在master->backup模式下，一旦主库宕机，虚拟ip会自动漂移到从库上提供服务，当主库修复后，keepalived启动后，还会把虚拟ip抢占过来，即使设置了非抢占模式(nopreempt)抢占ip的动作也会发生。
2. 在backup->backup模式下，当主库宕机后虚拟ip会自动漂移到从库上提供服务，当原主库恢复和keepalived服务启动后，并不会抢占新主的虚拟ip，即使是优先级高于从库的优先级别，也不会发生抢占。

多主需要考虑自增长ID问题，这个需要特别设置配置文件，比如双主，可以使用奇偶，总之，主之间设置自增长ID相互不冲突就能完美解决自增长ID冲突问题。

双M结构有一个问题要解决，业务逻辑在节点A上更新了一条语句，然后再把生成的binlog发给节点B，节点B执行完这条更新语句后也会生成binlog。那么，如果节点A同时是节点B的备库，相当于又把节点B新生成的binlog拿过来执行了一次，然后节点A和B间，会不断地循环执行这个更新语句，也就是循环复制。

MySQL在binlog中记录了这个命令第一次执行时所在实例的server id。因此，可以用下面的逻辑，来解决两个节点间的循环复制问题：

1. 规定两个库的server id必须不同，如果相同，则它们之间不能设定为主备关系；
2. 一个备库接到binlog并在重放的过程中，生成与原binlog的server id相同的新的binlog；
3. 每个库在收到从自己的主库发过来的日志后，先判断server id，如果跟自己的相同，表示这个日志是自己生成的，就直接丢弃这个日志。

双M结构日志的执行流如下：

1. 从节点A更新的事务，binlog里面记的都是A的server id
2. 传到节点B执行一次以后，节点B生成的binlog的server id也是A的server id
3. 再传回给节点A，A判断这个server id与自己的相同，就不会再处理这个日志。所以，死循环在这里就断掉了。

4 主备延迟

4.1 什么是主备延迟

与数据同步有关的时间点主要包括以下三个：

1. 主库A执行完成一个事务，写入binlog，这个时刻记为T1。
2. 之后传给备库B，备库B接收完这个binlog的时刻记为T2。
3. 备库B执行完这个事务，把这个时刻记为T3。

所谓主备延迟，就是同一个事务，在备库执行完成的时间和主库执行完成的时间之间的差值，也就是T3-T1。可以在备库上执行show slave status命令，它的返回结果里面会显示seconds_behind_master，用于表示当前备库延迟了多少秒。

seconds_behind_master的计算方法是这样的：

1. 每个事务的binlog里面都有一个时间字段，用于记录主库上写入的时间
2. 备库取出当前正在执行的事务的时间字段的值，计算它与当前系统时间的差值，得到seconds_behind_master

如果主备库机器的系统时间设置不一致，不会导致主备延迟的值不准。备库连接到主库的时候，会通过SELECTUNIX_TIMESTAMP()函数来获得当前主库的系统时间。如果这时候发现主库的系统时间与自己不一致，备库在执行seconds_behind_master计算的时候会自动扣掉这个差值。

网络正常情况下，主备延迟的主要来源是备库接收完binlog和执行完这个事务之间的时间差。主备延迟最直接的表现是，备库消费中转日志的速度，比主库生产binlog的速度要慢。

4.2 主备延迟的原因

1. 有些部署条件下，备库所在机器的性能要比主库所在的机器性能差。
2. 备库的压力大。主库提供写能力，备库提供一些读能力。忽略了备库的压力控制，导致备库上的查询耗费了大量的CPU资源，影响了同步速度，造成主备延迟。可以做以下处理：
   1. 一主多从。除了备库外，可以多接几个从库，让这些从库来分担读的压力。
   2. 通过binlog输出到外部系统，比如Hadoop这类系统，让外部系统提供统计类查询的能力。
3. 大事务。因为主库上必须等事务执行完才会写入binlog，再传给备库。所以，如果一个主库上的语句执行10分钟，那这个事务很可能会导致从库延迟10分钟。典型的大事务场景：一次性地用delete语句删除太多数据和大表的DDL。

由于主备延迟的存在，所以在主备切换的时候，就相应的有不同的策略。

4.3 主备切换策略

4.3.1 可靠性优先策略

这个切换流程，一般是由专门的HA系统来完成的，称之为可靠性优先流程。如下图（SBM，是seconds_behind_master参数），双M结构下，从状态1到状态2切换的详细过程如下：

1. 判断备库B现在的seconds_behind_master，如果小于某个值继续下一步，否则持续重试这一步
2. 把主库A改成只读状态，即把readonly设置为true
3. 判断备库B的seconds_behind_master的值，直到这个值变成0为止
4. 把备库B改成可读写状态，也就是把readonly设置为false
5. 把业务请求切到备库B。

这个切换流程中是有不可用的时间的。在步骤2之后，主库A和备库B都处于readonly状态，也就是说这时系统处于不可写状态，直到步骤5完成后才能恢复。在这个不可用状态中，比较耗时的是步骤3，可能需要耗费好几秒的时间。也是为什么需要在步骤1先做判断，确保seconds_behind_master的值足够小。

4.3.2 可用性优先策略

如果强行把可靠性优先策略的步骤4、5调整到最开始执行，也就是说不等主备数据同步，直接把连接切到备库B，并且让备库B可以读写，那么系统几乎没有不可用时间。这个切换流程的代价，就是可能出现数据不一致的情况。

假设有一个表 t：

mysql> CREATE TABLE `t` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `c` int(11) unsigned DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB;

insert into t(c) values(1),(2),(3);

这个表定义了一个自增主键id，初始化数据后，主库和备库上都是3行数据。接下来，业务人员要继续在表t上执行两条插入语句的命令，依次是：

insert into t(c) values(4);
insert into t(c) values(5);

假设，现在主库上其他的数据表有大量的更新，导致主备延迟达到5秒。在插入一条c=4的语句后，发起了主备切换。

下图是可用性优先策略，且binlog_format=mixed时的切换流程和数据结果。

这个切换流程如下：

1. 步骤2中，主库A执行完insert语句，插入了一行数据（4,4），之后开始进行主备切换。
2. 步骤3中，由于主备之间有5秒的延迟，所以备库B还没来得及应用“插入c=4”这个中转日志，就开始接收客户端“插入 c=5”的命令。
3. 步骤4中，备库B插入了一行数据（4,5），并且把这个binlog发给主库A。
4. 步骤5中，备库B执行“插入c=4”这个中转日志，插入了一行数据（5,4）。而直接在备库B执行的“插入c=5”这个语句，传到主库A，就插入了一行新数据（5,5）。

最后的结果就是，主库A和备库B上出现了两行不一致的数据。可以看到，这个数据不一致，是由可用性优先流程导致的。

如果我还是用可用性优先策略，但设置binlog_format=row。因为row格式在记录binlog的时候，会记录新插入的行的所有字段值，所以最后只会有一行不一致。而且，两边的主备同步的应用线程会报错duplicate key error并停止。也就是说，这种情况下，备库B的(5,4)和主库A的(5,5)这两行数据，都不会被对方执行。

从上面的分析中，你可以看到一些结论：

1. 使用row格式的binlog时，数据不一致的问题更容易被发现。而使用mixed或者statement格式的binlog时，数据很可能悄悄地就不一致了。如果你过了很久才发现数据不一致的问题，很可能这时的数据不一致已经不可查，或者连带造成了更多的数据逻辑不一致。
2. 主备切换的可用性优先策略会导致数据不一致。因此，大多数情况下，我都建议你使用可靠性优先策略。毕竟对数据服务来说的话，数据的可靠性一般还是要优于可用性的。

1.4. 并行复制

不论是偶发性的查询压力，还是备份，对备库延迟的影响一般是分钟级的，而且在备库恢复正常以后都能够追上来。

但是，如果备库执行日志的速度持续低于主库生成日志的速度，那这个延迟就有可能成了小时级别。而且对于一个压力持续比较高的主库来说，备库很可能永远都追不上主库的节奏。这里就涉及到了备库并行复制能力。

主备流程图如下：

主备的并行复制能力，要关注的就是上图中黑色的两个箭头。一个代表客户端写入主库，另一个代表备库上sql_thread执行中转日志。如果用箭头的粗细来代表并行度的话，那么真实情况就如图1所示，第一个箭头要明显粗于第二个箭头。

在官方的5.6版本之前，MySQL只支持备库单sql_thread线程更新数据，由此在主库并发高、TPS高时就会出现严重的主备延迟问题。5.6之后，支持多个sql-thread线程，并且随着版本不断地演进。

实际上，所有的多线程复制机制，都是要把图1中只有一个线程的sql_thread，拆成多个线程，也就是都符合下面的这个模型：

上图中，coordinator就是原来的sql_thread, 不过现在它不再直接更新数据了，只负责读取中转日志和分发事务。真正更新日志的，变成了worker线程。而work线程的个数，就是由参数slave_parallel_workers决定的。32核物理机的情况下，把这个值设置为8~16之间最好，毕竟备库还有可能要提供读查询，不能把CPU都吃光了。

coordinator在分发的时候，需要满足以下这两个基本要求：

1. 不能造成更新覆盖。这就要求更新同一行的两个事务，必须被分发到同一个worker中。
2. 同一个事务不能被拆开，必须放到同一个worker中。

参考资料：

1. 《 MySQL 技术内幕: InnoDB 存储引擎》
2. 《高性能 MySQL》
3. 《MySQL实战45讲 | 极客时间 | 丁奇》

如有需要交流，或者文章有误，请直接留言。另外希望点赞、收藏、关注，我将不间断更新各种Java学习博客！