详细介绍了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，这个位置包含文件名和日志偏移量。

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

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

2 主从切换

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

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

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

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

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

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

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

3 双主互备

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

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

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

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

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

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

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

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

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

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

4 主备延迟

4.1 什么是主备延迟

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

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

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

seconds_behind_master的计算方法是这样的：

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

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

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

4.2 主备延迟的原因

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

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

4.3 主备切换策略

4.3.1 可靠性优先策略

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

判断备库B现在的seconds_behind_master，如果小于某个值继续下一步，否则持续重试这一步把主库A改成只读状态，即把readonly设置为true判断备库B的seconds_behind_master的值，直到这个值变成0为止把备库B改成可读写状态，也就是把readonly设置为false把业务请求切到备库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时的切换流程和数据结果。

这个切换流程如下：

步骤2中，主库A执行完insert语句，插入了一行数据（4,4），之后开始进行主备切换。步骤3中，由于主备之间有5秒的延迟，所以备库B还没来得及应用“插入c=4”这个中转日志，就开始接收客户端“插入 c=5”的命令。步骤4中，备库B插入了一行数据（4,5），并且把这个binlog发给主库A。步骤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)这两行数据，都不会被对方执行。

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

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

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在分发的时候，需要满足以下这两个基本要求：

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

参考资料：

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

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

如果觉得《MySQL 数据库主从复制的基本原理和步骤》对你有帮助，请点赞、收藏，并留下你的观点哦！