[干货满满] MySql（基于Docker容器构建）主从架构及读写分离实战、集群扩容、半同步复制集群、主从数据延迟问题解决方案

一、实验目的与环境

1、​ 实验目的

MySQL是现在互联网最常用的开源数据库产品。但是我们平常开发使用，大都是用的单机服务。

而在实际生产中，往往数据量会极为庞大，并且数据的安全性要求也更高，这样单机的MySQL，不管是性能还是安全都是达不到要求的。

所以在生产环境中，MySQL必须是要搭建一套主从复制的架构，同时可以基于一些工具实现高可用架构。然后，在此基础上，就可以基于一些中间件实现读写分离架构。最后如果数据量非常大，还必须可以实现分库分表的架构。

当然，MySQL的这些架构搭建还是比较复杂的，通常会由专门的运维人员来搭建。

所以这次实验的目的，并不是要大家就学会去搭建MySQL集群，而是带大家对生产环境下的MySQL架构有一定的理解，能够在自己的生产项目中运用上MySQL的生产架构。同时，也是为后面学习ShardingSphere分库分表打下基础。

2、实验环境

​ 1、Linux服务器两台：centos7

​ 2、mysql版本：mysql-8.0.20

说明：

关于MySQL的安装：Linux服务的基础安装，在之前学习MySQL优化时已经讲解过，这里就不再多做介绍了。MySQL服务器安装方式，大家可以参考官网的手册，自行进行。

MySQL安装手册地址：https://dev.mysql.com/doc/refman/8.0/en/binary-installation.html


另外，对于熟悉Docker的同学，可以直接用Docker来搭建，更为简单高效，也是未来互联网企业进行服务搭建的主流方式。大家以后学Docker的时候也可以留意下。

二、基础环境介绍

两台服务器，均安装CentOS7。（我们这里为了简单，在一台服务器上使用docker装两个mysql服务）

CentOS7构建MySql8.0.20详解 ：https://blog.csdn.net/qq_43631716/article/details/120272124

1、192.168.131.171:3306 作为mysql主节点部署
​2、192.168.232.171:3307 作为mysql从节点部署

mysql版本：mysql-8.0.20

为了便于使用，两个mysql服务需要打开远程登录权限，开启方式需要在本机登录mysql，执行以下语句。

#开启远程登录
use mysql;
update user set host='%' where user='root';
flush privileges;

三、搭建主从集群

1、理论基础

主从架构有什么用？通过搭建MySQL主从集群，可以缓解MySQL的数据存储以及访问的压力。

1、数据安全
​给主服务增加一个数据备份。基于这个目的，可以搭建主从架构，或者也可以基于主从架构搭建互主的架构。

2、读写分离
对于大部分的JAVA业务系统来说，都是读多写少的，读请求远远高于写请求。这时，当主服务的访问压力过大时，可以将数据读请求转为由从服务来分担，主服务只负责数据写入的请求，这样大大缓解数据库的访问压力。

​要理解，MySQL的主从架构只是实现读写分离的一个基础。实现读写分离还是需要一些中间件来支持，比如ShardingSphere。

3、故障转移-高可用
​当MySQL主服务宕机后，可以由一台从服务切换成为主服务，继续提供数据读写功能。

​对于高可用架构，主从数据的同步也只是实现故障转移的一个前提条件，要实现MySQL主从切换，还需要依靠一些其他的中间件来实现。比如MMM、MHA、MGR。

​在一般项目中，如果数据库的访问压力没有那么大，那读写分离不一定是必须要做的，但是，主从架构和高可用架构则是必须要搭建的。

2、同步的原理

​MySQL服务的主从架构一般都是通过binlog日志（Binary Log）文件来进行的。

即在主服务上打开binlog记录每一步的数据库操作，然后从服务上会有一个IO线程，负责跟主服务建立一个TCP连接，请求主服务将binlog传输过来。这时，主库上会有一个IO dump线程，负责通过这个TCP连接把Binlog日志传输给从库的IO线程。

接着从服务的IO线程会把读取到的binlog日志数据写入自己的relay日志文件中。

然后从服务上另外一个SQL线程会读取relay日志里的内容，进行操作重演，达到还原数据的目的。我们通常对MySQL做的读写分离配置就必须基于主从架构来搭建。

