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

MySQL 主从复制原理

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

一个在主节点的线程：log dump thread

从库会生成两个线程：一个 I/O 线程，一个 SQL 线程

如下图所示:

主库会生成一个 log dump 线程,用来给从库 I/O 线程传 Binlog 数据。

从库的 I/O 线程会去请求主库的 Binlog，并将得到的 Binlog 写到本地的 relay log (中继日志)文件中。

SQL 线程,会读取 relay log 文件中的日志，并解析成 SQL 语句逐一执行。

主节点 log dump 线程

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

从节点 I/O 线程

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

relay log

这里又引申出一个新的日志概念。MySQL 进行主主复制或主从复制的时候会在要复制的服务器下面产生相应的 relay log。

relay log 是怎么产生的呢？

从服务器 I/O 线程将主服务器的 Binlog 日志读取过来，解析到各类 Events 之后记录到从服务器本地文件，这个文件就被称为 relay log。然后 SQL 线程会读取 relay log 日志的内容并应用到从服务器，从而使从服务器和主服务器的数据保持一致。中继日志充当缓冲区，这样 master 就不必等待 slave 执行完成才发送下一个事件。

relay log 相关参数查询：

mysql> show variables like '%relay%';

+---------------------------+------------------------------------------------------------+

| Variable_name | Value |

+---------------------------+------------------------------------------------------------+

| max_relay_log_size | 0 |

| relay_log | yangyuedeMacBook-Pro-relay-bin |

| relay_log_basename | /usr/local/mysql/data/yangyuedeMacBook-Pro-relay-bin |

| relay_log_index | /usr/local/mysql/data/yangyuedeMacBook-Pro-relay-bin.index |

| relay_log_info_file | relay-log.info |

| relay_log_info_repository | TABLE |

| relay_log_purge | ON |

| relay_log_recovery | OFF |

| relay_log_space_limit | 0 |

| sync_relay_log | 10000 |

| sync_relay_log_info | 10000 |

+---------------------------+------------------------------------------------------------+

11 rows in set (0.03 sec)

max_relay_log_size

标记 relay log 允许的最大值，如果该值为 0，则默认值为 max_binlog_size(1G)；如果不为 0，则 max_relay_log_size 则为最大的 relay_log 文件大小。

relay_log_purge

是否自动清空不再需要中继日志时。默认值为 1(启用)。

relay_log_recovery

当 slave 从库宕机后，假如 relay log 损坏了，导致一部分中继日志没有处理，则自动放弃所有未执行的 relay log，并且重新从 master 上获取日志，这样就保证了 relay log 的完整性。默认情况下该功能是关闭的，将 relay_log_recovery 的值设置为 1 时，可在 slave 从库上开启该功能，建议开启。

relay_log_space_limit

防止中继日志写满磁盘，这里设置中继日志最大限额。但此设置存在主库崩溃，从库中继日志不全的情况，不到万不得已，不推荐使用。

sync_relay_log

这个参数和 Binlog 中的?sync_binlog作用相同。当设置为 1 时，slave 的 I/O 线程每次接收到 master 发送过来的 Binlog 日志都要写入系统缓冲区，然后刷入 relay log 中继日志里，这样是最安全的，因为在崩溃的时候，你最多会丢失一个事务，但会造成磁盘的大量 I/O。

当设置为 0 时，并不是马上就刷入中继日志里，而是由操作系统决定何时来写入，虽然安全性降低了，但减少了大量的磁盘 I/O 操作。这个值默认是 0，可动态修改，建议采用默认值。

sync_relay_log_info

当设置为 1 时，slave 的 I/O 线程每次接收到 master 发送过来的 Binlog 日志都要写入系统缓冲区，然后刷入 relay-log.info 里，这样是最安全的，因为在崩溃的时候，你最多会丢失一个事务，但会造成磁盘的大量 I/O。当设置为 0 时，并不是马上就刷入 relay-log.info 里，而是由操作系统决定何时来写入，虽然安全性降低了，但减少了大量的磁盘 I/O 操作。这个值默认是 0，可动态修改，建议采用默认值。

