你了解MySQL 主从复制吗？

淩亂°似流年 2023-01-23 07:59 223阅读 0赞

**目录**

1.背景

2.主从复制的形式

3.原理

4.过程

5.类型

5.方式

6.配置

7.问题

8.注意事项

9.作用

10.应用场景

--------------------

## 1.背景 ##

随着业务的增加，如果单单靠一台服务器的话，负载过重，就容易造成**宕机，**这样我们保存在 MySQL 数据库的数据就会丢失，那么该怎么解决呢？

其实在 MySQL 本身就自带有一个主从复制的功能，可以帮助我们实现**负载均衡和读写分离**。

对于主服务器（Master）来说，主要负责写，从服务器（Slave）主要负责读，这样的话，就会大大减轻压力，从而提高效率。

主服务器只负责写，而从服务器只负责读，从而提高了效率减轻压力。

**主从复制可以分为：**

*  主从同步：当用户写数据主服务器必须和从服务器**同步了**才告诉用户写入成功，等待时间比较长。
 *  主从异步：只要用户**访问**写数据主服务器，立即返回给用户。
 *  主从半同步：当用户访问写数据主服务器写入并同步**其中一个从服务器**就返回给用户成功。

## **2.主从复制的形式** ##

**一主一从：**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzMzNzE4NTYz_size_16_color_FFFFFF_t_70][]

**一主多从：**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzMzNzE4NTYz_size_16_color_FFFFFF_t_70 1][]

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

**多主一从：**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzMzNzE4NTYz_size_16_color_FFFFFF_t_70 2][]

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

**双主复制：**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzMzNzE4NTYz_size_16_color_FFFFFF_t_70 3][]

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

**级联复制**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzMzNzE4NTYz_size_16_color_FFFFFF_t_70 4][]

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

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

## **3.原理** ##

MySQL主从复制是基于主服务器在二进制日志跟踪所有对数据库的更改。因此，要进行复制，必须在主服务器上启动二进制日志。

每个从服务器从主服务器接收已经记录到日志的数据。当一个从服务器连接到主服务器时，它通知主服务器从服务器日志中读取最后一个更新成功的位置。

从服务器接收从那时发生起的任何更新，并在主机上执行相同的更新。然后封锁等待主服务器通知的更新。

从服务器执行备份不会干扰主服务器，在备份过程中主服务器可以继续处理更新。

## **4.过程** ##

**工作过程**

MySQL的主从复制过程大致如下：

1.从库生成两个线程，一个I/O线程，一个SQL线程；

2.I/O线程去请求主库的binlog，并将得到的binlog日志写到relay log（中继日志）文件中；

3.主库会生成一个log dump线程， 用来给从库I/O线程传binlog；

4.SQL线程会读取relay log文件中的日志，并解析成具体操作，来实现主从的操作一致，而最终数据一致。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzMzNzE4NTYz_size_16_color_FFFFFF_t_70 5][]

**请求流程：**

MySQL 建立请求的主从的详细流程如下：

1.当从服务器连接主服务器时，主服务器会创建一个 log dump 线程，用于发送 binlog 的内容。在读取 binlog 的内容的操作中，会对主节点上的 binlog **加锁**，当读取完成并发送给从服务器后解锁。

2.当从节点上执行 `start slave` 命令之后，从节点会创建一个 IO 线程用来连接主节点，请求主库中**更新 **binlog。IO 线程接收主节点 binlog dump 进程发来的更新之后，保存到 relay-log 中。

3.从节点 SQL 线程负责读取 realy-log 中的内容，**解析**成具体的操作执行，最终保证主从数据的一致性。

## **5.类型** ##

**异步复制**

一个主库，一个或多个从库，数据**异步同步**到从库。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzMzNzE4NTYz_size_16_color_FFFFFF_t_70 6][]

这种模式下，主节点**不会主动推送数据**到从节点，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理。

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

**同步复制**

在 MySQL cluster 中特有的复制方式。

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

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

**半同步复制**

在异步复制的基础上，确保任何一个主库上的事物在提交之前**至少有一个从库**已经收到该事物并日志记录下来。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzMzNzE4NTYz_size_16_color_FFFFFF_t_70 7][]

