主从复制

## 1 什么是主从复制

1. MySQL 主从复制是指数据可以**从一个 MySQL 数据库服务器主节点复制到一个或多个从节点**。
2. **默认采用异步复制方式**，这样**从节点不用一直访问主服务器来更新自己的数据**，**数据的更新可以在远程连接上进行**，**从节点可以复制主数据库中的所有数据库或者特定的数据库**，**或者特定的表**。

## 2 为什么要主从复制

1. **读写分离**：
   1. 在开发工作中，有时候会遇见某个 SQL 语句需要锁表，导致暂时不能使用读的服务，这样就会影响现有业务。
   2. 使用主从复制，让**主库负责写**，**从库负责读**，这样，**即使主库出现了锁表的情景**，**通过读从库也可以保证业务的正常运作**。
2. **数据实时备份**：
   1. 当系统中**某个节点发生故障**时，可以**方便**的**故障切换**。
3. **高可用 HA**。
4. **架构扩展**：
   1. 随着系统中业务访问量的增大，如果是**单机部署数据**库，就会导致**I/O 访问频率过高**。
   2. 有了主从复制，**增加多个数据存储节点**，**将负载分布在多个从节点上**，**降低单机磁盘 I/O 访问的频率**，**提高单个机器的 I/O 性能**。

## 3 常见架构模型

### 3.1 一主一从/一主多从

1. 一主一从和一主多从是最常见的主从架构模式，一般实现主从配置或者读写分离都可以采用这种架构。
2. 如果是**一主多从模式**，当 `b`**增加到一定数量时**，**`Slave` 对 `Master` 的负载以及网络带宽都会成为一个严重的问题**。![1](/media/202107/2021-07-08_1725220.4615627563605139.png)

### 3.2 多主一从

1. MySQL 5.7 开始支持多主一从的模式，将多个库的数据备份到一个库中存储。![1](/media/202107/2021-07-08_1727100.08125400952718176.png)

### 3.3 双主复制

1. 理论上跟主从一样，但是**两个 MySQL 服务器互做对方的从**，**主从相互授权连接**，**读取对方 Binlog 日志并更新到本地数据库**，**只要对方数据改变**，**自己就跟着改变**。
2. **双主适用于写压力比较大的场景**，或者**DBA 做维护需要主从切换的场景**，通过双主架构**避免了重复搭建从库的麻烦**。

### 3.4 级联复制

1. 级联模式下因为涉及到的 `Slave` 节点很多，所以如果都连在 `Master` 上对主服务器的压力肯定是不小的，所以部分 `Slave` 节点连接到他上一级的从节点上，这样就缓解了主服务器的压力。
2. 级联复制解决了一主多从场景下**多个从库复制对方从库的压力**，带来的弊端就是**数据同步延迟比较大**。![1](/media/202107/2021-07-09_0959180.38642972342568416.png)

## 4 主从复制原理

主从复制涉及到三个线程：

1. 一个在**主节点的线程**：
   1. `Log Dump Thread`，主要用来**给从库 `I/O Thread` 传 Binlog 数据**。
2. 两个在**从库的线程**：
   1. 一个 `I/O Thread`，主要用于**请求主库的 Binlog**，并**将得到的 Binlog 写到本地的 Relay Log**（中继日志）**文件中**。
   2. 一个 `SQL Thread`，主要用于**读取 Relay Log 文件中的日志**，并**解析成 SQL 语句逐一执行**。

![4](/media/202107/2021-07-09_1002500.6522393134425326.png)

3. **Log Dump Thread：**
   
   1. 当**从节点连接主节点**时，**主节点会为其创建一个 Log Dump Thread**，**用于发送和读取 Binlog 的内容**。
   2. 在**读取 Binlog 的操作中**，**Log Dump Thread 会对主节点上的 Binlog 加锁**，当**读取完成发送给从节点之前**，**锁会被释放**。
   3. 主节点会**为自己的每一个从节点创建一个 Log Dump Thread**。
4. **I/O Thread：**
   
   1. 当从节点上执行 `start slave` 命令之后，从节点会**创建一个 `I/O Thread` 用来连接主节点**，**请求主库中更新的 Binlog**。
   2. **`I/O Thread` 接收到主节点的 `Log Dump Thread` 进程发来的更新之后**，**保存在 Relay Log 中**。
5. **SQL Thread：**
   
   1. SQL Thread 负责**读取 Relay Log 中的内容**，**解析成具体的操作并执行**，最终**保证主从数据的一致性**。