从节点 SQL 线程

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

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

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

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

因为整个复制过程实际上就是 Slave 从 Master 端获取该日志然后再在自己身上完全顺序的执行日志中所记录的各种操作。如下图所示：

复制的基本过程

1. 在从节点上执行?sart slave?命令开启主从复制开关，开始进行主从复制。从节点上的 I/O 进程连接主节点，并请求从指定日志文件的指定位置（或者从最开始的日志）之后的日志内容。

2. 主节点接收到来自从节点的 I/O 请求后，通过负责复制的 I/O 进程（log Dump Thread）根据请求信息读取指定日志指定位置之后的日志信息，返回给从节点。返回信息中除了日志所包含的信息之外，还包括本次返回的信息的 Binlog file 以及 Binlog position（Binlog 下一个数据读取位置）。

3. 从节点的 I/O 进程接收到主节点发送过来的日志内容、日志文件及位置点后，将接收到的日志内容更新到本机的 relay log 文件（Mysql-relay-bin.xxx）的最末端，并将读取到的 Binlog 文件名和位置保存到master-info?文件中，以便在下一次读取的时候能够清楚的告诉 Master ：“ 我需要从哪个 Binlog 的哪个位置开始往后的日志内容，请发给我”。

4. Slave 的 SQL 线程检测到 relay log 中新增加了内容后，会将 relay log 的内容解析成在能够执行 SQL 语句，然后在本数据库中按照解析出来的顺序执行，并在?relay log.info?中记录当前应用中继日志的文件名和位置点。

MySQL 基于 Binlog 主从复制的模式介绍

MySQL 主从复制默认是?异步的模式。MySQL 增删改操作会全部记录在 Binlog 中，当 slave 节点连接 master 时，会主动从 master 处获取最新的 Binlog 文件。并把 Binlog 存储到本地的 relay log 中，然后去执行 relay log 的更新内容。

异步模式 (async-mode)

异步模式如下图所示：

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

半同步模式(semi-sync)

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

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

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

全同步模式

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

Binlog 复制实战

配置 my.cnf

[mysqld]

log-bin

server-id

gtid_mode=off #禁掉 gtid

添加主从复制用户：

grant replication slave on . to 'repl'@'%' identified by 'gtidUser';

flush privileges;

然后我们新增一个从库。

接着我们用命令行的方式来加载主库的 Binlog 到从库，这里可以设置指定的 binlog 文件和位移值。在从库执行以下命令：

mysql>change master to

master_host='192.168.199.117',

master_user='slave',

master_port=7000,

master_password='slavepass',

master_log_file='mysql-bin.000008',

master_log_pos=0;

mysql>start slave;

mysql>show slave status\G;

复制过程中如果出现代码性错误，个人根据错误日志来决定是否要跳过错误继续执行：

mysql>stop slave;

mysql>set global sql_slave_skip_counter=1;

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

Slave 同步延迟

因为 Slave 端是通过 I/O thread 单线程来实现数据解析入库；而 Master 端写 Binlog 由于是顺序写效率很高，当主库的 TPS 很高的时候，必然 Master 端的写效率要高过 Slave 端的读效率，这时候就有同步延迟的问题。

I/O Thread 的同步是基于库的，即同步几个库就会开启几个 I/O Thread。

可以通过?show slave status?命令查看?Seconds_Behind_Master?的值来看是否出现同步延迟，这个值代表主从同步延迟的时间，值越大说明延迟越严重。值为 0 为正常情况，正值表示已经出现延迟，数字越大从库落后主库越多。

基于 Binlog 的复制方式肯定有这种问题，MySQL 官方也意识到，单线程不如多线程强，所以在 MySQL 5.7 版本引入了基于组提交的并行复制（官方称为 Enhanced Multi-threaded Slaves，即 MTS），设置参数：

slave_parallel_workers>0?即可，并且?global.slave_parallel_type＝‘LOGICAL_CLOCK’，

