企业级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数据库集群实战(3)—— MySQL主从复制之半同步复制_第1张图片

 

步骤二:

激活插件

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;                       ##激活插件 

企业级mysql数据库集群实战(3)—— MySQL主从复制之半同步复制_第2张图片

 

步骤二:

重启IO线程使半同步生效

企业级mysql数据库集群实战(3)—— MySQL主从复制之半同步复制_第3张图片

 

步骤三:

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

mysql> show status like '%rpl%';

企业级mysql数据库集群实战(3)—— MySQL主从复制之半同步复制_第4张图片

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

查看半同步参数

mysql> show variables like '%rpl%';

企业级mysql数据库集群实战(3)—— MySQL主从复制之半同步复制_第5张图片

各个参数的解释如下:

±------------------------------------------±-----------+
| 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线程

企业级mysql数据库集群实战(3)—— MySQL主从复制之半同步复制_第6张图片

企业级mysql数据库集群实战(3)—— MySQL主从复制之半同步复制_第7张图片

 

步骤二:

在master(server1)上:插入数据

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

企业级mysql数据库集群实战(3)—— MySQL主从复制之半同步复制_第8张图片

企业级mysql数据库集群实战(3)—— MySQL主从复制之半同步复制_第9张图片

查看半同步状态也是OFF

企业级mysql数据库集群实战(3)—— MySQL主从复制之半同步复制_第10张图片

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

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

 

步骤三:

在slave节点上:

开启io线程

mysql> START SLAVE IO_THREAD;

企业级mysql数据库集群实战(3)—— MySQL主从复制之半同步复制_第11张图片

 

步骤四:

查看进程

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

企业级mysql数据库集群实战(3)—— MySQL主从复制之半同步复制_第12张图片

说明各列的含义和用途

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

 

步骤五:

查看数据是否同步

企业级mysql数据库集群实战(3)—— MySQL主从复制之半同步复制_第13张图片

企业级mysql数据库集群实战(3)—— MySQL主从复制之半同步复制_第14张图片

 

步骤六:

在master节点上:

查看进程

mysql> show processlist;

企业级mysql数据库集群实战(3)—— MySQL主从复制之半同步复制_第15张图片

 

总结:

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

你可能感兴趣的:(企业级mysql数据库集群实战(3)—— MySQL主从复制之半同步复制)