MySQL的binlog不光可以用于主从同步，还可以用于缓存数据同步等场景。

例如阿里的中间件Canal，可以模拟一个slave节点，向MySQL发起binlog同步，然后将数据落地到Redis、Kafka等其他组件，实现数据实时流转。

搭建主从集群时，有两个必要的要求：

1、双方MySQL必须版本一致，至少需要主服务的版本低于从服务
2、两节点间的时间需要同步

3、搭建主从集群

3.1 配置master主服务器

首先，配置主节点的mysql配置文件： /etc/my.cnf 这一步需要对master进行配置，主要是需要打开binlog日志，以及指定severId。

我们打开MySQL主服务（也就是我的mysql_1的docker容器）的my.cnf文件，在文件中一行server-id以及一个关闭域名解析的配置。然后重启服务。


我们docker构建mysql的时候使用的是目录挂载，所以只需要修改宿主机上/usr/software/docker_dir/mysql8.0.20_1/mysql/my.cnf文件即可。再原来的配置后面添加如下的配置（注意要在同一个[mysqld]下）。

[mysqld]
server-id=47
#开启binlog
log_bin=master-bin
log_bin-index=master-bin.index
skip-name-resolve
# 设置连接端口
port=3306
# 设置mysql的安装目录
basedir=/usr/local/mysql
# 设置mysql数据库的数据的存放目录
datadir=/usr/local/mysql/mysql-files
# 允许最大连接数
max_connections=200
# 允许连接失败的次数。
max_connect_errors=10
# 服务端使用的字符集默认为UTF8
character-set-server=utf8
# 创建新表时将使用的默认存储引擎
default-storage-engine=INNODB
# 默认使用“mysql_native_password”插件认证
#mysql_native_password
default_authentication_plugin=mysql_native_password

配置说明：主要需要修改的是以下几个属性：

• server-id：服务节点的唯一标识。需要给集群中的每个服务分配一个单独的ID。
• log_bin：打开Binlog日志记录，并指定文件名。
• log_bin-index：Binlog日志文件

​重启docker mysql_1服务:

docker restart mysql_1

然后，我们需要给root用户分配一个replication slave的权限。

#登录主数据库
mysql -u root -p
GRANT REPLICATION SLAVE ON *.* TO 'root'@'%';
flush privileges;
#查看主节点同步状态：
show master status;

在实际生产环境中，通常不会直接使用root用户，而会创建一个拥有全部权限的用户来负责主从同步。

​这个指令结果中的File和Position记录的是当前日志的binlog文件以及文件中的索引。

注意，这两个值Fiel: master-bin.000001和Position: 543我们后面配置从节点的时候需要使用到！

而后面的Binlog_Do_DB和Binlog_Ignore_DB这两个字段是表示需要记录binlog文件的库以及不需要记录binlog文件的库。目前我们没有进行配置，就表示是针对全库记录日志。这两个字段如何进行配置，会在后面进行介绍。

开启binlog后，数据库中的所有操作都会被记录到datadir当中，以一组轮询文件的方式循环记录。而指令查到的File和Position就是当前日志的文件和位置。而在后面配置从服务时，就需要通过这个File和Position通知从服务从哪个地方开始记录binLog。<br/

3.2 配置slave从服务

下一步，我们来配置从服务mysqls。 我们打开mysqls的配置文件my.cnf，修改配置文件：

我们现在开启我们的第二个docker容器：mysql_2.

随后我们来修改宿主机上挂载的配置文件：

vim /usr/software/docker_dir/mysql8.0.20_2/mysql/my.cnf

然后将下面的配置添加到原配置文件的[mysqld]下面：

[mysqld]
#主库和从库需要不一致
server-id=48
#打开MySQL中继日志
relay-log-index=slave-relay-bin.index
relay-log=slave-relay-bin
#打开从服务二进制日志
log-bin=mysql-bin
#使得更新的数据写进二进制日志中
log-slave-updates=1
# 设置3307端口
port=3307
# 设置mysql的安装目录
# basedir=/usr/local/mysql
# 设置mysql数据库的数据的存放目录
# datadir=/usr/local/mysql/mysql-files
# 允许最大连接数
max_connections=200
# 允许连接失败的次数。
max_connect_errors=10
# 服务端使用的字符集默认为UTF8
character-set-server=utf8
# 创建新表时将使用的默认存储引擎
default-storage-engine=INNODB
# 默认使用“mysql_native_password”插件认证
#mysql_native_password
default_authentication_plugin=mysql_native_password