即可支持一个 schema(库) 下，slave_parallel_workers个 worker 线程并发执行 relay log 中主库提交的事务。

其核心思想：

一个组提交的事务都是可以并行回放（配合 binary log group commit）；

slave 机器的 relay log 中 last_committed 相同的事务（sequence_num 不同）可以并发执行。其中，变量?slave-parallel-type?可以有两个值：

1. DATABASE 默认值，基于库的并行复制方式

2. LOGICAL_CLOCK，基于组提交的并行复制方式

MySQL 5.7 开启 MTS 很简单，只需要在 Slave 从数据库的 my.cnf 文件中如下配置即可:

slave

slave-parallel-type=LOGICAL_CLOCK

slave-parallel-workers=8 #一般建议设置 4-8，太多的线程会增加线程之间的同步开销

master_info_repository=TABLE

relay_log_info_repository=TABLE

relay_log_recovery=ON

当然多线程带来的并行复制方案也有很多实现难点，比如事务都是有序执行的，如果并行回放会不会存在执行数据错乱的问题。这些问题就不在本节解释，大家有兴趣可以继续深究。

新一代主从复制模式 - GTID 复制模式

在传统的复制里面，当发生故障，需要主从切换，需要找到 Binlog 和 位点信息，恢复完成数据之后将主节点指向新的主节点。在 MySQL 5.6 里面，提供了新的数据恢复思路，只需要知道主节点的 IP、端口以及账号密码就行，因为复制是自动的，MySQL 会通过内部机制?GTID 自动找点同步。

基于 GTID 的复制是 MySQL 5.6.5 后新增的复制方式。

GTID (global transaction identifier)?即全局事务 ID，一个事务对应一个 GTID，保证了在每个在主库上提交的事务在集群中有一个唯一的 ID。

GTID 复制原理

在原来基于日志的复制中，从库需要告知主库要从哪个偏移量进行增量同步， 如果指定错误会造成数据的遗漏，从而造成数据的不一致。

而基于 GTID 的复制中，从库会告知主库已经执行的事务的 GTID 的值，然后主库会将所有未执行的事务的 GTID 的列表返回给从库，并且可以保证同一个事务只在指定的从库执行一次，通过全局的事务 ID 确定从库要执行的事务的方式代替了以前需要用 Binlog 和 位点确定从库要执行的事务的方式。

基于 GTID 的复制过程如下：

1. master 更新数据时，会在事务前产生 GTID，一同记录到 Binlog 日志中。

2. slave 端的 I/O 线程将变更的 Binlog，写入到本地的 relay log 中,读取值是根据gitd_next变量，告诉我们 slave 下一个执行哪个 GTID。

3. SQL 线程从 relay log 中获取 GTID，然后对比 slave 端的 Binlog 是否有记录。如果有记录，说明该 GTID 的事务已经执行，slave 会忽略。

4. 如果没有记录，slave 就会从 relay log 中执行该 GTID 的事务，并记录到 Binlog。

5. 在解析过程中会判断是否有主键，如果没有就用二级索引，如果没有二级索引就用全部扫描。

GTID 组成

? GTID = source_id:transaction_id

source_id?正常即是?server_uuid，在第一次启动时生成(函数?generate_server_uuid)，并持久化到?DATADIR/auto.cnf?文件里。

transaction_id?是顺序化的序列号(sequence number)，在每台 MySQL 服务器上都是从 1 开始自增长的序列，是事务的唯一标识。

GTID 生成

GTID 的生成受?gtid_next?控制。

在 Master 上，gtid_next?是默认的?AUTOMATIC,即 GTID 在每次事务提交时自动生成。它从当前已执行的 GTID 集合(即 gtid_executed)中，找一个大于 0 的未使用的最小值作为下个事务 GTID。在实际的更新事务记录之前将 GTID 写入到 Binlog。

在 Slave 上，从 Binlog 先读取到主库的 GTID(即 set gtid_next 记录)，而后执行的事务采用该 GTID。

GTID 的好处

