企业级mysql数据库集群实战（3）—— MySQL主从复制之半同步复制

本实验在上一个实验的基础上完成《企业级mysql数据库集群实战（2）—— MySQL主从复制之异步复制（传统复制Postion与Gtid）》，server1为主从复制的master、server2为主从复制的slave 、已经配置好主从复制的相关实验环境。

上一篇的博客链接：https://blog.csdn.net/dghfttgv/article/details/105106742

目录：

一、半同步复制简介

（一）、掌握Mysql复制方式的区别及优缺点

• 异步复制（Asynchronous replication）
• 全同步复制（Fully synchronous replication）
• 半同步复制（Semisynchronous replication）

（二）、了解半同步复制出现的必要性查看进程
（三）、半同步工作原理

二、半同步实验的部署

1、在主库上（server1）：

• 步骤一：安装插件
• 步骤二：激活插件

2、在slave节点上（server2）：

• 步骤一：在slave（server2）上停止I/O线程安装插件并激活
• 步骤二：重启IO线程使半同步生
• 步骤三：在master节点上查看半同步复制是否生效

3、测试半同步是否配置成功：

• 步骤一：在slave（server2）上停止I/O线程
• 步骤二：在master（server1）上：插入数据
• 步骤三：在slave节点上：开I/O线程
• 步骤四：查看进程
• 步骤五：查看数据是否同步
• 步骤六：在master节点上：查看进程
• 总结

 

一、半同步复制简介

（一）、掌握Mysql复制方式的区别及优缺点

• 异步复制（Asynchronous replication）

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

• 全同步复制（Fully synchronous replication）

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

• 半同步复制（Semisynchronous replication）

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

在2010年MySQL 5.5版本之前，一直采用的是这种异步复制的方式。主库的事务执行不会管备库的同步进度，如果备库落后，主库不幸crash，那么就会导致数据丢失。于是在MySQL在5.5中就顺其自然地引入了半同步复制，主库在应答客户端提交的事务前需要保证至少一个从库接收并写到relay log中。

（二）、了解半同步复制出现的必要性

1）正常的复制为：事务一（t1）写入binlog buffer；dumper线程通知slave有新的事务t1；binlog buffer进行checkpoint；slave的io线程接收到t1并写入到自己的的relay log；slave的sql线程写入到本地数据库。 这时，master和slave都能看到这条新的事务，即使master挂了，slave可以提升为新的master。

2）异常的复制为：事务一（t1）写入binlog buffer；dumper线程通知slave有新的事务t1；binlog buffer进行checkpoint；slave因为网络不稳定，一直没有收到t1；master挂掉，slave提升为新的master，t1丢失。

3）很大的问题是：主机和从机事务更新的不同步，就算是没有网络或者其他系统的异常，当业务并发上来时，slave因为要顺序执行master批量事务，导致很大的延迟。

为了弥补以上几种场景的不足，MySQL从5.5开始推出了半同步复制。相比异步复制，半同步复制提高了数据完整性，因为很明确知道，在一个事务提交成功之后，这个事务就至少会存在于两个地方。即在master的dumper线程通知slave后，增加了一个ack（消息确认），即是否成功收到t1的标志码，也就是dumper线程除了发送t1到slave，还承担了接收slave的ack工作。如果出现异常，没有收到ack，那么将自动降级为普通的复制，直到异常修复后又会自动变为半同步复制。

 

（三）、半同步工作原理

从库会在连接到主库时告诉主库，它是否配置了半同步。
如果半同步复制在主库端是开启了的，并且至少有一个半同步复制的从库节点，那么此时主库的事务线程在提交时会被阻塞并等待，结果有两种可能，要么至少一个从库节点通知它已经收到了所有这个事务的Binlog事件，要么一直等待直到超过配置的某一个时间点为止，而此时，半同步复制将自动关闭，转换为异步复制。
从库节点只有在接收到某一个事务的所有Binlog，将其写入并Flush到Relay Log文件之后，才会通知对应主库上面的等待线程。
如果在等待过程中，等待时间已经超过了配置的超时时间，没有任何一个从节点通知当前事务，那么此时主库会自动转换为异步复制，当至少一个半同步从节点赶上来时，主库便会自动转换为半同步方式的复制。

