PostgreSQL的同步级别与MySQL的半同步after_sync比较
MySQL的半同步中通过binlog进行流复制,同步级别和PostgreSQL对比可以发现:
PostgreSQL MySQL
off
local after_commit
remote_write after_sync
remote_apply
on
所以,整体来说MySQL的日志同步上还是没有PostgreSQL做的严谨,在金融系统中,PostgreSQL的日志同步级别都是设置为on,即日志接收到,apply,然后等待数据刷盘才返回commit的ack。
Specifies whether transaction commit will wait for WAL records to be written to disk before the command returns a “success” indication to the client. Valid values are on, remote_apply, remote_write, local, and off. The default, and safe, setting is on. When off, there can be a delay between when success is reported to the client and when the transaction is really guaranteed to be safe against a server crash. (The maximum delay is three times wal_writer_delay.) Unlike fsync, setting this parameter to off does not create any risk of database inconsistency: an operating system or database crash might result in some recent allegedly-committed transactions being lost, but the database state will be just the same as if those transactions had been aborted cleanly. So, turning synchronous_commit off can be a useful alternative when performance is more important than exact certainty about the durability of a transaction. For more discussion see Section 30.3. If synchronous_standby_names is non-empty, this parameter also controls whether or not transaction commits will wait for their WAL records to be replicated to the standby server(s). When set to on, commits will wait until replies from the current synchronous standby(s) indicate they have received the commit record of the transaction and flushed it to disk. This ensures the transaction will not be lost unless both the primary and all synchronous standbys suffer corruption of their database storage. When set to remote_apply, commits will wait until replies from the current synchronous standby(s) indicate they have received the commit record of the transaction and applied it, so that it has become visible to queries on the standby(s). When set to remote_write, commits will wait until replies from the current synchronous standby(s) indicate they have received the commit record of the transaction and written it out to their operating system. This setting is sufficient to ensure data preservation even if a standby instance of PostgreSQL were to crash, but not if the standby suffers an operating-system-level crash, since the data has not necessarily reached stable storage on the standby. Finally, the setting local causes commits to wait for local flush to disk, but not for replication. This is not usually desirable when synchronous replication is in use, but is provided for completeness. If synchronous_standby_names is empty, the settings on, remote_apply, remote_write and local all provide the same synchronization level: transaction commits only wait for local flush to disk. This parameter can be changed at any time; the behavior for any one transaction is determined by the setting in effect when it commits. It is therefore possible, and useful, to have some transactions commit synchronously and others asynchronously. For example, to make a single multistatement transaction commit asynchronously when the default is the opposite, issue SET LOCAL synchronous_commit TO OFF within the transaction.
下面转自:https://www.jianshu.com/p/3bfb0bfb8b34
今天主要剖析一下MySQL 5.7增强半同步的AFTER SYNC和AFTER COMMIT的区别。
如果我们生产库对数据的一致性要求比较高,那么我们一般会开启了半同步复制,但在MySQL5.5/5.6里,会存在数据不一致的风险。比如有如下场景,客户端提交了一个事务,master把binlog发送给slave,在发送的期间,网络出现波动,此时Binlog Dump线程发送就会卡住,要等待slave把binlog写到本地的relay-log里,然后给master一个反馈,等待的时间以rpl_semi_sync_master_timeout参数为准,默认为10秒。在这等待的10秒钟里,在其他会话里,查看刚才的事务是可以看见的,此时一旦master发生宕机,由于binlog没有发送给slave,前端app切到slave查看,就会发现刚才已提交的事务不见了。盗用两张图讲解一下两者的区别。
- AFTER SYNC
after sync是MySQL5.7官方新加的用以解决MySQL5.6半同步缺陷的选项,也是官方推荐的方式。下面我结合图来说明一下AFTER SYNC是怎么回事。image实际上,客户端发出commit请求后,在主库上写入binlog并推送给slave,slave接收到binlog并写入relaylog,发送ACK确认已经接收binlog后,master在引擎层commit,客户端接收commit完成,此时其他会话才可以看见已提交的数据。
故障分析:假设master在接收ACK确认时宕机,因为在引擎层并没有提交,HA切换到从库,因为binlog已经写入从库的relaylog,因此不会造成数据丢失,个人认为是目前比较完美的解决方式。
- AFTER COMMIT
image
after commit是MySQL5.6半同步参数,区别于after sync,after sync是在接收ack确认以后主库在引擎层做提交,而after commit是先在引擎层做提交后等待ACK确认。因此,在写入数据后并且在从库确认之前,其他的客户端可以看到在这一事务。
故障分析:
1.binlog 未发送到从库:
事务B获取到事务A提交的内容, 此时宕机故障切换到slave,事务B获取到的内容却丢失了。事务A commit没有收到反馈信息(则需要业务判断了)。
2.binlog 已经发送给从库 :
事务B获取到事务A提交的内容,故障切换到salve ,B仍然获取到A提交的内容,没毛病。事务A commit没有收到反馈信息,若重新执行该事务,则相当于执行两次A事务(则需要业务判断了)。
dump thread过程分析:
- mysql5.6版本之前:
1. master dump thread 发送binlog events 给 slave 的IO thread,等待 slave 的ack反馈
2. slave 接受binlog events 写入relay log ,返回 ack 消息给master dump thread
3. master dump thread 收到ack消息,给session返回commit ok,然后继续发送写一个事务的binlog。
- mysql5.7之后新增ack线程:
1. master dump thread 发送binlog events 给 slave 的IO thread,开启ack线程等待 slave 的ack反馈,dump 线程继续向slaveIO thread发送下一个事务的binlog。
2. slave 接受binlog events 写入relay log ,返回 ack 消息给master ack线程,然后给session返回commit ok。
过程总结:
1.Master在收到slave的应答后才Commit事务--after_sync(5.6上Master在commit后,才等待Slave的应答--after commit).
因此在确认事务复制到Slave上之前,并发的事务看不到当前事务的数据.当Master出现故障时,所有已经提交的事务都复制到了Slave上.
2.缺省采用无数据丢失的应答等待机制after_sync。用户也可以选择使用5.6的应答等待机制after_commit
设置方法:
mysql> SET rpl_semi_sync_master_wait_point= AFTER_SYNC;
Master接收到N个slave的应答后,才commit 事务.
用户可以设置应答Slave的数量:
mysql> SET GLOBAL rpl_semi_sync_master_wait_for_slave_count= N;
PostgreSQL的同步级别与MySQL的半同步after_sync比较的更多相关文章
- MySQL主从复制半同步复制原理及搭建
在MySQL5.5之前的版本中,MySQL的复制是异步复制,主库和从库的数据之间存在一定的延迟,比如网络故障等各种原因,这样子容易存在隐患就是:当在主库写入一个事务成功后并提交了,但是由于从库延迟没有 ...
- MySQL增强半同步的搭建实验,和一些参数的个人理解
关于参数理解,已补充实验,可以查看: rpl_semi_sync_master_wait_no_slave 参数研究实验 环境信息 role ip port hostname master 192.1 ...
- MySQL的半同步是什么?
前言 年后在进行腾讯二面的时候,写完算法的后问的第一个问题就是,MySQL的半同步是什么?我当时直接懵了,我以为是问的MySQL的两阶段提交的问题呢?结果确认了一下后不是两阶段提交,然后面试官看我连问 ...
- MySQL系列详解六:MySQL主从复制/半同步演示-技术流ken
前言 随着技术的发展,在实际的生产环境中,由单台MySQL数据库服务器不能满足实际的需求.此时数据库集群就很好的解决了这个问题了.采用MySQL分布式集群,能够搭建一个高并发.负载均衡的集群服务器.在 ...
- Bullet:MySQL增强半同步参数rpl_semi_sync_master_wait_point值AFTER_SYNC和AFTER_COMMIT的对比实验
MySQL 5.7.22启用增强半同步复制 MySQL对该参数值的描述 Semisync can wait for slave ACKs at one of two points, AFTER_SYN ...
- mysql的半同步复制
1. binlog dump线程何时向从库发送binlog mysql在server层进行了组提交之后,为了提高并行度,将提交阶段分为了 flush sync commit三个阶段,根据sync_bi ...
- MySQL增强半同步几个重要参数搭配的测试
Preface Semi-synchronous replication is supported since MySQL 5.5 and then enhanced graduall ...
- MySQL的半同步复制监控
(1)master端 >show variables like 'rpl_semi_sync%'; +------------------------------------+-------+ ...
- mysql主主半同步
1.半同步概述 先了解下mysql的几种复制 异步复制MySQL复制默认是异步复制,Master将事件写入binlog,提交事务,自身并不知道slave是否接收是否处理:缺点:不能保证所有事务都被所有 ...
随机推荐
- 2g 大文件上传
核心原理: 该项目核心就是文件分块上传.前后端要高度配合,需要双方约定好一些数据,才能完成大文件分块,我们在项目中要重点解决的以下问题. * 如何分片: * 如何合成一个文件: * 中断了从哪个分片开 ...
- Linux可变参数打印日志(二)
#include<stdio.h> #include<stdlib.h> #include<stdarg.h> #include<string.h> # ...
- Multi-judge Solving
C. Multi-judge Solving 写这个题的时候也是思维出了漏洞....容易漏掉的一点就是在别的 oj 上做了题之后可能不能够马上回原来的 oj 上做题,这是写循环的时候需要注意的的方,需 ...
- VMware中出现物理内存不足,无法使用配置的设置开启虚拟机解决方案
前几天给大家分享了如何在VMware中安装CentOS系统,后来有小伙伴在群里咨询,当新建虚拟机之后,打开虚拟机会弹出“物理内存不足,无法使用配置的设置开启虚拟机”的问题,如下图所示.这里会给出提示, ...
- Python tuple 元组
Python 元组 Python的元组与列表类似,不同之处在于元组的元素不能修改. 元组使用小括号,列表使用方括号. 元组创建很简单,只需要在括号中添加元素,并使用逗号隔开即可. 如下实例: tup1 ...
- 测试linux服务器是否能接入微信
官方文档:https://mp.weixin.qq.com/wiki?t=resource/res_main&id=mp1421135319 php.代码 <?php $a = $_GE ...
- legend3---lavarel安装debugbar工具条
legend3---lavarel安装debugbar工具条 一.总结 一句话总结: ` lavarel插件一般是composer官网下载,然后config/app.php中声明和加别名 ` 直接照官 ...
- Java-类加载(类的生命周期)
类从被加载到虚拟机内存开始,到卸载出内存为止. 解析阶段在某些情况下可以在初始化后再开始,这是为了支持 Java 语言的运行时绑定. 一.类加载时机 JVM 规范没有强制约束类加载过程的第一阶段(加载 ...
- GitHub:IBM
ylbtech-GitHub:IBM 1.返回顶部 2.返回顶部 3.返回顶部 4.返回顶部 5.返回顶部 1. https://github.com/ibm 2. 6.返回顶部 ...
- win + T 快捷键
和 alt + tab 不同,win + T会在 在任务栏间的程序间进行switch