6. **Relay Log：**
   
   1. MySQL 进行**主主复制**或**主从复制**的时候会在要**复制的服务器下面产生相应的 Relay Log**。
   2. **从服务器 `I/O Thread` 将主服务器的 Binlog 日志读取过来**，**解析到各类 Events 之后记录到从服务器本地文件**，**这个文件就被称为 Relay Log**。
   3. 然后 `SQL Thread`**会读取 Relay Log 日志的内容并应用到从服务器**，从而**使从服务器和主服务器的数据保持一致**。
   4. Relay Log**充当缓冲区**，这样 `Master` 就不必等到 `Slave` 执行完成才发送下一个事件。
   5. Relay Log 相关参数：
      1. 查询方式：
         
         ```shell
         mysql> show variables like '%relay%';
         +---------------------------+--------------------------------------------+
         | Variable_name             | Value                                      |
         +---------------------------+--------------------------------------------+
         | max_relay_log_size        | 0                                          |
         | relay_log                 |                                            |
         | relay_log_basename        | /www/server/data/ecs-q9gui-relay-bin       |
         | relay_log_index           | /www/server/data/ecs-q9gui-relay-bin.index |
         | relay_log_info_file       | relay-log.info                             |
         | relay_log_info_repository | FILE                                       |
         | relay_log_purge           | ON                                         |
         | relay_log_recovery        | OFF                                        |
         | relay_log_space_limit     | 0                                          |
         | sync_relay_log            | 10000                                      |
         | sync_relay_log_info       | 10000                                      |
         +---------------------------+--------------------------------------------+
         ```
      2. `max_relay_log_size`：
         
         1. **标记 Relay Log 允许的最大值**。
         2. 如果该值为 0，则默认值为 `max_binlog_size(1G)`。
         3. 如果不为 0，则 `max_relay_log_size` 为最大的 Relay Log 文件大小。
      3. `relay_log_purge`：
         
         1. **是否自动清空不再需要的中继日志**，默认为 1（启用）。
      4. `relay_log_recovery`：
         
         1. 当**`Slave` 从库宕机后**，**假如 Relay Log 损坏了**，**导致一部分中继日志没有处理**，则**自动放弃所有未执行的 Relay Log**，并且**重新从 `Master` 上获取日志**，这样就**保证了 Relay Log 的完整性**。
         2. 默认情况下该功能是关闭的，将 `relay_log_recovery` 的值设置为 1 时，可在 `Slave` 从库上开启该功能，建议开启。
      5. `relay_log_space_limit`：
         
         1. **防止中继日志写满磁盘**，这里**设置中继日志最大限额**。
         2. 此设置**存在主库崩溃**，**从库中继日志不全的情况**，**不到万不得已**，**不推荐使用**。
      6. `sync_relay_log`：
         
         1. 这个参数**和 Binlog 中的 `sync_binlog` 作用相同**。
         2. 当**设置为 1 时**，`Slave`**的 `I/O Thread` 每次接收到 `Master` 发送过来的 Binlog 日志都要写入系统缓冲区**，然后**刷入 Relay Log 中继日志里**，这样是**最安全**的，因为在**崩溃的时候**，我们**最多丢失一个事务**，但**会造成磁盘的大量 I/O**。
         3. 当**设置为 0 时**，并**不是马上就刷入中继日志里**，而是**由操作系统决定何时来写入**，虽然**安全性降低了**，但**减少了大量的磁盘 I/O 操作**。
         4. 这个值**默认是 0**，可动态修改，建议采取默认值。
      7. `sync_relay_log_info`：
         
         1. 这个参数**和 Binlog 中的 `sync_binlog` 作用相同**。
         2. 当**设置为 1 时**，`Slave`**的 `I/O Thread` 每次接收到 `Master` 发送过来的 Binlog 日志都要写入系统缓冲区**，然后**刷入 `relay-log.info` 里**，这样是**最安全**的，因为在**崩溃的时候**，我们**最多丢失一个事务**，但**会造成磁盘的大量 I/O**。
         3. 当**设置为 0 时**，并**不是马上就刷入 `relay-log.info` 里**，而是**由操作系统决定何时来写入**，虽然**安全性降低了**，但**减少了大量的磁盘 I/O 操作**。
         4. 这个值**默认是 0**，可动态修改，建议采取默认值。
7. 对于**每一个主从连接**，都**需要这三个进程来完成**，当**主节点有多个从节点时**，**主节点会为每一个当前连接的从节点创建一个 `Log Dump Thread`**，而**每个从节点都有自己的 `I/O Thread`**、**`SQL Thread`**。
8. **从节点用两个线程将从主库拉取更新和执行分成独立的任务**，这样**在执行同步数据任务的时候**，**不会降低读操作的性能**，比如：
   
   1. 如果从节点没有运行，此时 `I/O Thread` 可以很快从主节点获取更新，尽管 `SQL Thread` 还没有执行。
   2. 如果在 `SQL Thread` 执行之前从节点服务停止，至少 `I/O Thread` 已经从主节点拉取到了最新的变更并且保存在本地 Relay Log 中，当服务再次起来之后就可以完成数据的同步。

## 5 复制的基本过程

> 要实施复制，首先**必须打开 `Master` 端的 Binlog 功能**，否则无法实现，因为整个复制过程实际上就是 `Slave` **从 `Master` 端获取该日志**，**然后再在自己身上完全顺序的执行日志中所记录的各种操作**。

