搞懂MySQL主从复制原理及搭建过程，只需这篇文章！

主从复制是指将主库的 DDL 和 DML 操作通过二进制日志传到从库服务器中，然后在从库上对这些日志重新执行（也叫重做），从而使得从库和主库的数据保持一致。

MySQL 支持一台主库同时向多台从库进行复制，从库同时也可以作为其他从服务器的主库，实现链状复制。

MySQL 复制的优点，主要包含以下三个方面：

1. 实时灾备，用于故障切换：主库出现问题，可以快速切换到从库提供服务。

2. 读写分离，提供查询服务：实现读写分离，降低主库的访问压力。

3. 备份，避免影响业务：可以在从库中执行备份，以避免备份期间影响主库服务。

1. 主库压力较大扛不住时，可通过主从复制把读压力分担一部分到从库上；

2. 业务高峰数据库连接数太多时，例如高峰的认证，只需要把这个业务分拆到从库上；

3. 低频复杂类且难以优化的 SQL（报表统计分析类的 SQL），专门在从库上执行；

4. 利用从库做高可用切换。

主从复制原理图示

如上图所示，主从复制的过程原理可分为三个部分：

1. 主库汇报数据变更记录在二进制日志文件 binlog 中：

a) 启动（Slave I/O Thread->master.info；Slave SQL Thread，Relay-log.info）；

b) 建立连接（slave I/O Thread->master.info；Master log Dump Thread->binlog ）。

2. 从库连接主库，读取 binlog 日志，并写入自身中继日志 Relay log：

a) 获取更新日志（Master log dump Thread->binlog）；

b) 传递更新日志（Master log dump Thread->binlog；slave I/O Thread->master.info）；

c) 保存更新日志（slave I/O Thread->master.info；slave Relay log）。

1. master 记录二进制日志。在每个事务完成数据更新之前，master 在二进制日志记录这些改变。MySQL 将事务串行地写入二进制日志，完成后，master 通知存储引擎提交事务。

2. slave 将 master 的 binary log 拷贝到它自身的中继日志：

a) 首先，slave 开始一个工作线程：I/O 线程；

b) I/O 线程在 master 上打开一个普通的连接，然后开始 binlog dump process。binlog dump process 从 master 的二进制日志中读取事件（接收的单位是 event），如果已经跟上 master，它会睡眠并等待 master 产生新的事件；

c) I/O 线程将这些事件写入中继日志。

3. SQL slave 重做中继日志

a) Thread（SQL 从线程）是处理该过程的最后一步。SQL 线程从中继日志读取事件，并重放其中的事件（回放的单位也是 event）更新 slave 的数据，使其与 master 中的数据一致。只要该线程与 I/O 线程保持一致，中继日志通常会位于 OS 的缓存中，所以中继日志的开销很小；

b) 在 master 中也有一个工作线程：和其他 MySQL 的连接一样，slave 在 master 中打开一个连接也会使得 master 开始一个线程。

异步复制为 MySQL 默认的复制模式，指主库写 binlog、从库 I/O 线程读 binlog 并写入 relaylog、从库 SQL 线程重放事务这三步之间是异步的。

异步复制的主库不需要关心备库的状态，主库不保证事务被传输到从库，如果主库崩溃，某些事务可能还未发送到从库，切换后可能导致事务的丢失。其优点是可以有更高的吞吐量，缺点是不能保持数据实时一致，不适合要求主从数据一致性要求较高的应用场景。

MySQL 从 5.5 版本开始引入了半同步复制，半同步复制介于异步复制和同步复制之间。主库在提交事务时先等待，必须确认至少一个从库收到了事件（从库将事件写入 relaylog，不需要重放和提交，并向主库发送一个确认信息 ACK），主库收到确认信息后才会正式 commit。

与同步复制相比，半同步复制速度快很多，因为它只需要至少1个从库确认写入 relaylog，并不需要完成在从库上的事务提交，同时又比异步复制更安全，因为主库在提交时，事务至少已经存在2个地方（主库的 binlog 和从库的 relaylog）。

由于半同步复制在提交事务前，需要从库返还确认信息，所以这里涉及到网络的往返通信开销，因此半同步复制只适合在网络条件较好且地理上距离不远的环境部署，否则可能会因为网络延迟大幅降低主库性能。

GTID（Global Transaction Identifiers）是已提交事务的一个编号，是事务的全局唯一编号。GTID 和事务会记录到 binlog 中，用来标识事务。GTID 用于替代以前传统复制方法(binglog+position)，在MySQL 5.6.2 开始支持 GTID。

MySQL 支持 GTID 后，一个事务在集群中就不再孤单，在每一个节点中，如果存在具有相同标识符的情况，可以避免同一个事务，在同一节点中出现多次的情况。

GTID 的出现，最直接的效果就是，每一个事务在集群中具有了唯一性的意义，相对于行复制来讲，数据安全性更高，故障切换更简单。

GTID 由 server_uuid：sequence_Number 组成，其中：

• server_uuid：是 MySQL 实例的全局唯一标识；存放在$datadir/auto.cnf。

• sequence_Number：是 MySQL 内部的事务编号，在一个 MySQL 实例中不会重复。序列号（保证服务器内唯一)，也表示该实例上已经提交事务的数量，并且随着事务提交而递增。

举个例子：server_uuid 存放于“ cat /mysl/data/3306/data/auto.cnf ”，GTID样例如下：

优点：可以很方便地进行故障转移，从库不会丢失主库上的任何修改。

缺点：故障处理比较复杂，对执行的SQL有一定限制。以下三类语句不被执行：

a) create table ... select statements

b) create temporary table or drop temporary table statements inside transactions

c) 同时更新事务引擎和非事务引擎

服务器示例

准备好两台服务器之后，在上述两台服务器中分别安装好 MySQL，并完成基础的初始化准备工作。

MySQL 8下载地址：

https://downloads.mysql.com/archives/community/

一、选择安装的 MySQL 版本

1. 首先判断是否要和公司其他已经安装好的 MySQL 保持版本一致。

2. 如果不是实验新功能性质，则不选择 development release，而是安装 General Availability（GA）release（代表稳定版本，可在生产系统使用）。

二、选择安装 MySQL 的方式

安装方式有2种：二进制安装包的方式(RPM/ZIP/Tar等)、源码方式(source code)。一般会选择二进制安装方式；如果有特殊需求，比如修改一部分源码或修改 MySQL 深层次的配置，则会选择源码方式。

三、二进制 Tar 包安装 MySQL

MySQL 安装步骤如下：

步骤一：解压到 /usr/local 目录，相关脚本如下：

解压后的目录结构

步骤五：修改 MySQL 安装权限，具体如下：

a) 创建 MySQL 软连接