开发者社区> dbaer> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

AlwaysON同步的原理及可用模式

简介: 早在SQL Server 2005的时候微软就已经实现了数据库的查询分离技术——发布订阅。但生产库和查询库的同步性能较差,时常出现性能问题,因此在大型生产环境中一直被人所诟病。
+关注继续查看

新一代读写分离技术——AlwaysOn

早在SQL Server 2005的时候微软就已经实现了数据库的查询分离技术——发布订阅。但生产库和查询库的同步性能较差,时常出现性能问题,因此在大型生产环境中一直被人所诟病。

从SQL Server 2012开始,微软逐渐使用AlwaysON技术来取代发布订阅。AlwaysOn 作为SQL Server 2012引入的一种新的技术架构,性能相比发布订阅而言提升很多,最明显的区别在于其充分利用内存高效读取的原理来实现日志的传递。下文将通过AlwaysOn的同步原理和可用模式来详细了解AlwaysOn的同步优势。

 

AlwaysOn同步原理

AlwaysON是一种整库同步的技术,所有的成员服务器都维护一套相同的数据库副本。当主副本上的数据发生变化时,数据会实时同步到辅助副本上。这点与数据库镜像非常类似。

下图详细描述了AlwaysON数据同步的整个过程,我们先来看看每个步骤所代表的意义。

clip_image002

① 主副本的logwiter把事务修改的日志信息先记入一段内存中的日志缓冲区,然后再写入物理日志文件(日志固化);

② 主副本的logscanner从缓存中或者日志文件中读取日志块,然后把它发送给AlwaysON的日志块解码器;

备注:解码器会搜索日志中那些需要特别处理的操作,比如file stream操作、文件增长等。

③ 主副本将日志块通过网络传送给辅助副本;

④ 和⑤

辅助副本接受到日志块后,logwiter把事务修改的日志信息先记入一段内存中的日志缓冲区,然后再写入物理日志文件(日志固化),另外,如果辅助副本处于同步可用模式时,在日志固化后,还必须反馈信息给主副本,主副本在接受到辅助副本完成固化的消息后才可以提交该事务,如果辅助副本在异步可用模式或者主副本在异步模式下,主副本提交事务与否跟辅助副本是否完成日志固化没有关系,下文在介绍可用模式时会详细介绍;

⑤ 重做(Redo)线程将日志中记录的事务在辅助副本上重新演绎。重做线程每隔固定的时间点,会跟主副本通信,告知它自己的工作进度。主副本就能够知道两边数据的差距有多远。

 

AlwaysOn VS 发布订阅

我们知道,事务日志发布订阅通常不会用于整个数据库的同步,而同步发布库中的部分对象,而AlwaysON却是整个数据库都要同步,从数据量的角度来说,AlwaysON要同步的数据要更多,那为什么其性能还更好呢?

我们从如下两个个方面的对比来寻找答案吧:

1. 同步对象

发布订阅的同步对象是已经写入到磁盘的事务日志,但不是所有的事务日志都发布,只有那些被标记为待发布的日志才会被发布,因此它不仅需要读磁盘,而且对于某个事务,扫描所有日志才能筛选到标记为待发布的日志,如果这个事务的日志非常多而待发布的日志非常少,则日志读取器的效率将非常低;

而AlwaysON同步的对象绝大部分位于内存的日志缓冲中,日志扫描器不需要读取磁盘或者只需读取少量磁盘,且AlwaysON是整库同步,只要是主副本产生的日志都会同步到辅助副本,不需要进行日志筛选,因此不仅读取速度快,而且效率还很高。

clip_image003

备注:AlwaysON同步的日志要比事务日志发布订阅的要多,但从网络角度来看不一定占用网络带宽也会更多,因为在AlwaysON中,网络上传递的是压缩了的日志,而发布订阅则没有做压缩的优化

 

2. 同步过程

在发布订阅中,日志无法直接从发布库到订阅库,期间必须通过分发库中转,每个过程都会产生大量的磁盘IO和网络消耗;

clip_image004

而AlwaysON是点到点的数据同步,日志从主副本直接发送到辅助副本,中间不需要中转,传输过程简单高效。

 

AlwaysOn的可用性模式