完成后我们重启mysql_2容器。

docker restart mysql_2

配置说明：主要需要关注的几个属性：

server-id：服务节点的唯一标识

relay-log：打开从服务的relay-log日志。

log-bin：打开从服务的bin-log日志记录。

启动服务之后，然后我们来设置他的主节点同步状态。

首先登录从服务：

mysql -u root -p;

然后开始设置从服务：

#设置同步主节点（下面整个语句要在客户端执行）：
CHANGE MASTER TO
MASTER_HOST='192.168.131.172',
MASTER_PORT=3306,
MASTER_USER='root',
MASTER_PASSWORD='123456',
MASTER_LOG_FILE='master-bin.000001',
MASTER_LOG_POS=543,
GET_MASTER_PUBLIC_KEY=1;

#开启slave
start slave;

参数分析：

• MASTER_HOST： Master宿主机的ip地址，注意不是容器内部的IP
• MASTER_PORT： Master的端口，指的是容器的端口号，不是映射端口
• MASTER_USER：用于数据同步的用户
• MASTER_PASSWORD：用户同步的用户的密码
• MASTER_LOG_FILE：指定Slave从哪个日志文件开始复制数据，即上文中查到的主节点的File字段的值
• MASTER_LOG_POS：指从哪个Position开始读，即上文中查到的主节点的Position字段的值
• GET_MASTER_PUBLIC_KEY=1：是因为开启主从复制的时候可能会报出下方的异常。原因是mysql8默认使用插件caching_sha2_password，有些client连接报这个错误，需要拿到server的public key来加密password
  ERROR 2061 (HY000): Authentication plugin ‘caching_sha2_password’ reported error: Authentication requires secure connection.

注意，CHANGE MASTER指令中需要指定的MASTER_LOG_FILE和MASTER_LOG_POS必须与主服务中查到的保持一致。下图是我们主节点中查询的截图：

并且后续如果要检查主从架构是否成功，也可以通过检查主服务与从服务之间的File和Position这两个属性是否一致来确定。

接下来我们查看主从状态：

#查看主从同步状态
show slave status;
# 或者用 show slave status \G; 这样查看比较简洁

​我们重点关注其中红色方框的两个属性，与主节点保持一致，就表示这个主从同步搭建是成功的。

从这个指令的结果能够看到，有很多Replicate_开头的属性，这些属性指定了两个服务之间要同步哪些数据库、哪些表的配置。只是在我们这个示例中全都没有进行配置，就标识是全库进行同步。后面我们会补充如何配置需要同步的库和表。

3.3 主从集群测试

​测试时，我们先用show databases，查看下两个MySQL服务中的数据库情况:

​然后我们在主服务器上创建一个数据库:

mysql> create database syncdemo;
Query OK, 1 row affected (0.00 sec)

​然后我们再用show databases，来看下这个syncdemo的数据库是不是已经同步到了从服务。

​接下来我们继续在主节点的syncdemo这个数据库中创建一个表，并插入一条数据。

mysql> use syncdemo;
Database changed
mysql> create table demoTable(id int not null);
Query OK, 0 rows affected (0.02 sec)

mysql> insert into demoTable value(1);
Query OK, 1 row affected (0.01 sec)

然后我们也同样到主服务与从服务上都来查一下这个demoTable是否同步到了从服务。

从上面的实验过程看到，我们在主服务中进行的数据操作，就都已经同步到了从服务上。这样，我们一个主从集群就搭建完成了。

另外，这个主从架构是有可能失败的，如果在slave从服务上查看slave状态，发现Slave_SQL_Running=no，就表示主从同步失败了。

这有可能是因为在从数据库上进行了写操作，与同步过来的SQL操作冲突了，也有可能是slave从服务重启后有事务回滚了。

如果是因为slave从服务事务回滚的原因，可以按照以下方式重启主从同步：

