MySQL 数据库主从复制的基本原理和步骤

约定不等于承诺〃 2022-09-09 14:52 129阅读 0赞

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

### 文章目录 ###

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

# 1 主从复制的原理 #

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

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

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YiYSmF2YQ_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center]

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

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

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

1.  同步之前，在备库B上通过`change master`命令，设置主库A的IP、端口、用户名、密码，以及要从哪个位置开始请求binlog，这个位置包含文件名和日志偏移量。
2.  开始同步，在备库B上执行start slave命令，这时候备库会启动两个线程，就是图中的`io_thread`和`sql_thread`。其中io\_thread负责与主库建立连接。
3.  主库A校验完用户名、密码后，`dump_thread`开始按照备库B传过来的位置，从本地读取`binlog`文件的内容，发给B。
4.  备库B的`io_thread`拿到网络传输过来的binlog内容后，写到本地文件，称为`中转日志（relay log）`。
5.  备库B的`sql_thread`读取中转日志，解析出日志里的命令并执行（重放）。

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

# 2 主从切换 #

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

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YiYSmF2YQ_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 1]

在状态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之间总是互为主备关系：

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YiYSmF2YQ_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 2]

**可以使用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切换的详细过程如下：  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YiYSmF2YQ_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 3]

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时的切换流程和数据结果。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YiYSmF2YQ_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 4]

这个切换流程如下：

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)这两行数据，都不会被对方执行。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YiYSmF2YQ_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 5]

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

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

## 1.4. 并行复制 ##

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

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

主备流程图如下：  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YiYSmF2YQ_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 6]

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

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

实际上，所有的多线程复制机制，都是要把图1中只有一个线程的sql\_thread，拆成多个线程，也就是都符合下面的这个模型：  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YiYSmF2YQ_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 7]

**上图中，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学习博客！

[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YiYSmF2YQ_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center]: /images/20220829/b1fedfa6defb4c9bba2c3881a799e0cd.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YiYSmF2YQ_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 1]: /images/20220829/f4cad000d95043c7b9d0e693c4f75302.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YiYSmF2YQ_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 2]: /images/20220829/e8d9f2249a8e4ab1b215076e9f2c429b.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YiYSmF2YQ_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 3]: /images/20220829/d77fb3d63a5f4934bb12b4b902c6a276.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YiYSmF2YQ_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 4]: /images/20220829/45477e872297416f8fd78b223e458370.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YiYSmF2YQ_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 5]: /images/20220829/1fbe5b316b83490a845ea4d635057fb1.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YiYSmF2YQ_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 6]: /images/20220829/f11c67bf6bb243419d158fa0a23b098a.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5YiYSmF2YQ_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center 7]: /images/20220829/755a1dca35a74ef3a4f4143a4f7f5f2b.png