半同步复制必须是在主库和从库两端都开启时才行，否则主库默认使用异步方式复制。

 

二、半同步实验的部署

实验环境

主机名	ip	服务
server1	172.25.6.1	数据库master
server2	172.25.6.2	数据库slave

查看server1、server2主机的3306端口是否开启

 

1、在主库上（server1）：

步骤一：

安装插件

[root@server1 ~]# mysql -uroot -pYang+123love     ##登录数据库
mysql> INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';  ##安装插件 
mysql> SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME LIKE '%semi%';   ##查看插件是否安装 
+----------------------+---------------+
| PLUGIN_NAME          | PLUGIN_STATUS |
+----------------------+---------------+
| rpl_semi_sync_master | ACTIVE        |
+----------------------+---------------+

 

步骤二：

激活插件

mysql> SET GLOBAL rpl_semi_sync_master_enabled =1;     ##激活插件

 

2、在slave节点上（server2）：

步骤一：

安装插件并激活

mysql> INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';   ##安装插件
mysql> SET GLOBAL rpl_semi_sync_slave_enabled =1;                       ##激活插件 

 

步骤二：

重启IO线程使半同步生效

 

步骤三：

在master节点上查看半同步复制是否生效

mysql> show status like '%rpl%';

看到| Rpl_semi_sync_master_status | ON |
表示已开启半同步复制

查看半同步参数

mysql> show variables like '%rpl%';

各个参数的解释如下：

±------------------------------------------±-----------+
| Variable_name | Value |
±------------------------------------------±-----------+
| rpl_semi_sync_master_enabled | ON |

•     是否开启半同步

| rpl_semi_sync_master_timeout | 10000 |

•     切换复制的timeout

| rpl_semi_sync_master_trace_level | 32 |

•     用于开启半同步复制模式时的调试级别,默认是32

| rpl_semi_sync_master_wait_for_slave_count | 1 |

•     至少有N个slave接收到日志

| rpl_semi_sync_master_wait_no_slave | ON |

•     是否允许master 每个事物提交后都要等待slave的receipt信号。默认为on

| rpl_semi_sync_master_wait_point | AFTER_SYNC |

•     等待的point

| rpl_stop_slave_timeout | 31536000 |

• 控制stop slave 的执行时间，在复制一个大的事务的时候,突然执行stop slave,命令 stop slave会执行很久,这个时候可能产生死锁或阻塞,严重影响性能
   

 

3、测试半同步是否配置成功：

步骤一：

在slave（server2）上停止I/O线程

mysql> STOP SLAVE IO_THREAD;        ##停止I/O线程

 

步骤二：

在master（server1）上：插入数据

mysql> use yang  
mysql> insert into test values('user6','26');       ##插入数据
mysql> show status like '%rpl%';
#等待10s才成功，因为上面超时时间是10s，10s后如果没有收到slave节点的返回，就会切换到异步复制

查看半同步状态也是OFF

再次插入时就不会延迟，因为已经是异步了

mysql> insert into test values('user7','27');  ##已经是异步复制了

 

步骤三：

在slave节点上：

开启io线程

mysql> START SLAVE IO_THREAD;

 

步骤四：

查看进程

mysql> show processlist;输出结果显示了有哪些线程在运行

说明各列的含义和用途

id列	一个标识
user列	显示当前用户，如果不是root，这个命令就只显示你权限范围内的sql语句
host列	显示这个语句是从哪个ip 的哪个端口上发出的。可用来追踪出问题语句的用户
db列	显示这个进程目前连接的是哪个数据库
command列	显示当前连接的执行的命令，一般就是休眠（sleep），查询（query），连接（connect）
time列	此这个状态持续的时间，单位是秒
state列	显示使用当前连接的sql语句的状态

 

步骤五：

查看数据是否同步

 

步骤六：

在master节点上：

查看进程

mysql> show processlist;

 

总结：

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