mysql> stop slave ;
mysql> set GLOBAL SQL_SLAVE_SKIP_COUNTER=1;
mysql> start slave ;

而另一种解决方式就是重新记录主节点的binlog文件消息:

mysql> stop slave ;
mysql> change master to .....
mysql> start slave ;

但是这种方式要注意binlog的文件和位置，如果修改后和之前的同步接不上，那就会丢失部分数据。所以不太常用。

4、集群搭建扩展

在完成这个基本的MySQL主从集群后，我们还可以进行后续的实验：

4.1 全库同步与部分同步

​之前提到，我们目前配置的主从同步是针对全库配置的，而实际环境中，一般并不需要针对全库做备份，而只需要对一些特别重要的库或者表来进行同步。那如何针对库和表做同步配置呢？

首先在Master端
在my.cnf中，可以通过以下这些属性指定需要针对哪些库或者哪些表记录binlog。

# 需要同步的二进制数据库名(我们现在要同步的数据库是masterdemo)
binlog-do-db=masterdemo
# 只保留7天的二进制日志，以防磁盘被日志占满(可选)
expire-logs-days  = 7
# 不备份的数据库
binlog-ignore-db=information_schema
binlog-ignore-db=performation_schema
binlog-ignore-db=sys

然后在Slave端
在my.cnf中，需要配置备份库与主服务的库的对应关系。

#如果salve库名称与master库名相同，使用本配置
replicate-do-db = masterdemo 
#如果master库名[mastdemo]与salve库名[mastdemo01]不同，使用以下配置[需要做映射]
# replicate-rewrite-db = masterdemo -> masterdemo01
#如果不是要全部同步[默认全部同步]，则指定需要同步的表
replicate-wild-do-table=masterdemo.t_dict
replicate-wild-do-table=masterdemo.t_num

注意： replicate-wild-do-table指定了需要同步的表！也就是说此时只会同步数据库 masterdemo 中的t_dict 和 t_num 这两张表！ 其他的表还是不会同步的！！！

修改完后重启mysql_1和mysql_2容器。

配置完成了之后，然后我们登录到master节点的客户端上，

输入show master status指令，就可以看到Binlog_Do_DB和Binlog_Ignore_DB两个参数的作用了。

• File：同步日志
• Position：同步位置
• Binlog_Do_DB：需要同步的数据库
• Binlog_Ignore_DB：忽略的，也就是说不需要同步的数据库。

4.2 测试部分同步

4.2.1 验证数据库同步

我们首先在主节点来创建一个名为masterdemo的数据库。

mysql> create database masterdemo;
Query OK, 1 row affected (0.02 sec)

然后我们登录到从节点上去查看：

可以看到我们在主节点上创建的masterdemo 数据库已经被自动同步到从节点上了。

那如果我们创建一个其他名称的数据库呢？这个数据库名不被包括在配置文件中需要同步的数据库集合中。

比如，我们在主节点上创建一个masterdemo2 数据库，然后查看是否从节点会同步这个数据库。

mysql> create database masterdemo2;
Query OK, 1 row affected (0.29 sec)

发现此时数据库masterdemo2并没有被同步到从节点上！！！

这也验证了我们刚才的配置，因为我们现在只会同步masterdemo数据库！

4.2.2 验证数据表同步

我们知道，我们在从节点配置文件中配置了只同步数据库 masterdemo 中的 t_dict 和 t_num 这两张表。

我们首先来在主节点的masterdemo数据库中随便创建一个名为demoTable的表，然后分别在主从服务上查看：

mysql> create table demoTable(id int not null);
Query OK, 0 rows affected (0.02 sec)

发现此时没有被配置的表是不会被同步的。

那我们继续在主节点上的masterdemo 数据库中来创建一个被配置了的表t_num，然后分别验证：

mysql> create table t_num(id int not null);
Query OK, 0 rows affected (0.02 sec)

发现正如我们所预料的！我们所配置的数据表示可以成功被同步的。

这样，我们就做到了在更细的粒度上同步具体的数据库和数据表的功能！

5、读写分离配置

我们要注意，目前我们的这个MySQL主从集群是单向的，也就是只能从主服务同步到从服务，而从服务的数据表更是无法同步到主服务的。

我们在从服务的t_num表中插入一条记录：

insert into t_num value(1);