上文在介绍AlwaysON同步原理时,我们考虑地比较简单,只考虑了日志的同步情况。

如果要结合事务来整体考虑,AlwaysON的同步——更准确地说是可用模式,应该分为异步提交模式和同步提交模式。

可用性模式是AlwaysON中每个可用性副本的一个属性,它决定了主副本在提交事务之前是否需要等待某个辅助副本将事务日志记录固化到磁盘,如果需要等待,则该AlwaysON的可用模式为“同步提交模式,反之,则是“异步提交模式”。

异步提交模式

使用此可用性模式的可用性副本称为"异步提交副本"。

当辅助副本处于异步提交模式下或者尽管辅助副本在同步提交模式下,但此时主副本在异步提交模式时,主副本无须确认该辅助副本是否已经完成日志固化,就可以提交事务。因此,主数据库事务提交不会受到辅助数据库的影响而产生等待。但是,辅助数据库的更新可能会滞后于主数据库,如果发生故障转移,可能会导致某些数据丢失。因此这种可用模式适合于可用性副本的分布距离较远的情况。

同步提交模式

使用此可用性模式的可用性副本称为"同步提交副本"。同步提交模式要求主副本和辅助副本必须设置成同步提交副本。

在同步提交模式中,主副本必须确认辅助副本已经完成日志固化才可以提交事务(不需要等待辅助副本完成日志重做),这样就保证两边的数据始终是同步的。但是这种保障的代价是主数据库上的事务提交会有滞后时间。可以说,同步提交模式相对于性能而言更强调高可用性。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
poj 1751 Highways
点击打开链接poj 1751 思路:最小生成树+prime 分析:只要按照prime的思路求出所有的边,然后输出的时候判断是否是已经建好的即可。
552 0
always on 集群
准备工作 1、  四台已安装windows server 2008 r2 系统的虚拟机,配置如下: CPU : 1核 MEMORY : 2GB DISK : 40GB(未分区) NetAdapter : 2块 2、  网卡设置: 本地连接:外网IP(由于虚拟机本身处于内网网段,192.168.1.2-192.168.1.255,在此我们把当前内网视为外网公开的IP)。
1134 0
《利用Python进行数据分析·第2版》第5章 pandas入门
第1章 准备工作第2章 Python语法基础,IPython和Jupyter第3章 Python的数据结构、函数和文件第4章 NumPy基础:数组和矢量计算 第5章 pandas入门第6章 数据加载、存储与文件格式第7章 数据清洗和准备第8章 数据规整:聚合、合并和重塑第9章 绘图和可视化第10章 数据聚合与分组运算第11章 时间序列第12章 pandas高级应用第13章 Python建模库介绍第14章 数据分析案例附录A NumPy高级应用附录B 更多关于IPython的内容(完) pandas是本书后续内容的首选库。
964 0
协同过滤(ALS)的原理及Python实现
提到ALS相信大家应该都不会觉得陌生(不陌生你点进来干嘛[捂脸]),它是协同过滤的一种,并被集成到Spark的Mllib库中。本文就ALS的基本原理进行讲解,并手把手、肩并肩地带您实现这一算法。 原理篇 我们用人话而不是大段的数学公式来讲讲ALS是怎么一回事。
2800 0
java 根据两个位置的经纬度,来计算两地的距离 经纬度处理
java 根据两个位置的经纬度,来计算两地的距离 经纬度处理
0 0
JWT的原理和使用
在用户注册或登录后,我们想记录用户的登录状态,或者为用户创建身份认证的凭证。我们不再使用Session认证机制,而使用Json Web Token认证机制。Json web token (JWT), 是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准((RFC 7519).该token被设计为紧凑且安全的,特别适用于分布式站点的单点登录(SSO)场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息,以便于从资源服务器获取资源,也可以增加一些额外的其它业务逻辑所必须的声明信息,该token也可直接被用于认证,也可被加密。
0 0
+关注
dbaer
擅长SQL Server、MySQL、云架构部署等
文章
问答
文章排行榜
最热
最新
相关电子书
更多
事务、全局索引、透明分布式
立即下载
高可用数据库的搭建与备份恢复策略验证实战
立即下载
运用新技术解决有状态应用的冷热迁移挑战 迁移策略+新容器运行时
立即下载