1. GTID 使用?master_auto_position=1?代替了 Binlog 的主从复制方案，相比 Binlog 方式更容易搭建主从复制。

2. GTID 方便实现主从之间的 failover（主从切换），不用一步一步的去定位 Binlog 日志文件和查找 Binlog 的位点信息。

GTID 模式复制局限性

1. 在一个事务里面混合使用引擎，如 Innodb(支持事务)、MyISAM(不支持事务)， 造成多个 GTIDs 和同一个事务相关联出错。

2. CREATE TABLE…..SELECT?不能使用，该语句产生的两个 Event。 在某一情况会使用同一个 GTID(同一个 GTID 在 slave 只能被使用一次)：

• event one：创建表语句 create table

• event two ：插入数据语句 insert

3. CREATE TEMPORARY TABLE and DROP TEMPORARY TABLE?不能在事务内使用 (启用了?–enforce-gtid-consistency?参数)。

4. 使用 GTID 复制从库跳过错误时，不支持?sql_slave_skip_counter?参数的语法。

GTID 主从复制实战

1.Master 主数据库上的操作

在 my.cnf 文件中配置 GTID 主从复制

[root@mysql-master ~]# cp /etc/my.cnf /etc/my.cnf.bak

[root@mysql-master ~]# >/etc/my.cnf

[root@mysql-master ~]# cat /etc/my.cnf

[mysqld]

datadir = /var/lib/mysql

socket = /var/lib/mysql/mysql.sock

symbolic-links = 0

log-error = /var/log/mysqld.log

pid-file = /var/run/mysqld/mysqld.pid

#GTID:

server_id = 1

gtid_mode = on

enforce_gtid_consistency = on

#binlog

log_bin = mysql-bin

log-slave-updates = 1

binlog_format = row

sync-master-info = 1

sync_binlog = 1

#relay log

skip_slave_start = 1

配置后，重启 MySQL 服务：

[root@mysql-master ~]# systemctl restart mysqld

登录 MySQL，并查看 Master 状态， 发现多了一项?Executed_Gtid_Set：

mysql> show master status;

+-------------------+----------+--------------+------------------+-------------------+

| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |

+-------------------+----------+---

【一线大厂Java面试题解析+核心总结学习笔记+最新架构讲解视频+实战项目源码讲义】
浏览器打开：qq.cn.hn/FTf 免费领取

-----------+------------------+-------------------+

| mysql-bin.000001 | 154 | | | |

+-------------------+----------+--------------+------------------+-------------------+

1 row in set (0.00 sec)

mysql> show global variables like '%uuid%';

+---------------+--------------------------------------+

| Variable_name | Value |

+---------------+--------------------------------------+

| server_uuid | 317e2aad-1565-11e9-9c2e-005056ac6820 |

+---------------+--------------------------------------+

1 row in set (0.00 sec)

查看确认 GTID 功能打开:

mysql> show global variables like '%gtid%';

+----------------------------------+-------+

| Variable_name | Value |

+----------------------------------+-------+

| binlog_gtid_simple_recovery | ON |

| enforce_gtid_consistency | ON |

| gtid_executed | |

| gtid_executed_compression_period | 1000 |

| gtid_mode | ON |

| gtid_owned | |

| gtid_purged | |

| session_track_gtids | OFF |

+----------------------------------+-------+

8 rows in set (0.00 sec)

查看确认 Binlog 日志功能打开:

mysql> show variables like 'log_bin';

+---------------+-------+

| Variable_name | Value |

+---------------+-------+

| log_bin | ON |

+---------------+-------+

1 row in set (0.00 sec)

授权 slave 复制用户，并刷新权限:

mysql> flush privileges;

Query OK, 0 rows affected (0.04 sec)

mysql> show grants for slave@'172.23.3.66';

+-------------------------------------------------------------------------------+

| Grants for slave@172.23.3.66 |

+-------------------------------------------------------------------------------+

| GRANT REPLICATION SLAVE, REPLICATION CLIENT ON . TO 'slave'@'172.23.3.66' |