异步复制(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.1.1 | master |
server2 | 172.25.1.2 | slave |
本实验是在mysql基于gtid的异步复制搭建好的基础上进行的,这里不再赘述了。具体部署方法参考MySQL数据库集群实战(2)——MySQL主从复制之异步复制(传统复制postion与GTID)
在主库上(server1):
步骤一:安装插件
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%';
mysql> SET GLOBAL rpl_semi_sync_master_enabled =1;
在slave节点上(server2):
步骤一:安装插件并激活
mysql> INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
mysql> SET GLOBAL rpl_semi_sync_slave_enabled =1;
mysql> STOP SLAVE IO_THREAD;
mysql> START SLAVE IO_THREAD;
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 |
| rpl_semi_sync_master_trace_level | 32 |
| rpl_semi_sync_master_wait_for_slave_count | 1 |
| rpl_semi_sync_master_wait_no_slave | ON |
| rpl_semi_sync_master_wait_point | AFTER_SYNC |
| rpl_stop_slave_timeout | 31536000 |
在slave节点上查看:
mysql> show variables like '%rpl%';
参数说明:
±--------------------------------±---------+
| Variable_name | Value |
±--------------------------------±---------+
| rpl_semi_sync_slave_enabled | ON |
| rpl_semi_sync_slave_trace_level | 32 |
| rpl_stop_slave_timeout | 31536000 |
±--------------------------------±---------+
测试半同步是否配置成功:
在slave(server2)上
停止io线程
mysql> STOP SLAVE IO_THREAD;
插入数据
mysql> use yan;
mysql> insert into test values ('user5','20');
#等待10s才成功,因为上面超时时间是10s,10s后如果没有收到slave节点的返回,就会切换到异步复制
mysql> show status like '%rpl%';
mysql> insert into test values ('user6','15');
开启io线程
mysql> START SLAVE IO_THREAD;
mysql> show processlist;输出结果显示了有哪些线程在运行
id列 | 一个标识 |
---|---|
user列 | 显示当前用户,如果不是root,这个命令就只显示你权限范围内的sql语句 |
host列 | 显示这个语句是从哪个ip 的哪个端口上发出的。可用来追踪出问题语句的用户 |
db列 | 显示这个进程目前连接的是哪个数据库 |
command列 | 显示当前连接的执行的命令,一般就是休眠(sleep),查询(query),连接(connect) |
time列 | 此这个状态持续的时间,单位是秒 |
state列 | 显示使用当前连接的sql语句的状态 |
查看表信息,已经复制过来
mysql> select * from test;
查看进程
mysql> show processlist;