linux 下基于GTID的Mysql主从数据库的半同步复制（mysql版本：mysql-5.7.24）——半同步复制

半同步复制

介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay log中才返回给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。所以，半同步复制最好在低延时的网络中使用。

 

配置server1（主库）

1.加载插件，并查看插件加载是否成功

#查看插件是否加载成功

#查看插件是否加载成功(和上面的方法类似,两种方法都可以)

 

2.启动半同步复制，并查看半同步复制是否在运行

#启动半同步复制

#查看半同步复制的状态是否是打开状态的

#查看半同步复制的一些参数变量

rpl_semi_sync_master_timeout的值是10000（单位是毫秒），表示半同步复制时，当从库的io线程关闭时，主库等待10s。

当然10s这个时间是可以改的，通过参数“SET GLOBAL rpl_semi_sync_master_timeout =N;”改。在实际的生产过程中，为了防止数据丢失，一般将N设置为无穷大。

 

配置server2（从库）

1.加载插件，并查看插件加载是否成功

#查看插件是否加载成功

#查看插件是否加载成功(和上面的方法类似,两种方法都可以)

2.启动半同步复制，并查看半同步复制是否在运行

#启动半同步复制

#slave端启动半同步复制之后,不能立即生效,需要重启slave端的io线程

#查看半同步复制是否打开

 

#查看半同步复制的一些参数变量

 

测试：

1.在从库关闭io线程

2.在主库更新数据，并查看更新以后的数据

一直停留10秒才会返回OK

此时可以看到，数据传送成功之后，半同步复制就会关闭（这是因为从库，没有成功接收到数据）。

show  status  like  '%rpl%'或show  status  like  'semi'都可以。

Rpl_semi_sync_master_no_tx为失败次数，yes为成功次数

Rpl_semi_sync_master_yes_tx为1，半同步成功

 

3.在从库查看更新之后的数据

4.在从库打开io线程，再次查看更新以后的数据

当从库打开io线程之后，从库就接受到了数据，那么半同步复制又会重新开启

结论：

从上述测试的过程中可知：当从库的io线程关掉之后，在主库插入数据，会有10s的停留才会返回OK，在从库看不到刚刚插入的数据，当打开从库的io线程后，此哦从库又可以看到主库刚刚插入的数据。

表明基于gtid的主从数据库的半同步复制搭建成功。

 

值的注意的是：

半同步的设置是临时的，如果重新启动mysqld服务，那么半同步的设置就会失效。需要在主库和从库上重新打开半同步的设置。