复制采用独特的“发布-订阅”模式,将
SQL Server
中的数据分发到各个服务器或客户端上,然后再数据库间进行同步,以维持一致性。
复制的使用场景
复制注重的是数据同步,而非灾难恢复。灵活的数据同步功能能够在多个数据源之间进行数据的同步与合并,移动设备可以通过复制功能从 SQL Server
上同步到它所需要的数据。若将其作为灾难恢复的解决方案,可能会使用较多的代价和资源,但效果却很一般。
使用复制的原因可分为如下几类:
- 负载均衡
通过将数据复制到其他数据库服务器来减少当前服务器的负载,比如说最典型的应用就是分发数据来分OLTP
和OLAP
环境 - 分区
将经常使用的数据和历史数据隔离,将历史数据复制到其他数据库中 - 授权
将一部分数据提供给需要使用这些数据的人 - 数据合并
每个区域都有其各自的数据,将其数据进行合并。比如一个大公司,每个地区都有其各自的销售数据,总部需要汇总这些数据。 - 故障转移
复制所有数据,以便故障时进行转移
复制的基本概念
术语
1. 项目( Article )
项目指的是 SQL Server
数据库中的对象,如:表、视图、存储过程、自定义函数或其他对象。如果项目是一个表,可通过添加筛选条件来过滤掉表中的某些行和列,类似于对文章进行了编辑工作,确保订阅者只收到过滤后的内容。
2. 发布( Publication )
发布是一个或多个项目的集合,一次发布可以包含不同类型的项目。文章比作成项目,杂志比作成发布。一个杂志包含多篇文章,一个发布包含多个项目。发布是复制的基本单位。通常将逻辑上相关联的数据库对象(比如外键和被外键关联的两个表)组合在一起形成一个发布,如此可确保被复制的内容在逻辑上保持一致。
3. 发布服务器( Publisher )
发布服务器好比是杂志的出版商,其生产一种或多种杂志提供给订阅者。在复制的结构中,发布服务器是一个数据库实例,上面配了一个或多个发布,每个发布定义一组要复制的具有逻辑关系的对象和数据。这些发布中的对象和数据通过复制发送给其他的服务器或客户端。
4. 分发服务器 ( Distributer )
分发服务器也是一个数据库实例,它服务于一个或多个发布服务器。每个发布服务器都对应分发服务器中的一个数据库,这种关联的数据库被称为分发数据库。
分发数据库的作用
分发服务器是发布服务器与订阅服务器之间的桥梁,起着存储区的作用,负责复制与一个或多个发布服务器相关联的特定数据。每个发布服务器都与分发服务器上的单个数据库(称作分发数据库)相关联。分发数据库从发布服务器获得要发布的数据后将存储复制状态数据和有关发布的元数据,并且在某些情况下为从发布服务器向订阅服务器移动的数据起着排队的作用。在大多数情况下,一个数据库服务器实例充当发布服务器和分发服务器两个角色。当发布服务器和分发服务器在同一个数据库实例中时,称为“本地分发服务器”。当发布服务器和分发服务器按各自的数据库服务器实例配置时,把分发服务器称为“远程分发服务器”。
5. 订阅服务器 ( Subscribers )
订阅服务器好比是杂志的订阅者。订阅服务器是从分发服务器接受复制数据的数据库实例。订阅服务器可接受来自多个发布服务器的数据。根据所选的复制类型,如果是合并复制模式,订阅服务器还可以将数据更改传递回发布服务器,或者将数据重新发布到其他订阅服务器。
复制的类型
SQL Server
三种基本复制类型
- 快照复制
- 事务复制
- 合并复制
主要为可能存在数据冲突的移动应用程序或分布服务器应用程序设计的。常见应用场景包括:与移动用户交换数据,POS(消费者销售点)应用程序,以及集成来自多个站点的数据。
如何选择适合的复制类型
- 被复制数据的类型和数量
- 是否复制在订阅服务器上进行更新的数据
- 复制中所涉及的计算机数量和位置
- 复制中所涉及的计算机是客户端(工作站、便携式电脑或手持设备)还是服务器
快照复制 (Snapshot Replication)
原理
快照代理将数据库的某个瞬时状态生成一个快照,并将此快照发送到订阅服务器。而不监视对数据的更新。在数据同步时,系统将重新生成完整的快照并将其发送到订阅服务器。
快照复制的缺点
- 快照文件通常较大,因此通过快照复制同步数据,可能会花费较长时间。
- 快照是静态的,因此快照复制不会将数据变化自动传递给订阅服务器
- 快照复制每次同步的是整个订阅的内容,若要复制的数据集非常大表,那么势必每次同步都需要生成很大的快照文件并将这些快照文件逐一导入到订阅数据库中,因此同步时间和同步间隔都会很长。
- 快照复制中服务器之间并不具有很高的一致性,快照复制是按照作业计划或人工操作进行数据同步的,在数据同步之前,发布服务器上的数据与订阅服务器上的数据可能存在很大的差别。
快照复制的工作机制
从上图可以看出,当快照复制运行时&#x