然后我们分别查询主从库中这张表的记录：

我们发现，此时主节点无法同步从从节点插入的数据！！！

​所以，在这种架构下， 为了保证数据一致，通常会需要保证数据只在主服务上写，而从服务只进行数据读取。这个功能，就是大名鼎鼎的读写分离。

但是这里要注意下， mysql主从本身是无法提供读写分离的服务的，需要由业务自己来实现。这也是我们后面要学的ShardingSphere的一个重要功能。

5.1 读写分离总结

到这里可以看到，在MySQL主从架构中，是需要严格限制从服务的数据写入的，一旦从服务有数据写入，就会造成数据不一致。并且从服务在执行事务期间还很容易造成数据同步失败。

如果需要限制用户写数据，我们可以在从服务中将read_only参数的值设为1( set global read_only=1; )。这样就可以限制用户写入数据。但是这个属性有两个需要注意的地方：

1、read_only=1设置的只读模式，不会影响slave同步复制的功能。 所以在MySQL slave库中设定了read_only=1后，通过 “show slave status\G” 命令查看salve状态，可以看到salve仍然会读取master上的日志，并且在slave库中应用日志，保证主从数据库同步一致；

2、read_only=1设置的只读模式， 限定的是 普通用户进行数据修改的操作，但不会限定具有super权限的用户的数据修改操作。 在MySQL中设置read_only=1后，普通的应用用户进行insert、update、delete等会产生数据变化的DML操作时，都会报出数据库处于只读模式不能发生数据变化的错误，但具有super权限的用户，例如在本地或远程通过root用户登录到数据库，还是可以进行数据变化的DML操作； 如果需要限定super权限的用户写数据，可以设置super_read_only=0。另外 如果要想连super权限用户的写操作也禁止，就使用"flush tables with read lock;"，这样设置也会阻止主从同步复制！

6、​其他集群方式

我们到这里搭建出了一个一主一从的MySQL主从同步集群，具有了数据同步的基础功能。而在生产环境中，通常会以此为基础，根据业务情况以及负载情况，搭建更大更复杂的集群。

例如为了进一步提高整个集群的读能力，可以扩展出一主多从。而为了减轻主节点进行数据同步的压力，可以继续扩展出多级从的主从集群。

​为了提高整个集群的高可用能力，可以扩展出多主的集群。

我们也可以扩展出互为主从的互主集群甚至是环形的主从集群，实现MySQL多活部署。

​搭建互主集群只需要按照上面的方式，在主服务上打开一个slave进程，并且指向slave节点的binlog当前文件地址和位置。

我们这里是使用的最为传统的Binlog方式搭建集群，是基于日志记录点的方式来进行主从同步的。

在这个实验中，Executed_Grid_Set一列，实际上就是另外一种搭建主从同步的方式，即GTID搭建方式。

GTID的本质也是基于Binlog来实现的主从同步，只是他会基于一个全局的事务ID来标识同步进度。这个GTID全局事务ID是一个全局唯一、并且趋势递增的分布式ID策略。我们这里就不再去搭建了。

7、GTID同步集群

上面我们搭建的集群方式，是基于Binlog日志记录点的方式来搭建的，这也是最为传统的MySQL集群搭建方式。

而在这个实验中，可以看到有一个Executed_Grid_Set列，暂时还没有用上。实际上，这就是另外一种搭建主从同步的方式，即GTID搭建方式。这种模式是从MySQL5.6版本引入的。

GTID的本质也是基于Binlog来实现主从同步，只是他会基于一个全局的事务ID来标识同步进度。GTID即全局事务ID，全局唯一并且趋势递增，他可以保证为每一个在主节点上提交的事务在复制集群中可以生成一个唯一的ID 。

在基于GTID的复制中，首先从服务器会告诉主服务器已经在从服务器执行完了哪些事务的GTID值，然后主库会有把所有没有在从库上执行的事务，发送到从库上进行执行，并且使用GTID的复制可以保证同一个事务只在指定的从库上执行一次，这样可以避免由于偏移量的问题造成数据不一致。

​他的搭建方式跟我们上面的主从架构整体搭建方式差不多。只是需要在my.cnf中修改一些配置。

​ 在主节点上：

