Mysql5.7 半同步改进

Mysql5.6半同步策略

Mysql 5.6在半同步的时候,采用的是After Commit策略。即在主库上commit了之后,等待从库返回确认。

在这里,首先会出现幻读的问题,即当前连接的事务读取不到这条记录,而其他连接因为主库已经提交了事务,所以能读取到这条记录。

其次,如果在主库等待从库确认的过程中,主库宕机。此时有两种情况:

1. 事务还没有提交到从库。此时客户端会得到失败的结果。此时如果从库切换为主库,主库恢复变为从库,客户端提交数据到原来的从库,就会发现原来的主库上数据被重复提交。

2. 事务已经提交到从库。此时主库向客户端返回提交失败,而从库已经提交了事务。再次提交的时候,从库便会多出一个事务。

Mysql5.7上半同步的改进

Mysql5.7上,主从的同步等待由主库提交之后等待改为了主库提交之前等待,即 Before Commit。这样就保证了从库在提交了事务之后,主库才会提交事务并返回。从一定程度上解决了主从不一致的问题。

并且,在Mysql5.7上提供了rpl semi sync master wait_point配置,来决定半同步在什么地方等待从库返回。

rpl_semi_sync_master_wait_point

AFTER

SYNC

新的半同步方案,Waiting Slave dump在Storage Commit之前。

COMMIT

老的半同步方案,Waiting Slave dump在Storage Commit之后。

时间: 2024-08-24 00:13:22

Mysql5.7 半同步改进的相关文章

mysql5.5半同步复制

一.实验目的: mysql在主从复制还支持半同步复制,mysql复制是异步的,因为同步性能非常差.主库分发事件以后必须等待从库复制数据结束并收到从库正常响应以后,才能进行下一步操作.异步模式导致从库落后主库时,主库无从得知.因此mysql5.5后引入google补丁半同步复制,2个插件:semisync_master.so与semisync_slave.so.半同步:一主多从架构中,主库只等待一台从库复制完成数据并返回正常响应,就认为同步完成进行下一步操作,这样即有异步的高速,又有同步的安全.一

MySQL5.7半同步复制环境搭建

参考博客: http://blog.chinaunix.net/uid-21879027-id-3258210.html 基本环境 master slave mysql版本 mysql-5.7.14x86_64  mysql-5.7.14x86_64 ip 192.168.0.100 192.168.0.101 port 3306 3306 配置注意事项 master: INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so'

关于Mysql5.6半同步主从复制的开启方法

介绍 先了解一下mysql的主从复制是什么回事,我们都知道,mysql主从复制是基于binlog的复制方式,而mysql默认的主从复制方式,其实是异步复制. 主库实际上并不关心从库是否把数据拉完没有,也不关心从库有没有把数据写进硬盘入库,反正数据丢过去,让从库自己慢慢跑,而实际上这也并不影响主库任何使用的情况. 细心的人就会发现,这种情况下,假如主库临时挂了,binlog还没传输完毕,即使是集群也不能保证说这挂了之后的数据一致性,因为你不能排除别人在主库是正常提交的,而从库没有数据的情况. 然后

MySQL5.7 半同步复制

一.概述 5.5与5.7的半同步复制可能存在差异,从MySQL5.5开始,MySQL以插件的形式支持半同步复制 异步:默认情况下,MySQL复制是异步的.主库在执行完客户端提交的事务后会立即将结果返给给客户端,并不关心从库是否已经接收并处理.此时若是主若是崩溃了,那提交完成的事务可能并没有传到从上,从而导致数据不一致. 全同步:当主库执行完接受到的事务,会等待所有从机执行此事务的返回值,当收到所有从机的返回值时才会返回给客户端.所以对性能的影响严重. 半同步:介于以上两者之间,主库在执行完客户端

Percona MySQL5.6 半同步复制

先配置普通的clone 两台服务器,一主一备 主服务器: 10.10.1.30 Slave: 10.10.1.200 修改每台机器的my.cnf文件,分别修改server_id 主服务器server_id= 1 ,slave 的server_id=2 重启两台服务器,通过: show variables like 'server_id'; 可以查看到两台服务器的server_id均不一样. 登录Master,输入: grant replication slave on *.* to 'repl'

MySQL5.6 半同步复制,保证数据库一致性

半同步复制需要使用插件,主从节点都需要安装插件.插件安装完之后 ,配置系统变量就可以启用和关闭半同步复制功能. 1.半同步实施前提 数据库版本为 5.5以上 have_dynamic_loading system variable 为 YES. 复制已经正常运行. 2.安装插件 主节点 INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so'; 从节点  INSTALL PLUGIN rpl_semi_sync_slave S

MySQL5.7半同步强复制

这里不赘述5.7的安装步骤,主要注意初始化方法和配置文件,有了很大的改动,同时5.7加强了安全性,初始化后会给出密码,第一次登陆要修改密码. OK,废话少说,回到主题,5.7的半同步强复制. 半同步复制搭建与5.6版本没有差别,搭建过程略. 将主库的半同步时间加长.参数如下图. 主库创建测试库测试表.插入数据. 从库查询数据. 主库开启另一会话-会话二,查询数据. 停掉从库io复制线程. 主库会话一继续插入数据,产生等待. 主库会话二查询数据,查询不到会话一后续插入的数据. 此步骤不同于5.6,

MySQL5.6半同步复制-非强一致性

接上一篇blog,现在证实5.6的半同步复制. 截图如下. 主库会话一查询数据. 将从库io复制线程停止,主库会话一继续插入数据,由于同步断料,出现等待. 主库开启会话二,查询数据,发现会话一的数据已经插入. 查询主库binlog,发现该事务写入binlog. 总结: 5.6中,写入binlog后,在等待从库返回确认信息之前,事务直接提交到引擎,此时刷新可以看到数据.若此时主库宕机,主从切换后,由于该事物未同步到从库,所以再次刷新发现数据丢失.

MySQL主从复制--MySQL5.5异步、半同步配置

大纲 一.主从复制复制原理 二.主从复制的作用及复制类型 三.MySQL5.5异步复制的实现 四.MySQL5.5半同步复制的实现 一.主从复制原理 工作原理 1.当Master接收到了一个写请求,处理写请求,将结果保存至磁盘中,并且会将此操作记录到二进制日志文件中 2.Slave会从Master的二进制日志中读取其中的事件保存至本地的中继日志中 3.Slave会启动一个线程来逐条读取中继日志中的事件并应用于本地的 二.主从复制的作用及复制类型 复制的作用 辅助实现备份 提供类似高可用的机制 异