简介

MySQL主从复制过程：

主从复制方式

MySQL有四种同步方式：
1、异步复制（Async Replication）
2、同步复制（sync Replication）
3、半同步复制（Async Replication）
4、增强半同步复制（lossless Semi-Sync Replication）、无损复制

1、异步复制（Async Replication）
主库将更新写入Binlog日志文件后，不需要等待数据更新是否已经复制到从库中，就可以继续处理更多的请求。Master将事件写入binlog，但并不知道Slave是否或何时已经接收且已处理。在异步复制的机制的情况下，如果Master宕机，事务在Master上已提交，但很可能这些事务没有传到任何的Slave上。假设有Master->Salve故障转移的机制，此时Slave也可能会丢失事务。MySQL复制默认是异步复制，异步复制提供了最佳性能。

2、同步复制（Sync Replication）
主库将更新写入Binlog日志文件后，需要等待数据更新已经复制到从库中，并且已经在从库执行成功，然后才能返回继续处理其它的请求。同步复制提供了最佳安全性，保证数据安全，数据不会丢失，但对性能有一定的影响。

3、半同步复制（Semi-Sync Replication）
主库提交更新写入二进制日志文件后，等待数据更新写入了从服务器中继日志中，然后才能再继续处理其它请求。该功能确保至少有1个从库接收完主库传递过来的binlog内容已经写入到自己的relay log里面了，才会通知主库上面的等待线程，该操作完毕。
半同步复制，是最佳安全性与最佳性能之间的一个折中。
MySQL 5.5版本之后引入了半同步复制功能，主从服务器必须安装半同步复制插件，才能开启该复制功能。如果等待超时，超过rpl_semi_sync_master_timeout参数设置时间（默认值为10000，表示10秒），则关闭半同步复制，并自动转换为异步复制模式。当master dump线程发送完一个事务的所有事件之后，如果在rpl_semi_sync_master_timeout内，收到了从库的响应，则主从又重新恢复为增强半同步复制。
ACK (Acknowledge character）即是确认字符。

4、增强半同步复制（lossless Semi-Sync Replication、无损复制）
增强半同步是在MySQL 5.7引入，其实半同步可以看成是一个过渡功能，因为默认的配置就是增强半同步，所以，大家一般说的半同步复制其实就是增强的半同步复制，也就是无损复制。
增强半同步和半同步不同的是，等待ACK时间不同
rpl_semi_sync_master_wait_point = AFTER_SYNC（默认）
半同步的问题是因为等待ACK的点是Commit之后，此时Master已经完成数据变更，用户已经可以看到最新数据，当Binlog还未同步到Slave时，发生主从切换，那么此时从库是没有这个最新数据的，用户看到的是老数据。
增强半同步将等待ACK的点放在提交Commit之前，此时数据还未被提交，外界看不到数据变更，此时如果发送主从切换，新库依然还是老数据，不存在数据不一致的问题。

图示如下：

异步复制示例

MySQL主从复制之1主2从异步复制搭建及同步测试参考：https://www.xmmup.com/dbbao64mysqlzhucongzhi1zhu2congyibufuzhidajianjitongbuceshi.html

如何配置半同步复制

延迟从库

延迟从库:从库落后于主库一段时间。
SQL线程延时:数据已经写入relaylog中了,只是让SQL线程"慢点"运行

MySQL延迟复制的好处主要有几点：
1.误删除时，能更快恢复数据。有时候手抖了，把线上数据给误删除了，或者误删除库、表、其他对象，或不加WHERE条件的更新、删除，都可以让延迟从库在误操作前的时间点停下，然后进行恢复。
2.把延迟从库作为专用的备份节点。虽然有一定的延迟，但并不影响利用该节点作为备份角色，也不影响生产节点数据库。
3.还可以把延迟从库当做一些问题、案例研究的对象。个别时候，可能有些Binlog Event在普通从库上会有问题（例如：早期版本中无主键会导致从库更新非常慢的经典问题），这时就有时间在延迟从库上慢慢琢磨研究了。

一般企业建议3-6小时，具体看公司运维人员对于故障的反应时间。

启用延迟从库的方法也挺简单的：

并行复制

MySQL 5.6提供了并行复制，但是这种并行只是基于database的（slave-parallel-type=DATABASE）。如果用户的MySQL数据库实例中存在多个database，对于从库复制的速度的确可以有比较大的帮助。如果是基于单个database的复制依然无法做到真正的并行回放，这个阶段很多DBA将数据库进行垂直拆分，将一个database拆分成几个database，通过设置slave_parallel_workers=n，可以进行database级别的并行复制，但对于热点业务复制延迟依然无法解决。参数slave_parallel_workers默认值为0，表示禁用并行。

到了MySQL 5.7，才实现了真正的并行复制（slave-parallel-type=LOGICAL_CLOCK），也叫多线程复制，复制效率提升很多。MySQL 5.7的并行复制，multi-threaded slave即MTS，期望最大化还原主库的并行度，实现方式是在binlog event中增加必要的信息，以便slave节点根据这些信息实现并行复制。

一个组提交的事务都是可以并行回放，因为这些事务都已进入到事务的 Prepare 阶段，则说明事务之间没有任何冲突（否则就不可能提交）。如何知道事务是否在一组中呢？在MySQL 5.7版本中，其设计方式是将组提交的信息存放在GTID中。即使用户没有开启GTID，那么每个事务在开始前也会存在一个Anonymous_Gtid（匿名gtid），而这GTID中就存在着组提交的信息。

要开启 MySQL 5.7 并行复制需要以下2步：
1、首先在主库设置 binlog_group_commit_sync_delay 的值大于0 。

binlog_group_commit_sync_delay 全局动态变量，单位微妙，默认0，范围：0～1000000（1秒）。
表示 binlog 提交后等待延迟多少时间再同步到磁盘，默认0 ，不延迟。当设置为 0 以上的时候，就允许多个事务的日志同时一起提交，也就是我们说的组提交。组提交是并行复制的基础，我们设置这个值的大于 0 就代表打开了组提交的功能。
binlog_group_commit_sync_no_delay_count 全局动态变量，单位个数，默认0，范围：0～1000000。
表示等待延迟提交的最大事务数，如果上面参数的时间没到，但事务数到了，则直接同步到磁盘。若 binlog_group_commit_sync_delay 没有开启，则该参数也不会开启。

2、其次要在 Slave 主机上设置如下几个参数：

MySQL 5.7 引入的变量 slave-parallel-type，其可以配置的值有：

• DATABASE：默认值，基于库的并行复制方式。
• LOGICAL_CLOCK：基于组提交的并行复制方式。

一、1主2从之增强半同步复制（无损复制）示例

半同步复制比异步复制多了如下步骤：

1、MySQL环境初始化

2、主库配置

执行过程：

3、从库1配置

4、从库2配置

5、主从查询

半同步复制查询：

Rpl_semi_sync_master_clients表示记录支持半同步的slave的个数

Rpl_semi_sync_master_status标记master现在是否是半同步复制状态

6、测试半同步复制

测试过程：

1、关闭从库io线程，模拟网络卡顿

2、主库插入数据，等待10秒，同步方式自动转换为异步模式

3、从库启动io线程

4、同步方式变为半同步模式

先关闭一个从库，我们测试1主1从的情况。

二、配置延迟复制示例

我们把从库2配置为延迟从库，如下所示：

三、配置并行复制示例

3.1、主库配置

3.2、从库2配置并行复制

只在从库2做配置，从库1不做配置。

3.3、主库压测测试并行复制

因为这里的架构为1主2从，我只配置了从库2为并行复制，从库1不是并行复制，那么接下来测试并行复制的效果。

首先，取消从库2的延迟复制功能：

首先，主库进行压测生成数据：

结果：

可以看到，从库2比从库1能至少快一倍。

若是将从库的slave_parallel_workers配置为16，则配置了并行复制的库基本无延迟，而没有配置并行复制的库，延迟会越来越严重：

重新测试，可以看到从库2基本无延迟了：