技术开发 频道

SQL Server中的高可用性 之 复制篇

  【IT168 技术】随着数据量的增长,以及对RTO和RPO要求的严格,单实例已经无法满足HA/DR方面的要求,因此需要做多实例的高可用性。本文着重对SQL Server的复制进行阐述。

  复制?

  复制起初并不是用于作为高可用性功能而设计的,实际上复制的概念就像其名称一样,用于复制数据。比如将某个库中的数据“复制”到另一个库,到另一个实例中,由OLTP复制到OLAP环境中,由某数据中心复制到位于地球另一侧的另外一个数据中心中。因此,由于复制所提供的功能,复制可用被用来剥离负载,用于做数据冗余,直至把复制用于作为高可用性拓扑中的一个环节。(切记,复制的功能可以被用做高可用性,而不是复制是高可用性功能。)

  不同于其它SQL Server可以被用作高可用性的特性,复制可以做的非常灵活。您可以复制某些列,过滤某些行,复制表中的部分数据。复制是基于数据库对象的,而不像日志传送、镜像、集群、AlawysOn等需要以库和实例作为基本对象,此外更新的订阅还允许订阅端合并数据,没有任何一种其它的高可用性技术能做到这一点。

  复制的基本概念

  关于复制的基本概念,我在之前已经有一篇文章进行了阐述:http://www.cnblogs.com/CareySon/archive/2012/06/20/IntroductToSQLServerReplicationPart1.html。但这里我还是想再次对基本的概念进行阐述。

  复制的模型参考的杂志发布的模型,由出版社发型杂志,由经销商分发杂志,由订户来消费这些杂志。这个概念看似简单,但可以归结出复制下面一些特点:

  •杂志社是否大,比如说全国发行的杂志需要总代理(单独分发服务器),而一个机关内部发型的文章直接在杂志社(发布服务器和分发服务器在同一台服务器)消费

  •是由订户去经销商自取(订阅服务器去分发服务器请求订阅),还是由经销商送到订户那里(分发服务器推送到订阅服务器)

  •是一次性订阅一本书(快照发布),还是每当有新的文章后就发给订户(事务订阅)

  •杂志会首先到达经销商那里,然后再给订户(数据会在分发服务器那里转存,一定时间过后,则丢弃暂存的数据)

  •经销商保留多久就处理掉过期期刊(分发服务器数据保留时间)

  •出版社不可能仅仅将杂志发布给某个订户看,而是会给多个订户看(一个发布可以允许多个订阅,但要考虑性能问题)

  •从出版社发型文章到经销商再到订户需要一定时间(发布服务器到分发服务器到订阅服务器可能存在5秒10秒15秒等延迟,因此事务复制不能用于做热备,只能用于做冷备和暖备)

  •出版社到经销商到订户中间可能存在杂志丢失的问题,原因可能是由于出版社的问题,快递的问题,经销商的问题,由于环节比较多,不太容易找出问题(复制相对难以调错)

  复制的几种类型

  下面来简单介绍几种复制类型在高可用性中可以作为的角色。

  快照发布

  快照复制本质上就是通过快照目录(共享目录)共享一堆文件(因为需要多个订阅端共享),在早起版本,快照复制仅仅是一个文件,而相对更新的版本,复制会将文件分为多个。快照就是文章某一时间点发布的Article

  是一种创建报表数据库的好方式。

  对于快照复制的简单概念,如图1所示。

SQL Server中的高可用性 之 复制篇
▲图1.快照发布的概念

0
相关文章