复制(1)SQLServer复制简介

来源:IT165收集  发布日期:2014-04-01 19:59:28

前言:

  SQLServer的复制技术最少从SQLServer2000时代已经出现,当初是为了分布式计算,不是为了高可用。但是到了今天,复制也成为了一种高可用技术,并且被广泛使用。很多问题都通过复制得以解决。

复制组件:

  复制说白了就是一种发布/订阅模式,但是这种模式并不容易理解。下面介绍一下复制技术的一些概念。提醒一下,这里的复制在英文中不是COPY,而是Replication。它包含三个组件:发布者、分发者和订阅者。三者缺一不可,并且均以在发布和订阅中定义的项目为操作单元。

  • 项目(Article):是用于复制中的可配置的最小操作单元,它可以是一个单独的SQL Server对象,也可以是一个对象中的一个自己。这些对象通常是表、视图、存储过程等。还可以是表中的部分行或者列的集合。在非严格环境下,可以把多个对象定义为一个项目来发布和订阅。
  • 发布(Publication):注意这里是名词,是一组项目的逻辑集合,每个发布可以包含一个或多个项目。发布中的配置项会影响它包含的所有项目,通过这种方式,可以减少管理对象所带来的影响。其中最重要的配置项就是复制类型。
  • 发布者(Publisher):运行发布的实例,发布者监控所有项目的变更,并且告知这些信息给分发者。
  • 分发者(Distributor):是一个跟踪所有订阅和发布活动变更的实例,在复制过程中充当中间人,绝大部分的变更会存储在一个分发数据库(存在于系统数据库目录下,库名为distribution),可以是单独的实例,也可以运行在订阅服务器或者发布服务器上,但是通常会运行在发布者所在的机器上。
  • 订阅者(Subscriber):同样是一个实例,用于通过分发者,接收所有发布者传过来的信息。
  • 订阅(Subscription):与发布配对,用于决定哪个服务器(订阅者)接收从发布中传输过来的信息。每个订阅都会创建一个发布者和订阅者之间的连接。复制技术存在两种订阅方式,推送(push )和提取(pull)。对于推送订阅,分发者直接在订阅数据库更新数据,对于提取订阅,订阅者会周期性询问分发者是否有新变更可用,如果有,就会自行更新自己的数据。

    图中上半部分是分发者和发布者均在一个实例上的情况,下半部分是三者都分开实例。

    复制类型:

      粗略来说,SQLServer有三种主要的复制类型:快照复制、合并复制和事务复制。这里先简单介绍,后续会详细并演示每一种类型。

    快照复制:

      每次运行时,会创建被发布对象的完整副本及其数据,并使用SQLServer的BCP工具把每个表的内容写入到快照文件夹中。这类快照文件夹是由分发者创建的共享文件夹。复制过程中的所有参与者都必须能够访问快照文件夹。

      每次快照复制开始运行后,分发者会从发布中抓取已配置的发布项的当前快照,并传送给订阅者,然后应用到订阅数据库中,当应用新快照时,订阅数据库上的项目会被删除并按新快照的内容重建,这个过程只会在每次快照复制启动时执行一次,发布和订阅端之间没有持续的数据流,并且这个过程是高带宽和存储开销的操作。

      默认情况下,其他类型的复制会在初始化时通过分发者,通过快照来同步所有的订阅项。这种类型的复制最适合用于相对静态的数据环境。

    事务复制:

      基于事务的一种复制类型,每个在发布项中的已提交的事务都会被扫描,并通过分发者传输到订阅端。这个扫描操作是由日志读取器代理(log reader agent)通过读取发布数据库中的事务日志完成。如果已发布项中有修改,会把修改记录在分发者的分发数据库中。然后从分发数据库上,按照当前的订阅类型,应用到订阅者中。

      事务复制可以接近实时同步,并只占用少量的发布者空间。同时,这种类型的复制可以配置成数据双向移动,但是事务复制的最初设计是仅仅用于单向的。

    合并复制:

      最初的设计是用于允许修改发生在发布者和订阅者上。同时,合并复制在订阅者不能持续连到发布者,可能隔天连一次这种情景下也很有用。这种情景下,可以每天晚上同步,但是当一个数据被同时来自于不同发布者的数据所修改时,就会产生冲突。可以通过一些配置来解决。

Tag标签: 简介  
  • 专题推荐

About IT165 - 广告服务 - 隐私声明 - 版权申明 - 免责条款 - 网站地图 - 网友投稿 - 联系方式
本站内容来自于互联网,仅供用于网络技术学习,学习中请遵循相关法律法规