MySQL 主从复制模式以及基于GTID的半同步复制模式的实现

Bertha 。 2023-07-13 03:02 6阅读 0赞

### MySQL 主从复制模式以及 基于GTID的半同步复制模式的实现 ###

*  一、MySQL 主从复制模式
 *   *  异步模式（mysql async-mode）
     *  半同步模式(mysql semi-sync)
     *  全同步模式
 *  二、基于GTID的半同步复制模式的实现
 *   *  配置server1（主库）
     *  配置server2（从库）
     *  测试：
     *  结论：

# 一、MySQL 主从复制模式 #

## 异步模式（mysql async-mode） ##

MySQL默认的复制即是异步的，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，主如果crash掉了，此时主上已经提交的事务可能并没有传到从库上，如果此时，强行将从提升为主，可能导致新主上的数据不完整。

异步模式如下图所示，这种模式下，主节点不会主动push bin log到从节点，这样有可能导致failover的情况下，也许从节点没有即时地将最新的bin log同步到本地。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2_size_16_color_FFFFFF_t_70]

## 半同步模式(mysql semi-sync) ##

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

这种模式下主节点只需要接收到其中一台从节点的返回信息，就会commit；否则需要等待直到超时时间然后切换成异步模式再提交；这样做的目的可以使主从数据库的数据延迟缩小，可以提高数据安全性，确保了事务提交后，binlog至少传输到了一个从节点上，不能保证从节点将此事务更新到db中。性能上会有一定的降低，响应时间会变长。如下图所示：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2_size_16_color_FFFFFF_t_70 1]  
半同步模式不是mysql内置的，从mysql 5.5开始集成，需要master 和slave 安装插件开启半同步模式。

## 全同步模式 ##

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

# 二、基于GTID的半同步复制模式的实现 #

该实验必须在实现基于GTID的主从复制的基础上进行，基于GTID的主从复制可参考：[https://blog.csdn.net/qq\_35887546/article/details/104755817][https_blog.csdn.net_qq_35887546_article_details_104755817]

## 配置server1（主库） ##

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

[root@server1 mysql]# mysql -uroot -pWestos+001
    
    mysql> install plugin rpl_semi_sync_master soname 'semisync_master.so';
    Query OK, 0 rows affected (0.09 sec)

查看插件是否加载成功

mysql> select PLUGIN_NAME,PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS where PLUGIN_NAME like '%semi%';

![在这里插入图片描述][20200309182856696.png]

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

mysql> SET GLOBAL rpl_semi_sync_master_enabled=1;			#启动半同步复制
    Query OK, 0 rows affected (0.00 sec)

mysql> show status like '%rpl%';		#查看半同步复制的状态是否是打开状态的
    mysql>  show variables like '%rpl%';		#查看半同步复制的一些参数变量

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2_size_16_color_FFFFFF_t_70 2]![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2_size_16_color_FFFFFF_t_70 3]

`rpl_semi_sync_master_timeout`的值是10000（单位是毫秒），表示半同步复制时，当从库的io线程关闭时，主库等待10s。  
当然10s这个时间是可以改的，通过参数`SET GLOBAL rpl_semi_sync_master_timeout =N`;更改。在实际的生产过程中，为了防止数据丢失，一般将N设置为无穷大。

## 配置server2（从库） ##

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

[root@server2 mysql]# mysql -uroot -pWestos+001

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

查看插件是否加载成功

![在这里插入图片描述][20200309183605642.png]

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

mysql> SET GLOBAL rpl_semi_sync_slave_enabled=1;		#启动半同步复制
    Query OK, 0 rows affected (0.00 sec)

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

mysql> stop slave IO_THREAD;
    Query OK, 0 rows affected (0.02 sec)
    
    mysql> start slave IO_THREAD;
    Query OK, 0 rows affected (0.00 sec)

查看半同步复制状态

mysql> show status like '%rpl%';			#查看半同步复制是否打开
    mysql> show variables like '%rpl%';			#查看半同步复制的一些参数变量

![在这里插入图片描述][20200309183831558.png]

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2_size_16_color_FFFFFF_t_70 4]

## 测试： ##

1.在从库关闭io线程

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

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

mysql> use westos;
    Reading table information for completion of table and column names
    You can turn off this feature to get a quicker startup with -A
    
    Database changed
    mysql> insert into usertb values ('user6','666');
    Query OK, 1 row affected (10.06 sec)				#一直停留10秒才会返回OK

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

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

Rpl\_semi\_sync\_master\_no\_tx为失败次数，yes为成功次数

Rpl\_semi\_sync\_master\_yes\_tx为1，半同步成功

mysql> show status like '%rpl%';
    +--------------------------------------------+-------+
    | Variable_name                              | Value |
    +--------------------------------------------+-------+
    | Rpl_semi_sync_master_clients               | 0     |
    | Rpl_semi_sync_master_net_avg_wait_time     | 0     |
    | Rpl_semi_sync_master_net_wait_time         | 0     |
    | Rpl_semi_sync_master_net_waits             | 1     |
    | Rpl_semi_sync_master_no_times              | 1     |
    | Rpl_semi_sync_master_no_tx                 | 1     |
    | Rpl_semi_sync_master_status                | OFF   |
    | Rpl_semi_sync_master_timefunc_failures     | 0     |
    | Rpl_semi_sync_master_tx_avg_wait_time      | 0     |
    | Rpl_semi_sync_master_tx_wait_time          | 0     |
    | Rpl_semi_sync_master_tx_waits              | 0     |
    | Rpl_semi_sync_master_wait_pos_backtraverse | 0     |
    | Rpl_semi_sync_master_wait_sessions         | 0     |
    | Rpl_semi_sync_master_yes_tx                | 0     |
    +--------------------------------------------+-------+
    14 rows in set (0.00 sec)

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

发现内容没有同步

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

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

## 结论： ##

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

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

**值的注意的是：**

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

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200309172743325.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/2020030917311616.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2,size_16,color_FFFFFF,t_70
[https_blog.csdn.net_qq_35887546_article_details_104755817]: https://blog.csdn.net/qq_35887546/article/details/104755817
[20200309182856696.png]: https://img-blog.csdnimg.cn/20200309182856696.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20200309183113864.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/20200309183245540.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2,size_16,color_FFFFFF,t_70
[20200309183605642.png]: https://img-blog.csdnimg.cn/20200309183605642.png
[20200309183831558.png]: https://img-blog.csdnimg.cn/20200309183831558.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2_size_16_color_FFFFFF_t_70 4]: https://img-blog.csdnimg.cn/20200309183856875.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1ODg3NTQ2,size_16,color_FFFFFF,t_70