gtid_mode=on
enforce_gtid_consistency=on
log_bin=on
server_id=单独设置一个
binlog_format=row

在从节点上：

gtid_mode=on
enforce_gtid_consistency=on
log_slave_updates=1
server_id=单独设置一个

​然后分别重启主服务和从服务，就可以开启GTID同步复制方式。

四、集群扩容

我们现在已经搭建成功了一主一从的MySQL集群架构，那要扩展到一主多从的集群架构，其实就比较简单了，只需要增加一个binlog复制就行了。

但是如果我们的集群是已经运行过一段时间，这时候如果要扩展新的从节点就有一个问题，之前的数据没办法从binlog来恢复了。这时候在扩展新的slave节点时，就需要增加一个数据复制的操作。

MySQL的数据备份恢复操作相对比较简单，可以通过SQL语句直接来完成。具体操作可以使用mysql的bin目录下的mysqldump工具。

mysqldump -u root -p --all-databases > backup.sql
#输入密码

通过这个指令，就可以将整个数据库的所有数据导出成backup.sql，然后把这个backup.sql分发到新的MySQL服务器上，并执行下面的指令将数据全部导入到新的MySQL服务中。

mysql -u root -p < backup.sql
#输入密码

这样新的MySQL服务就已经有了所有的历史数据，然后就可以再按照上面的步骤，配置Slave从服务的数据同步了。

五、半同步复制与半同步复制集群搭建

1、理解半同步复制

到现在为止，我们已经可以搭建MySQL的主从集群，互主集群，但是我们这个集群有一个隐患，就是有可能会丢数据。这是为什么呢？这要从MySQL主从数据复制分析起。

MySQL主从集群默认采用的是一种异步复制的机制。主服务在执行用户提交的事务后，写入binlog日志，然后就给客户端返回一个成功的响应了。而binlog会由一个dump线程异步发送给Slave从服务。

由于这个发送binlog的过程是异步的。主服务在向客户端反馈执行结果时，是不知道binlog是否同步成功了的。这时候如果主服务宕机了，而从服务还没有备份到新执行的binlog，那就有可能会丢数据。

那怎么解决这个问题呢，这就要靠MySQL的半同步复制机制来保证数据安全。

半同步复制机制是一种介于异步复制和全同步复制之前的机制。主库在执行完客户端提交的事务后，并不是立即返回客户端响应，而是等待至少一个从库接收并写到relay log中，才会返回给客户端。MySQL在等待确认时，默认会等10秒，如果超过10秒没有收到ack，就会降级成为异步复制。

这种半同步复制相比异步复制，能够有效的提高数据的安全性。

但是这种安全性也不是绝对的，他只保证事务提交后的binlog至少传输到了一个从库，并且并不保证从库应用这个事务的binlog是成功的。

另一方面，半同步复制机制也会造成一定程度的延迟，这个延迟时间最少是一个TCP/IP请求往返的时间。整个服务的性能是会有所下降的。而当从服务出现问题时，主服务需要等待的时间就会更长，要等到从服务的服务恢复或者请求超时才能给用户响应。

2、搭建半同步复制集群

半同步复制需要基于特定的扩展模块来实现。

而mysql从5.5版本开始，往上的版本都默认自带了这个模块。

这个模块包含在mysql安装目录下的lib/plugin目录下的semisync_master.so和semisync_slave.so两个文件中。

2.1 主服务上安装semisync_master模块

需要在主服务上安装semisync_master模块，在从服务上安装semisync_slave模块。

注意：我没有在docker否建的mysql中找到plugin这个文件夹。不管了，我们继续向下先执行安装命令试试。

首先我们登录主服务（mysql_1容器），安装semisync_master模块：

mysql> install plugin rpl_semi_sync_master soname 'semisync_master.so';
Query OK, 0 rows affected (0.14 sec)

mysql> show global variables like 'rpl_semi%';
+-------------------------------------------+------------+
| Variable_name                             | Value      |
+-------------------------------------------+------------+
| rpl_semi_sync_master_enabled              | OFF        |
| rpl_semi_sync_master_timeout              | 10000      |
| rpl_semi_sync_master_trace_level          | 32         |
| rpl_semi_sync_master_wait_for_slave_count | 1          |
| rpl_semi_sync_master_wait_no_slave        | ON         |
| rpl_semi_sync_master_wait_point           | AFTER_SYNC |
+-------------------------------------------+------------+
6 rows in set (0.08 sec)

