MySQL5.7 & AliSQL5.6 半同步复制 rpl_semi_sync_master_wait_point参数

MySQL5.5 开始支持半同步复制,但实现的不完善,slave ack 是在 master
commit 之后。如果 master 宕机,会有数据丢失的风险。如下图可以看出,主库在 commit 之后宕机,如果从库还未收到 binlog ,主从切换后可能会出现数据丢失的现象。

MySQL5.7 & AliSQL5.6 增加了 rpl_semi_sync_master_wait_point 参数来修复这个问题。先来看看这个参数是做什么用的。官方文档解释如下:

The rpl_semi_sync_master_wait_point system variable controls the point at which a semisynchronous replication master waits for slave acknowledgment of transaction receipt before returning a status to the client that committed the transaction.

简单来讲就是控制 master 在哪个环节接收 slave ack,master 接收到 ack 后返回状态给客户端。
此参数一共有两个选项 AFTER_SYNC(default) & AFTER_COMMIT。

我们先来看看旧的逻辑(AFTER_COMMIT):

AFTER_COMMIT: The master writes each transaction to its binary log and the slave, syncs the binary log, and commits the transaction to the storage engine. The master waits for slave acknowledgment of transaction receipt after the commit. Upon receiving acknowledgment, the master returns a result to the client, which then can proceed.

整个流程: master write binlog -> slave sync binlog -> master commit -> salve ack -> master return result。
这样会有什么问题呢?

With AFTER_COMMIT, the client issuing the transaction gets a return status only after the server commits to the storage engine and receives slave acknowledgment. After the commit and before slave acknowledgment, other clients can see the committed transaction before the committing client.

If something goes wrong such that the slave does not process the transaction, then in the event of a master crash and failover to the slave, it is possible that such clients will see a loss of data relative to what they saw on the master.

  1. 会出现脏读的情况,也就是在事务提交之后,slave 确认之前,客户端A还没有获得结果返回,但是客户端B能够读取A提交的结果;
  2. 可能会出现我们上文提到的数据丢失的问题;

这些问题对于数据一致性要求高的场景是无法满足的,所以 MySQL5.7 提供了 AFTER_SYNC 模式来避免这些问题。

AFTER_SYNC (the default): The master writes each transaction to its binary log and the slave, and syncs the binary log to disk. The master waits for slave acknowledgment of transaction receipt after the sync. Upon receiving acknowledgment, the master commits the transaction to the storage engine and returns a result to the client, which then can proceed.

整个流程: master write binlog -> slave sync binlog -> salve ack -> master commit -> master return result。这样就保证 master commit 的事务已经同步到 slave 了,防止数据丢失。

With AFTER_SYNC, all clients see the committed transaction at the same time: After it has been acknowledged by the slave and committed to the storage engine on the master. Thus, all clients see the same data on the master.

In the event of master failure, all transactions committed on the master have been replicated to the slave (saved to its relay log). A crash of the master and failover to the slave is lossless because the slave is up to date.

  1. 保证所有客户端查询到的结果都是相同的;
  2. 保证 slave 不会丢数据;
  3. master 宕机虽然不会导致数据丢失,但有一种情况可能会出现,那就是 salve 的数据比 master 多,大家可以回顾下流程,想想为什么,该如何处理。

AliSQL5.6 半同步复制已经实现此功能,并且是整合到主代码里原生支持的,而 MySQL 半同步是通过插件的形式支持

时间: 2024-07-28 21:18:40

MySQL5.7 & AliSQL5.6 半同步复制 rpl_semi_sync_master_wait_point参数的相关文章

MySQL5.5配置安装半同步复制

确认master和slave上是否开启have_dynamic_loading master MASTER(none) 10:54:58>show variables like 'have_dynamic_loading';+----------------------+-------+| Variable_name | Value |+----------------------+-------+| have_dynamic_loading | YES |+------------------

MySQL基于SSL的半同步复制

