MySQL 主从复制原理

1.目的

MySQL 主从复制（Master-Slave Replication）是一种常见的数据库复制技术，它在数据库管理中发挥着重要的作用，有以下几个主要用途：

• 高可用：主从复制通过在多个服务器之间复制数据，提供了数据冗余和高可用。如果主数据库发生故障，从数据库可以接管，确保系统继续运行。
• 高性能：主从复制支持读写分离，即读操作可以路由到从服务器，而写操作仍然由主服务器处理。这有助于提高读操作的性能，减轻主服务器的负载。
• 备份容灾：从服务器可以用于数据库备份目的。备份可以在不影响主服务器性能的情况下进行，而且备份可以是实时的，以确保数据安全。

MySQL 主从复制提供了高可用性、高性能、备份灾难等关键功能，使其成为许多企业和组织在数据库管理中的重要工具。有了主从复制，MySQL 的部署会变得简单、灵活并且具有多样性，从而可以根据不同的业务场景做出灵活调整。

2.主从架构

• 一主一从
  

• 一主多从
  
  一主一从和一主多从是最常见的主从架构，使用起来简单有效，不仅可以实现 HA，而且还能读写分离，进而提升集群的并发能力。

• 多主一从
  
  多主一从可以将多个 MySQL 数据库备份到一台存储性能比较好的服务器上。

• 双主复制
  
  双主复制，也就是可以互做主从复制，每个 master 既是 master，又是另外一台服务器的 salve。这样任何一方所做的变更，都会通过复制应用到另外一方的数据库中。

• 级联复制
  

级联复制模式下，部分 slave 的数据同步不连接主节点，而是连接从节点。

因为如果主节点有太多的从节点，就会损耗一部分性能用于 replication ，那么我们可以让 3~5 个从节点连接主节点，其它从节点作为二级或者三级与从节点连接。这样不仅可以缓解主节点压力，并且对数据一致性没有负面影响。

级联复制解决了一主多从场景下多个从库复制对主库的压力，带来的弊端就是数据同步延迟比较大。

3.主从复制原理

要实施主从复制，必须打开 Master 端的 Binlog 功能，否则无法实现。

整个复制过程实际上就是 Slave 从 Master 获取 binlog 后，再顺序地执行（重放）日志记录的各种操作。

主从复制过程如下：

1. master 将变更记录到二进制日志（binary log）。
2. slave 通过 I/O 线程与 maste 建立长连接，master 为 slave 创建 log dump 线程，将 binlog 发送给 slave。
3. 后续当 binlog 有变动时，log dump 线程会将变动通过 I/O 线程推给 slave。
4. slave I/O 线程将 binlog 写入它的中继日志（relay log）。
5. slave SQL 线程解析中继日志（relay log），将变更应用到从数据库。
   

主从复制涉及三个线程：

• 主节点 log dump 线程

当从节点连接主节点时，主节点会为其创建一个 log dump 线程，用于发送和读取 Binlog 的内容。在读取 Binlog 中的操作时，dump 线程会对主节点上的 Binlog 加锁；当读取完成发送给从节点之前，锁会被释放。主节点会为每一个从节点创建一个 dump 线程。

• 从节点 I/O 线程

当从节点上执行 start slave 命令之后，从节点会创建一个 I/O 线程用来连接主节点，请求主库中更新的 Binlog。I/O 线程接收到主节点的 log dump 线程发来的更新之后，保存到本地中继日志（ relay log）。

• 从节点 SQL 线程

SQL 线程负责读取 relay log 中的内容，解析成具体的操作并执行，最终保证主从数据的一致性。

对于每一个主从连接，都需要这三个线程来完成。当主节点有多个从节点时，主节点会为每一个当前连接的从节点建一个 log dump 线程，而每个从节点都有自己的 I/O 线程和 SQL 线程。

从节点将从主库拉取更新和执行分成独立的两个任务，使用两个线程来完成，这样在执行数据同步任务的时候，不会降低读操作的性能。比如，如果从节点 SQL 线程没有运行，此时 I/O 线程可以很快从主节点获取更新。如果在 SQL 线程执行之前从节点服务停止，至少 I/O 线程已经从主节点拉取到了最新的变更并且保存在本地 relay log 中，当服务再次起来之后就可以完成数据的同步。

4.binlog 三种格式

STATEMENT

STATEMENT 格式 Binlog 记录的是 SQL 语句，而不是行数据。

优点：

• Binlog 文件相对较小。当更新或删除影响许多行时，这将大大减少日志文件所需的存储空间。这也意味着从备份中获取和恢复可以更快地完成。
• 日志文件包含所有变更语句，因此它们可用于审计数据库。

缺点：

• 不够精确，因为某些操作可能无法精确还原。比如使用随机函数或非确定性存储过程。
• 某些 SQL 在恢复时会，需要更多的行级锁，影响恢复效率。

INSERT ... SELECT
UPDATE ... WHERE 没有命中索引导致锁表
1
2

ROW

在 ROW 模式下，Binlog 记录的是实际行数据的更改。具体来说，它会记录哪些行被插入、更新或删除，以及这些行的新值。

优点：

• 复制数据非常精确，不会出现非确定函数或存储过程、存储函数、触发器的调用导致数据不一致。
• 某些类型的语句，恢复时需要更少的行锁，从而实现更高的并发性。

INSERT ... SELECT
INSERT statements with AUTO_INCREMENT
UPDATE or DELETE statements with WHERE clauses that do not use keys or do not change most of the examined rows.
1
2
3

