MySQL主从复制的常见拓扑、原理分析以及如何提高效率

一、主从复制搭建方法参考

MySQL5.6 数据库主从（Master/Slave）同步安装与配置详解

二、Mysql 主从复制的常用拓扑结构

2.1、一主一从

是最基础的复制结构，用来分担之前单台数据库服务器的压力，可以进行读写分离。

2.2、一主多从

一台 Slave 承受不住读请求压力时，可以添加多台，进行负载均衡，分散读压力。

还可以对多台 Slave 进行分工，服务于不同的系统，例如一部分 Slave 负责网站前台的读请求，另一部分 Slave 负责后台统计系统的请求。

因为不同系统的查询需求不同，对 Slave 分工后，可以创建不同的索引，使其更好的服务于目标系统。

2.3、双主复制

Master 存在下线的可能，例如故障或者维护，需要把 Slave 切换为 Master。

在原来的 Master 恢复可用后，由于其数据已经不是最新的了，不能再做主，需要做为 Slave 添加进来。

那么就需要对其重新搭建复制环境，需要耗费一定的工作量。

双主结构就是用来解决这个问题的，互相将对方作为自己的 Master，自己作为对方的 Slave 来进行复制，但对外来讲，还是一个主和一个从。

当 主Master 下线时，备Master 切换为 主Master，当原来的 主Master 上线后，因为他记录了自己当前复制到对方的什么位置了，就会自动从之前的位置开始重新复制，不需要人为地干预，大大提升了效率。

2.4、级联复制

当直接从属于 Master 的 Slave 过多时，连到 Master 的 Slave IO 线程就比较多，对 Master 的压力是很大的。

级联结构就是通过减少直接从属于 Master 的 Slave 数量，减轻 Master 的压力，分散复制请求，从而提高整体的复制效率。

2.5、双主级联

级联复制结构解决了 Slave 过多导致的瓶颈问题，但还是有单主结构中切换主时的维护问题。

那么为了解决这个问题，就可以加入上面的双主结构。

在必要时，可以再对 Slaves 进行分级。

Mysql 的复制结构有很多种方式，复制的最大问题是数据延时，选择复制结构时需要根据自己的具体情况，并评估好目标结构的延时对系统的影响。

三、Mysql 主从复制过程及原理

3.1、Binary Log 简单介绍

因为Binlog dump 线程操作的文件是bin-log 日志文件，并且实现主从复制在主服务器上主要依靠bin-log日志文件，所以我们简单介绍一下bin-log日志文件。

3.2、原理

MySQL的Replication（英文为复制）是一个多MySQL数据库做主从同步的方案，特点是异步复制，广泛用在各种对MySQL有更高性能、更高可靠性要求的场合。与之对应的是另一个同步技术是MySQL Cluster，但因为MySQL Cluster配置比较复杂，所以使用者较少。

MySQL Replication 就是从服务器拉取主服务器上的 二进制日志文件，然后再将日志文件解析成相应的SQL语句在从服务器上重新执行一遍主服务器的操作，通过这种方式来保证数据的一致性。

MySQL的Replication是一个异步复制的过程（mysql5.1.7以上版本分为异步复制和半同步两种模式），它是从一个Mysql instance（instance英文为实例）(我们称之为Master)复制到另一个Mysql instance(我们称之slave)。

3.3、三个线程

在master与slave之间实现整个复制过程主要由三个线程来完成：

1、Slave SQL thread线程，在slave端

2、Slave I/O thread线程，在slave端

3、Binlog dump thread线程(也可称为IO线程)，在master端

注意：如果一台主服务器配两台从服务器那主服务器上就会有两个Binlog dump 线程，而每个从服务器上各自有两个线程。

要实现MySQL的Replication，首先必须打开master端的binlog (mysql-bin.xxxxxx)日志功能，否则无法实现mysql的主从复制。因为mysql的整个主从复制过程实际上就是：slave端从master端获取binlog日志，然后再在自己身上完全顺序的执行该日志中所记录的各种SQL操作。有关具体如何开启mysql的binlog日志功能，请大家自己在网上搜。

3.4、主从复制流程

MySQL主从复制的基本交互过程，如下：

1、slave端的IO线程连接上master端，并请求从指定binlog日志文件的指定pos节点位置(或者从最开始的日志)开始复制之后的日志内容。