介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待**至少一个从库接收到并写到** relay log 中才返回成功信息给客户端(只能保证主库的 Binlog 至少传输到了一个从节点上)，否则需要等待直到**超时时间**然后切换成异步模式再提交。

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

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

**延迟复制**

在异步复制的基础上，人为设定主库和从库的数据**同步延迟时间**，即保证数据延迟至少是这个参数。

## 6.方式 ##

MySQL 主从复制支持两种不同的日志格式，这两种日志格式也对应了各自的复制方式。当然也有二者相结合的混合类型复制。

**语句复制**

基于语句的复制相当于**逻辑复制**，即二进制日志中记录了操作的语句，通过这些语句在从数据库中**重放**来实现复制。

这种方式简单，二进制文件小，传输带宽占用小。但是基于语句更新依赖于其它因素，比如插入数据时利用了时间戳。

因此在开发当中，我们应该尽量将业务逻辑逻辑放在**代码层**，而不应该放在 MySQL 中，不易拓展。

**特点：**

*  传输效率高，减少延迟。
 *  在从库更新不存在的记录时，语句赋值不会失败。而行复制会导致失败，从而更早发现主从之间的不一致。
 *  设表里有一百万条数据，一条sql更新了所有表，基于语句的复制仅需要发送一条sql，而基于行的复制需要发送一百万条更新记录。

**行数据复制**

基于行的复制相当于**物理复制**，即二进制日志中记录的实际更新数据的每一行。

这样导致复制的压力比较大，日志占用的空间大，传输带宽占用大。但是这种方式比基于语句的复制要更加**精确**。

**特点：**

*  不需要执行查询计划。
 *  不知道执行的到底是什么语句。
 *  例如一条更新用户总积分的语句，需要统计用户的所有积分再写入用户表。如果是基于语句复制的话，从库需要再一次统计用户的积分，而基于行复制就直接更新记录，无需再统计用户积分。

**混合类型的复制**

一般情况下，默认采用**基于语句**的复制，一旦发现基于语句无法精确复制时，就会采用基于行的复制。

## 7.配置 ##

配置主要要点如下：

# 如果在双主复制结构中没有设置ID的话就会导致循环同步问题
    server_id=1
    
    # 即日志中记录的是语句还是行更新或者是混合
    binlog_format=mixed
    
    # 在进行n次事务提交以后，Mysql将执行一次fsync的磁盘同步指令。将缓冲区数据刷新到磁盘。
    # 为0的话由Mysql自己控制频率。
    sync_binlog=n
    
    # 为0的话，log buffer将每秒一次地写入log file中并且刷新到磁盘。
    # mysqld进程崩溃会丢失一秒内的所有事务。
    # 为1的话，每次事务log buffer会写入log file并刷新到磁盘。（较为安全）
    # 在崩溃的时候,仅会丢失一个事务。
    # 为2的话，每次事务log buffer会写入log file，但一秒一次刷新到磁盘
    innodb_flush_logs_at_trx_commit=0
    
    # 阻止从库崩溃后自动启动复制，给一些时间来修复可能的问题，
    # 崩溃后再自动复制可能会导致更多的问题。并且本身就是不一致的
    skip_slave_start=1 
    
    # 是否将从库同步的事件也记录到从库自身的bin-log中
    # 允许备库将重放的事件也记录到自身的二进制日志中去，可以将备库当做另外一台主库的从库
    log_slave_update 
    
    # 日志过期删除时间，延迟严重的话会导致日志文件占用磁盘
    expire_logs_days=7

## 8.问题 ##

**延迟**

当主库的 TPS 并发较高的时候，由于主库上面是多线程写入的，而从库的SQL线程是单线程的，导致从库SQL可能会跟不上主库的**处理速度**。

**解决方法：**

*  网络方面：尽量保证主库和从库之间的**网络稳定**，延迟较小；
 *  硬件方面：从库**配置更好**的硬件，提升随机写的性能；
 *  配置方面：尽量使 MySQL 的操作在**内存中完成**，减少磁盘操作。或升级 MySQL5.7 版本使用并行复制；
 *  建构方面：在事务中尽量对**主库读写**，其它非事务的读在从库。消除一部分**延迟**带来的数据库不一致。**增加缓存**降低一些从库的负载。