mysql> set global rpl_semi_sync_master_enabled=ON;
Query OK, 0 rows affected (0.01 sec)

mysql> show global variables like 'rpl_semi%';
+-------------------------------------------+------------+
| Variable_name                             | Value      |
+-------------------------------------------+------------+
| rpl_semi_sync_master_enabled              | ON         |
| rpl_semi_sync_master_timeout              | 10000      |
| rpl_semi_sync_master_trace_level          | 32         |
| rpl_semi_sync_master_wait_for_slave_count | 1          |
| rpl_semi_sync_master_wait_no_slave        | ON         |
| rpl_semi_sync_master_wait_point           | AFTER_SYNC |
+-------------------------------------------+------------+
6 rows in set (0.00 sec)

可以看到，虽然我没找到那两个文件在哪里，但是还是成功安装服务了。

• 这三行指令中，第一行是通过扩展库来安装半同步复制模块，需要指定扩展库的文件名。
• 第二行查看系统全局参数，rpl_semi_sync_master_timeout就是半同步复制时等待应答的最长等待时间，默认是10秒，可以根据情况自行调整。最后的一个参数rpl_semi_sync_master_wait_point其实表示一种半同步复制的方式。
• 第三行则是打开半同步复制的开关。

半同步复制有两种方式，一种是我们现在看到的这种默认的AFTER_SYNC方式。这种方式下，主库把日志写入binlog，并且复制给从库，然后开始等待从库的响应。从库返回成功后，主库再提交事务，接着给客户端返回一个成功响应。

而另一种方式是叫做AFTER_COMMIT方式。他不是默认的。这种方式，在主库写入binlog后，等待binlog复制到从库，主库就提交自己的本地事务，再等待从库返回给自己一个成功响应，然后主库再给客户端返回响应。

2.2 从服务上安装smeisync_slave模块

然后我们登录从服务（mysql_2容器），安装smeisync_slave模块：

mysql> install plugin rpl_semi_sync_slave soname 'semisync_slave.so';
Query OK, 0 rows affected (0.05 sec)

mysql> show global variables like 'rpl_semi%';
+---------------------------------+-------+
| Variable_name                   | Value |
+---------------------------------+-------+
| rpl_semi_sync_slave_enabled     | OFF   |
| rpl_semi_sync_slave_trace_level | 32    |
+---------------------------------+-------+
2 rows in set (0.03 sec)

mysql> set global rpl_semi_sync_slave_enabled = on;
Query OK, 0 rows affected (0.00 sec)

mysql> show global variables like 'rpl_semi%';
+---------------------------------+-------+
| Variable_name                   | Value |
+---------------------------------+-------+
| rpl_semi_sync_slave_enabled     | ON    |
| rpl_semi_sync_slave_trace_level | 32    |
+---------------------------------+-------+
2 rows in set (0.00 sec)

mysql> stop slave;
Query OK, 0 rows affected (0.03 sec)

mysql> start slave;
Query OK, 0 rows affected (0.04 sec)

slave端的安装过程基本差不多，不过要注意下安装完slave端的半同步插件后，需要重启下slave服务。

至此，我们的半同步复制集群已经搭建完成。

六、主从架构的数据延迟问题

​在我们搭建的这个主从集群中，有一个比较隐藏的问题，就是这样的主从复制之间会有延迟。

这在做了读写分离后，会更容易体现出来。即数据往主服务写，而读数据在从服务读。这时候这个主从复制延迟就有可能造成刚插入了数据但是查不到。当然，这在我们目前的这个集群中是很难出现的，但是在大型集群中会很容易出现。

出现这个问题的根本在于： 面向业务的主服务数据都是多线程并发写入的，而从服务是单个线程慢慢拉取binlog，这中间就会有个效率差。所以解决这个问题的关键是要让从服务也用多线程并行复制binlog数据。

MySQL自5.7版本后就已经支持并行复制了。 可以在从服务上设置slave_parallel_workers为一个大于0的数，然后把slave_parallel_type参数设置为LOGICAL_CLOCK，这就可以了。