企业级mysql数据库集群实战(3)—— MySQL主从复制之半同步复制
目录:
一、半同步复制简介
(一)、掌握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 安装插件开启半同步模式。
标签:主从复制,同步,slave,之半,企业级,复制,master,mysql,线程 From: https://www.cnblogs.com/Lqdream/p/16918439.html