MySQL的主从复制应用场景非常多,默认的MySQL复制是基于异步且明文传输的,也就是说,速度快,但是从服务器的数据会有着一定的滞后性,明文也就意味着数据传输的不安全.因此笔者这里构建一个简单的基于加密并半同步的主从MySQL,当然由于其半同步的特性,主服务器的写操作速度必会有所降低.究竟如何选择,这取决于场景需要了. 实验环境:RHEL5.8  MySQL5.5.28 192.168.88.21       master.mos.com  master 192.168.88.22      

mysql 5.5中的半同步复制

先来看下MYSQL异步复制的概念:   异步复制:MySQL本身支持单向的.异步的复制.异步复制意味着在把数据从一台机器拷贝到另一台机器时有一个延时 – 最重要的是这意味着当应用系统的事务提交已经确认时数据并不能在同一时刻拷贝/应用到从机.通常这个延时是由网络带宽.资源可用性和系统负载决定的.然而,使用正确的组件并且调优,复制能做到接近瞬时完成.      当主库有更新的时候,主库会把更新操作的SQL写入二进制日志(Bin log),并维护一个二进制日志文件的索引,以便于日志文件轮回(Rotat

MySQL · 源码分析 · MySQL 半同步复制数据一致性分析

简介 MySQL Replication为MySQL用户提供了高可用性和可扩展性解决方案.本文介绍了MySQL Replication的主要发展历程,然后通过三个参数rpl_semi_sync_master_wait_point.sync_binlog.sync_relay_log的配置简要分析了MySQL半同步的数据一致性. MySQL Replication的发展 在2000年,MySQL 3.23.15版本引入了Replication.Replication作为一种准实时同步方式,得到广泛

MySQL · 源码分析 · MySQL BINLOG半同步复制数据安全性分析

半同步复制(semisynchronous replication)MySQL使用广泛的数据复制方案,相比于MySQL内置的异步复制它保证了数据的安 全,本文从主机在Server层提交事务开始一直到主机确认收到备机回复进行一步步解析,来看MySQL的半同步复制是怎么保证数 据安全的.本文基于MySQL 5.6源码,为了简化本文只分析DML的核心的事务处理过程,并假定事务只涉及innodb存储引擎. MySQL的事务提交流程 在MySQL中事务的提交Server层最后会调用函数ha_commit_

MySQL中的半同步复制(r11笔记第65天)

关于MySQL的复制架构,大体有下面三种方式,异步,全同步复制,半同步复制. 三种复制方式     第一种是异步复制,是比较经典的主从复制,搭建主从默认的架构方式,就是属于异步的,相对来说性能要好一些.但是还是会有丢失数据的情况.     第二种是全复制,比如说MySQL Cluster这样的方式,是属于全复制的,实际上MySQL Cluster其实发展并不大顺利,更多时候是一个实验室产品,但是时间定格在2016年12月12日,MySQL  5.7.17 GA的重大特性group replica

MySQL 5.5的半同步复制

在保证数据库性能的前提下,怎么保证数据的一致性呢? 在MySQL 5.5版本中即支持异步复制又支持半同步复制. 1.当slave 连接master的时候,它会指出它是否支持半同步复制. 2.当master启用 semisynchronous  replication.并且至少有一台slave也启用了该功能,master端的事务会被阻塞,并且等到该事务会等待其中任何一个slave接受到该事务,或者超过等待时间才会提交. 3.slave端回复给master的信息依据是slave事务已经写入到rela

mysql semi-sync(半同步复制)

半同步复制: 5.5集成到MySQL,以插件的形式存在,需要单独安装 确保事务提交后bnog至少传输到一个从库 不保证从库应用完这个事务的binlog 性能有一定的降低,响应时间会更长 网络异常或从库宕机,卡住主库直到超时或从库恢复 异步复制的逻辑 半同步复制的逻辑 安装 主库上 mysql> install plugin rpl_semi_sync_master soname 'semisync_master.so'; Query OK, 0 rows affected (0.01 sec)

MySQL 5.5中如何配置安装半同步复制

确认master和slave上是否开启have_dynamic_loading master MASTER(none) 10:54:58>show variables like 'have_dynamic_loading'; +----------------------+-------+ | Variable_name        | Value | +----------------------+-------+ | have_dynamic_loading | YES   | +----