缺点：

• 但生成的 Binlog 文件通常较大，比如 UPDATE 或 DELETE 操作。
• 在某些情况下可能会影响主库的性能，尤其是在大量更新操作时。

MIXED

STATEMENT 和 ROW 格式各有优缺点，MIXED 格式结合了二者的优点，在保证「数据完整性」的情况下提供最佳的「复制性能」。

MIXED 格式会根据具体情况来选择使用 ROW 记录或 STATEMENT 记录。这意味着对于某些更改，它将记录每一行数据的变化；而对于其他更改，它将记录执行的 SQL 语句。

这种模式在保持精确的同时，可以减小 Binlog 文件的大小。

从 MySQL 5.1 版本开始，MIXED 成为了默认的 binlog 格式，以兼顾 STATEMENT 和 ROW 两种格式的优点。

5.主从复制方式

5.1 异步复制

MySQL 主从复制默认是异步复制。

主数据库执行写操作后，并将变更写入 binlog，不等待从数据库应用这些变更，而是立即向客户端返回结果。

后续 master 通过 log dump 线程将 binlog 并发送给 slave。slave 把 binlog 存储到本地的 relay log 中，然后执行 relay log 的更新内容。

这个过程是异步的，所以称为异步复制。

这样就会有一个问题，主节点崩溃，此时主节点上已经提交的事务可能并没有传到从节点上。如果此时强行将从提升为主，可能导致新主节点上的数据不完整。

5.2 全同步复制

当主库执行完一个事务，然后所有的从都复制了该事务的 binlog 并写到 relay log，主库才返回成功信息给客户端。

因为需要等待所有从库执行完该事务才能返回成功，所以全同步复制的性能必然会受到严重的影响。

5.3 半同步复制

介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回客户端，而是等待至少一个从库接收到 binlog 并写到 relay log 中才返回成功信息给客户端，保证主库的 binlog 至少传输到了一个从节点上。

相对于异步与同步复制，半同步复制是对性能与数据一致性的权衡，保证主从最终一致。

半同步复制提高了数据的安全性，一定程度上保证了数据能成功备份到从库，同时它也造成了一定程度的延迟，但是比全同步模式延迟要低，这个延迟最少是一个 TCP/IP 往返的时间。所以，半同步复制最好在低延时的网络中使用。

半同步模式不是 MySQL 内置的，从 MySQL 5.5 开始集成，需要 master 和 slave 安装插件开启半同步模式。

6.主从复制问题

数据丢失

当主库宕机后，数据可能丢失。

解决方法：使用半同步复制方式，可以解决数据丢失的问题。

同步延迟

主从延迟来自两个方面：从库进行 binlog 复制，从库日志回放。

从库复制 binlog 这个主要影响是网络带宽和网络稳定性，只能提高带宽来解决，没有什么更好的方式，所以这里更多讨论从库回放日志阶段导致的主从延迟。

从库一般是单线程重放 relay log，所以如果主库写并发较大，可能导致从库单线程重放 SQL 压力较大，主从复制延迟较高。

所以优化思路就有2个，降低主库写并发和多线程重放 SQL，提高重放效率。

（1）水平分库（降低主库写并发）

水平分库后单个分库的数据量降低，单个分库的写并发降低，从而降低从库重放 SQL 的排队时延，因而降低延迟。

（2）从库并行复制

升级至 MySQL 5.7 版本使用并行复制，官方称为 Enhanced Multi-threaded Slaves，即多线程重放 SQL，提高重放效率。

读写分离问题

主从同步有延迟，这个延迟期间读从库，会读到不一致的数据。

方法一：忽略。

大觉部分业务场景对主从同步延迟不敏感，如果业务可以接受，直接忽略。

方法二：放弃读写分离，强制读主。

读和写都落到主库上，在业务层面采用缓存来提升系统读性能。

方法三：选择性读主。

可以利用一个缓存 key 标记那些不容许主从不一致，也就是必须读主的数据，发生了更新，且设置缓存 key 的超时时间，超时时间设置为“主从同步时延”。同步延迟期间读主，同步完成后读从。

7.主从复制是推还是拉？

binlog 的同步可以是 slave 向 master 拉取（pull），也可以是 master 向 slave 推送（push），应该选择哪种方式？

“推”是指 MySQL 主库在有数据更新时推送变更给从库，这种方式只有在数据有变更的时候才会发生，资源消耗少，同步及时。

“拉”是指 MySQL 从库定期询问主库是否有数据更新，这种方式频繁询问，资源消耗多，效率低且同步延迟大。

那么 MySQL 具体是怎么同步 binlog 的呢？

slave 与 master 建立连接之后，会把当前哪个 binlog 文件（MASTER_LOG_FILE）和具体偏移位置（MASTER_LOG_POS) 告诉 master。对应的，主库会启动一个 log dump 线程，根据传过来的（file，pos）在本地的binlog中查找，并把剩下的 binlog 发送给slave。这个过程是 pull 模式。

当主从数据一致之后，master 收到的修改类操作，都会实时传播（propagate）给 slave，此时属于 push 模式。

所以 MySQL 主从复制是推拉结合。

---

参考文献

17.2 Replication Implementation - MySQL
看完这篇还不懂MySQL主从复制，可以回家躺平了 - 腾讯云
主从同步中的关键技术解析 - 腾讯云
主从不一致解决方案&& 如何降低主从延迟 - 阿里云
MySQL主从不一致情形与解决方法原创 - CSDN