2、master端在接收到来自slave端的IO线程请求后，通知负责复制进程的IO线程，根据slave端IO线程的请求信息，读取指定binlog日志指定pos节点位置之后的日志信息，然后返回给slave端的IO线程。该返回信息中除了binlog日志所包含的信息之外，还包括本次返回的信息在master端的binlog文件名以及在该binlog日志中的pos节点位置。

3、slave端的IO线程在接收到master端IO返回的信息后，将接收到的binlog日志内容依次写入到slave端的relaylog文件(mysql-relay-bin.xxxxxx)的最末端，并将读取到的master端的binlog文件名和pos节点位置记录到master-info（该文件存slave端）文件中，以便在下一次读取的时候能够清楚的告诉master“我需要从哪个binlog文件的哪个pos节点位置开始，请把此节点以后的日志内容发给我”。

4、slave端的SQL线程在检测到relaylog文件中新增内容后，会马上解析该log文件中的内容。然后还原成在master端真实执行的那些SQL语句，并在自身按顺丰依次执行这些SQL语句。这样，实际上就是在master端和slave端执行了同样的SQL语句，所以master端和slave端的数据完全一样的。

以上mysql主从复制交互过程比较拗口，理解起来也比较麻烦，我简化了该交互过程。如下：

1、master在执行sql之后，记录二进制log文件（bin-log）。

2、slave连接master，并从master获取binlog，存于本地relay-log中，然后从上次记住的位置起执行SQL语句，一旦遇到错误则停止同步。

从以上mysql的Replication原理可以看出：

主从间的数据库不是实时同步，就算网络连接正常，也存在瞬间主从数据不一致的情况。

如果主从的网络断开，则从库会在网络恢复正常后，批量进行同步。

如果对从库进行修改数据，那么如果此时从库正在在执行主库的bin-log时，则会出现错误而停止同步，这个是很危险的操作。所以一般情况下，我们要非常小心的修改从库上的数据。

一个衍生的配置是双主、互为主从配置，只要双方的修改不冲突，则可以工作良好。

如果需要多主库的话，可以用环形配置，这样任意一个节点的修改都可以同步到所有节点。

3.5、整体过程就是：

MySQL 复制基于主服务器在二进制日志中跟踪所有对数据库的更改(更新、删除等等)。每个从服务器从主服务器接收主服务器已经记录到其二进制日志的保存的更新，以便从服务器可以对其数据拷贝执行相同的更新。

将主服务器的数据拷贝到从服务器的一个途径是使用LOAD DATA FROM MASTER语句。请注意LOAD DATA FROM MASTER目前只在所有表使用MyISAM存储引擎的主服务器上工作。并且，该语句将获得全局读锁定。

MySQL 使用3个线程来执行复制功能,其中1个在主服务器上，另两个在从服务器上。当发出START SLAVE时，从服务器创建一个I/O线程，以连接主服务器并让它发送记录在其二进制日志中的语句。

主服务器创建一个线程，即I/O线程，将二进制日志中的内容发送到从服务器。该线程可以识别为主服务器上SHOW PROCESSLIST的输出中的Binlog Dump线程。

从服务器I/O线程读取主服务器Binlog Dump线程发送的内容并将该数据拷贝到从服务器数据目录中的本地文件中，即中继日志。

第3个线程是SQL线程，是从服务器创建用于读取中继日志并执行日志中包含的更新。

有多个从服务器的主服务器创建为每个当前连接的从服务器创建一个线程；每个从服务器有自己的I/O和SQL线程。

四、MySQL支持的复制类型及其优缺点

bin-log 日志文件有两种格式，一种是Statement-Based，另一种是Row-Based。

（１）：基于语句的复制（Statement-Based）： 在主服务器上执行的SQL语句，在从服务器上执行同样的语句。MySQL默认采用基于语句的复制，效率比较高。 一旦发现没法精确复制时，会自动选着基于行的复制。

（２）：基于行的复制（Row-Based）：把改变的内容复制过去，而不是把命令在从服务器上执行一遍. 从mysql5.0开始支持

（３）：混合类型的复制: 默认采用基于语句的复制，一旦发现基于语句的无法精确的复制时，就会采用基于行的复制。

4.1、Statement-Based优点和缺点分析

（编辑：常州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!