![5](/media/202107/2021-07-09_1101440.00551414399379524.png)

1. 在从节点执行 `start slave` 命令**开启主从复制**开关，**开始进行主从复制**，**从节点上的 `I/O Thread` 连接主节点**，并**请求从指定日志文件的指定位置**（或者从最开始的日志）**之后的日志内容**。
2. **主节点接收到来自从节点的 I/O 请求后**，**通过负责复制的 `Log Dump Thread` 根据请求信息读取指定日志指定位置之后的日志信息**，**返回给从节点**，**返回信息中除了日志所包含的信息之外**，**还包括本次返回的信息的 Binlog File 以及 Binlog Position**（Binlog 下一个数据读取位置）。
3. **从节点的 `I/O Thread` 接收到主节点发送过来的日志内容**、**日志文件及位置点后**，**将接收到的日志内容更新到本机的 Relay Log 文件的最末端**，并**将读取到的 Binlog 文件名和位置保存到 `master-info` 文件中**，**以便在下一次读取的时候能够清楚的告诉 `Master`**“我**需要从哪个 Binlog 的哪个位置开始往后的日志内容**，请发送给我”。
4. **`Slave` 的 `SQL Thread` 检测到 Relay Log 中新增加了内容后**，会**将 Relay Log 的内容解析成能够执行的 SQL 语句**，然后**在本数据库中按照解析出来的顺序执行**，并**在 `relay-log.info` 中记录当前应用中继日志的文件名和位置点**。

## 6 复制的模式

> MySQL 主从复制**默认是异步的模式**。

### 6.1 异步模式（Async Mode）

![6](/media/202107/2021-07-09_1115530.729759596392375.png)

1. 这种模式下，**主节点不会主动推送数据到从节点**，主库在**执行完客户端提交的事务后会立即将结果返回给客户端**，并**不关心从库是否已经接收并处理**。
2. 这样就会**有一个问题**，**主节点如果崩溃掉了**，此时**主节点上已经提交的事务可能并没有传到从节点上**，**如果此时强行将从提升为主**，**可能导致新主节点上的数据不完整**。

### 6.2 半同步模式（Semi Sync Mode）

![7](/media/202107/2021-07-09_1121140.055395934571049965.png)

1. **介于异步复制和全同步复制之间**，**主库在执行完客户端提交的事务后不是立刻返回给客户端**，**而是等待至少一个从库接收到并写到 Relay Log 中才返回成功信息给客户端**（**只能保证主库的 Binlog 至少传输到了一个从节点上**），**否则需要等待直到超时时间然后切换成异步模式再提交**。
2. 相对于异步复制，半同步复制**提高了数据的安全性**，一定程度的**保证了数据能成功备份到从库**。
3. 同时他也**造成了一定程度的延迟**，但是**比全同步模式延迟要低**，这个延迟**至少是一个 TCP/IP 往返的时间**，所以，半同步复制**最好在低延时的网络中使用**。
4. **半同步模式不是 MySQL 内置的**，**从 MySQL 5.5 开始集成**，**需要 `Master` 和 `Slave` 安装插件开启半同步模式**。

### 6.3 全同步模式

1. 指当**主库执行完一个事务**，然后**所有的从库都复制了该事务并成功执行完才返回成功信息给客户端**。
2. 因为**需要等待所有从库执行完该事务才能返回成功信息**，所以全同步复制的**性能必然会受到严重的影响**。

## 7 主从复制可能会出现的问题

### 7.1 Slave 同步延迟

1. 因为 **Slave 端是通过 `I/O Thread` 单线程来实现数据解析入库**，而**Master 端写 Binlog 是顺序写效率很高**，因此**当主库的 TPS 很高的时候**，必然**Master 端的写效率要高过 Slave 端的读效率**，这时候就有**同步延迟**的问题。
2. `I/O Thread` 的同步是基于库的，即同步几个库就会开启几个 `I/O Thread`，可以通过 `show slave status` 命令查看 `Seconds_Behind_Master` 的值来看是否出现同步延迟，这个值代表**主从同步延迟的时间**，值为**0 表示正常情况**，**正值表示已经出现延迟**，**值越大说明延迟越严重**，**从库落后主库也就越多**。

## 参考文献

1. [什么是主从复制？实现原理是什么？](https://github.com/wolverinn/Waking-Up/blob/master/Database.md#%E4%BB%80%E4%B9%88%E6%98%AF%E4%B8%BB%E4%BB%8E%E5%A4%8D%E5%88%B6%E5%AE%9E%E7%8E%B0%E5%8E%9F%E7%90%86%E6%98%AF%E4%BB%80%E4%B9%88)
2. [深度探索 MySQL 主从复制原理](https://zhuanlan.zhihu.com/p/50597960)。
3. [MySQL 主从复制原理不再难](https://www.cnblogs.com/rickiyang/p/13856388.html)。
4. [深入了解 MySQL 主从复制的原理](https://segmentfault.com/a/1190000038967218)。