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

接上一篇blog,现在证实5.6的半同步复制。

截图如下。

主库会话一查询数据。

将从库io复制线程停止,主库会话一继续插入数据,由于同步断料,出现等待。

主库开启会话二,查询数据,发现会话一的数据已经插入。

查询主库binlog,发现该事务写入binlog。

总结:

5.6中,写入binlog后,在等待从库返回确认信息之前,事务直接提交到引擎,此时刷新可以看到数据。若此时主库宕机,主从切换后,由于该事物未同步到从库,所以再次刷新发现数据丢失。

时间: 2024-10-03 19:58:12

MySQL5.6半同步复制-非强一致性的相关文章

mysql5.5半同步复制

一.实验目的: mysql在主从复制还支持半同步复制,mysql复制是异步的,因为同步性能非常差.主库分发事件以后必须等待从库复制数据结束并收到从库正常响应以后,才能进行下一步操作.异步模式导致从库落后主库时,主库无从得知.因此mysql5.5后引入google补丁半同步复制,2个插件:semisync_master.so与semisync_slave.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.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 大大降低了半同步复制-数据丢失的风险

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

【可靠性】Mysql 5.7 降低了半同步复制-数据丢失的风险

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

Mysql5.7基于GTID的半同步复制

一.GTID是什么 GTID是事务的ID,唯一识别号,全局唯一.随事务记录到Binary Log中,用来标识事务.每个事务有一个Gtid_log_event.GTID的构成:UUID + Sequence Number Sequence Number是MySQL服务器内部的一个事务顺序号.一个MySQL服务器上的事务不会有重复的顺序号(保证服务器内唯一).每个MySQL服务器有一个全局唯一的UUID. GTID的目的简化复制的使用过程和降低复制集群维护的难度,不再依赖Master的binlog文

mysql-5.6.x半同步复制配置

本文环境   主库:CentOS6.5 x64 192.168.0.65 mysql-5.6.29    备库:CentOS6.5 x64 192.168.0.66 mysql-5.6.29 接上文: mysql-5.6主从同步配置示例http://koumm.blog.51cto.com/703525/1764093 半同步复制的概念:    mysql5.5.x以上版本支持半同步复制,当Slave主机连接到Master时,能够查看其是否处于半同步复制的机制.当Master上开启半同步复制的功