设为首页 收藏本站
查看: 1275|回复: 0

[经验分享] SQL Server复制入门(二)----复制的几种模式

[复制链接]

尚未签到

发表于 2015-6-27 18:22:03 | 显示全部楼层 |阅读模式
简介
    本系列文章的上一篇对复制是什么做了一个概述。本篇文章根据发布服务器,分发服务器和订阅服务器的组织方式和复制类型来讲述常用复制的几种模式。
  
  模式的选择
    选择复制的模式取决于多个方面。首先需要考虑具体的业务需求,在此之后还需要考虑硬件和网络的限制。对于业务需求来说考虑的角度可以分为两个部分:自治和延时。自治是指”数据不被影响的程度”,比如说一个业务场景:公司的总部在北京,发布服务器和分发服务器全在总部,各个地区的分部有订阅服务器,使用快照复制来接收推送订阅总部每个月一次的公司员工通讯录。在这个业务场景中,订阅服务器仅仅是接收发布服务器发布的通讯录信息,对于这些信息的修改是不会回传给总部服务器的,这个业务场景的自治程度就是非常低的。而对于延时来说,就是”在发布服务器上的数据修改应用到订阅服务器上的时间”,比如还是上面那个例子,每次订阅服务器的订阅周期是一个月,在此期间总部的通讯录可能经过了多次修改,但一个月以后才会同步到订阅服务器,那么这种场景的延时是非常高的。
  其次就是硬件和网络的限制,比如将发布服务器和分发服务器设置在一台服务器上,在现有的情况下CPU是否能够承受这些负担?或是使用快照复制,发布服务器和订阅服务器之间的网络宽带是否能够承受在一定发布周期内的数据量传输?
  在简单了解了模式选择的标准后,下面我们来看常用的几种复制模式。
  
  以发布服务器为中心的复制模式
    这种模式多个订阅服务器以一个发布服务器为中心进行订阅,如图1所示。
DSC0000.png
  图1.多个订阅服务器以发布服务器为中心的模式
  
  这种模式也是复制模式中最简单的模式,这种模式可以使用快照发布和事务发布。不难看出,这种情景的自治性是比较低的,因此这种模式适用于以下几种业务场景。
  
       
  •     订阅服务器用于报表生成.   
  •     发布服务器用来发布类似前文所说的员工通讯录,产品资料等主(Master)信息   
  •     使用事务发布,使得订阅服务器承担部分负载   
  •     在发布服务器Down了以后,作为紧急备用服务器
    
  当然,这种模式的缺陷也是显而易见的。
  
       
  •      首先是发布服务器和分发服务器在同一台服务器上对CPU和内存的消耗服务器硬件是否能够承受是一个问题   
  •      在OLTP环境中如果每天要修改的数据量过大,比如超过10%,那么需要传送到的订阅服务器的数据量过大也是不得不考虑的一个问题
    
  以发布服务器和分发服务器为中心的复制模式
    这种模式其实和上一种模式区别不大,只是分离了发布服务器和分发服务器,如图2所示。
DSC0001.png
  图2.以发布服务器和分发服务器为中心的复制模式
  
  这种模式是将分发任务对CPU,内存和网络带来的负载转移到另一台分发服务器了。从而减轻发布服务器的压力和支持更多的订阅服务器。此外,我们知道一个分发服务器支持多个发布服务器的,因此也可以多个发布服务器使用一个分发服务器。
  这种模式还有一个好处是可以将分发服务器放到DMZ区域和订阅服务器连接以避免发布服务器直接暴漏在外网。
  当然了,这种模式最重要的一点是发布服务器和分发服务器一定要有可靠的网络连接,这种模式和图1提到的第一种模式适用的业务场景基本一致。
  
  发布-订阅的复制模式
    这种模式使得发布服务器也是订阅服务器,如图3所示。
DSC0002.png
  图3.发布-订阅复制模式
  
  这种模式适用于服务器A和服务器B的网络非常昂贵但服务器B和各个订阅服务器的网络成本很低的情况。比如,公司的总部在北京,服务器A在北京,服务器B是上海分公司的,各个订阅服务器通过局域网和服务器B进行连接。在这个例子中,服务器A和服务器B通过VPN进行连接,这个费用是相当昂贵的,而服务器B和各个订阅服务器通过局域网连接的成本可以忽略。
  
  以订阅服务器为中心的复制模式
    这种模式以订阅服务器为中心,如图4所示。
DSC0003.png
  图4.以订阅服务器为中心复制模式
  
  这种模式适用的场景比如:各个区域将各自的业务数据汇总到总部这种类型的业务场景。
  
  多个发布服务器和多个订阅服务器的复制模式
    这种模式适用于数据对等的环境,一个简化的版本如图5所示。
DSC0004.png
  图5.多个发布服务器和多个订阅服务器
  
  这种模式非常适合业务数据对等的环境,比如说这类业务场景,一个销售公司在同一个城市有3个分店,这三个分店之间是对等的,它们之间通过复制来同步库存。使得每个店都可以了解其它分店的库存情况。这类业务场景适合使用多个发布服务器和多个订阅服务器的复制模式。
  
  具有可更新订阅的事务发布模式
    这种模式非常类似图1中所说的模式,但这种模式允许订阅服务器更新数据。如图6所示。
DSC0005.png
  图6.具有可更新订阅事务的发布模式
  
  在这种模式下,比如订阅服务器B更新了数据,这个数据会传送回发布服务器,如果发布服务器接收了这个数据,那么这个数据会同时同步到其它订阅服务器。
  
  合并发布模式
    合并发布模式适用于所有服务器共享一部分数据的场景,如图7所示。
DSC0006.png
  图7.合并发布模式
  
  这种模式下,每个服务器并不是互相订阅,而是互相共享。这种模式同样适用于图5所述的业务模式。
  
  总结
    本文讲述了复制的几种模式以及它们的所适用的一些场景,很多更复杂的复制模式大多都是对以上几种模式的组合或者拓展。理解上述简单的复制模式是理解复杂复制模式的基础。

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-81049-1-1.html 上篇帖子: 下载SQL Server 2008 R2 Express(数据库大小限制提高到10G) 下篇帖子: 初探SQL Server CLR 集成
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表