MySQL5.7半同步强复制

这里不赘述5.7的安装步骤,主要注意初始化方法和配置文件,有了很大的改动,同时5.7加强了安全性,初始化后会给出密码,第一次登陆要修改密码。

OK,废话少说,回到主题,5.7的半同步强复制。

半同步复制搭建与5.6版本没有差别,搭建过程略。

将主库的半同步时间加长。参数如下图。

主库创建测试库测试表。插入数据。

从库查询数据。

主库开启另一会话-会话二,查询数据。

停掉从库io复制线程。

主库会话一继续插入数据,产生等待。

主库会话二查询数据,查询不到会话一后续插入的数据。

此步骤不同于5.6,5.6中另一会话可以查询到该值,后续会找时间进行证明。

将主库进程kill掉,然后查看主库binlog,发现binlog中记录了插入值。

总结:

5.7的半同步强一致性,为after_sync时,事务刷入binlog后,会等待从库返回确认信息,返回后在写入引擎层,否则等待。开启另一回话(用户刷新)不会发现该事务。

5.6中主库不等待从库返回确认信息,直接将事务写入引擎层。开启另一回话(用户刷新)会发现该事务。

5.7加强了半同步的强一致性。

时间: 2024-09-30 16:27:06

MySQL5.7半同步强复制的相关文章

mysql5.5半同步复制

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

Mysql5.7 半同步改进

Mysql5.6半同步策略 Mysql 5.6在半同步的时候,采用的是After Commit策略.即在主库上commit了之后,等待从库返回确认. 在这里,首先会出现幻读的问题,即当前连接的事务读取不到这条记录,而其他连接因为主库已经提交了事务,所以能读取到这条记录. 其次,如果在主库等待从库确认的过程中,主库宕机.此时有两种情况: 1. 事务还没有提交到从库.此时客户端会得到失败的结果.此时如果从库切换为主库,主库恢复变为从库,客户端提交数据到原来的从库,就会发现原来的主库上数据被重复提交.

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.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.6半同步复制-非强一致性

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

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

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

MySQL5.7 大大降低了半同步复制-数据丢失的风险

如果你的生产线开启了半同步复制,那么对数据的一致性会要求较高,但在MySQL5.5/5.6里,会存在数据不一致的风险.有这么一个场景,客户端提交了一个事务,master把binlog发送给slave,在发送的期间,网络出现波动,此时Binlog Dump线程发送就会卡住,要等待slave把binlog写到本地的relay-log里,然后给master一个反馈,等待的时间以rpl_semi_sync_master_timeout参数为准,默认为10秒.在这等待的10秒钟里,在其他会话里,查看刚才的