**数据丢失**

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

**解决方法：**

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

## 9.注意事项 ##

MySQL 需要注意以下事项：

*  MySQL 主从复制是 MySQL **高可用性，高性能**（负载均衡）的基础；
 *  简单，灵活，部署**方式多样**，可以根据不同业务场景部署不同复制结构；
 *  复制过程中应该时刻**监控**复制状态，复制出错或延时可能给系统造成影响；
 *  MySQL 主从复制目前也存在一些问题，可以根据需要部署**复制增强**功能。

## 10.作用 ##

主从复制带来了很多好处，当我们的主服务器出现问题，可以**切换**到从服务器；可以进行数据库层面的**读写分离**；可以在从数据库上进行日常**备份**。还可以保证：

1.  数据更安全：做了**数据冗余**，不会因为单台服务器的宕机而丢失数据；
2.  性能大大提升：一主多从，不同用户从不同数据库读取，**性能提升**；
3.  扩展性更优：流量增大时，可以方便的**增加**从服务器，不影响系统使用；
4.  负载均衡：一主多从相当于分担了主机任务，做了**负载均衡**。

## 11.应用场景 ##

MySQL 主从复制集群功能使得 MySQL 数据库支持**大规模高并发读写**成为可能，同时有效地保护了物理服务器宕机场景的**数据备份**。

**横向扩展**

将工作负载**分发**到各 Slave 节点上，从而提高系统性能。

在这个场景下，所有的写(write)和更新(update)操作都在 Master 节点上完成；所有的读( read)操作都在 Slave 节点上完成。通过**增加更多**的 Slave 节点，便能提高系统的读取速度。

**数据安全**

数据从 Master 节点复制到 Slave 节点上，在 Slave 节点上可以**暂停**复制进程。可以在 Slave 节点上**备份**与 Master 节点对应的数据，而不用影响 Master 节点的运行。

**数据分析**

实时数据可以在 Master 节点上创建，而分析这些数据可以在 Slave 节点上进行，并且不会对 Master 节点的性能产生影响。

**远距离数据分布**

可以利用复制在远程主机上创建一份本地数据的**副本**，而不用持久的与Master节点连接。

**拆分访问**

可以把几个不同的从服务器，根据公司的**业务**进行拆分。通过拆分可以帮助减轻主服务器的压力，还可以使数据库对外部用户浏览、内部用户业务处理及 DBA 人员的备份等**互不影响**。

参考：[https://mp.weixin.qq.com/s/5-qCk1WX8h8VDDXDNdV9FA][https_mp.weixin.qq.com_s_5-qCk1WX8h8VDDXDNdV9FA]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzMzNzE4NTYz_size_16_color_FFFFFF_t_70]: /images/20221004/063ca33ec75340b5942a3d96d50aeabb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzMzNzE4NTYz_size_16_color_FFFFFF_t_70 1]: /images/20221004/556302da0e5f4cb8a4aa876b0a8dff24.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzMzNzE4NTYz_size_16_color_FFFFFF_t_70 2]: /images/20221004/f7b4d7848a7848ada3295d511f0115f6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzMzNzE4NTYz_size_16_color_FFFFFF_t_70 3]: /images/20221004/55dee368338648aa914f7e5abca86f8a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzMzNzE4NTYz_size_16_color_FFFFFF_t_70 4]: /images/20221004/6e2a42e815df4391898d1a9e6743bf13.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzMzNzE4NTYz_size_16_color_FFFFFF_t_70 5]: /images/20221004/1bb480f1c918481d90103e433d6d221b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzMzNzE4NTYz_size_16_color_FFFFFF_t_70 6]: /images/20221004/65d650390e0a4ed7affbedf5b7efc652.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzMzNzE4NTYz_size_16_color_FFFFFF_t_70 7]: /images/20221004/0f8f630bbaef4cdc93150fc1e3f15227.png
[https_mp.weixin.qq.com_s_5-qCk1WX8h8VDDXDNdV9FA]: https://mp.weixin.qq.com/s/5-qCk1WX8h8VDDXDNdV9FA