复制概述及工作机制

分发服务器是发布服务器与订阅服务器之间的桥梁，起着存储区的作用，负责复制与一个或多个发布服务器相关联的特定数据。每个发布服务器都与分发服务器上的单个数据库（称作分发数据库）相关联。分发数据库从发布服务器获得要发布的数据后将存储复制状态数据和有关发布的元数据，并且在某些情况下为从发布服务器向订阅服务器移动的数据起着排队的作用。在大多数情况下，一个数据库服务器实例充当发布服务器和分发服务器两个角色。当发布服务器和分发服务器在同一个数据库实例中时，称为“本地分发服务器”。当发布服务器和分发服务器按各自的数据库服务器实例配置时，把分发服务器称为“远程分发服务器”。

5. 订阅服务器 ( Subscribers )

订阅服务器好比是杂志的订阅者。订阅服务器是从分发服务器接受复制数据的数据库实例。订阅服务器可接受来自多个发布服务器的数据。根据所选的复制类型，如果是合并复制模式，订阅服务器还可以将数据更改传递回发布服务器，或者将数据重新发布到其他订阅服务器。

复制的类型

SQL Server 三种基本复制类型

快照复制
事务复制
合并复制
主要为可能存在数据冲突的移动应用程序或分布服务器应用程序设计的。常见应用场景包括：与移动用户交换数据，POS(消费者销售点)应用程序，以及集成来自多个站点的数据。

如何选择适合的复制类型

被复制数据的类型和数量
是否复制在订阅服务器上进行更新的数据
复制中所涉及的计算机数量和位置
复制中所涉及的计算机是客户端（工作站、便携式电脑或手持设备）还是服务器

快照复制 (Snapshot Replication)

原理

快照代理将数据库的某个瞬时状态生成一个快照，并将此快照发送到订阅服务器。而不监视对数据的更新。在数据同步时，系统将重新生成完整的快照并将其发送到订阅服务器。

快照复制的缺点

快照文件通常较大，因此通过快照复制同步数据，可能会花费较长时间。
快照是静态的，因此快照复制不会将数据变化自动传递给订阅服务器
快照复制每次同步的是整个订阅的内容，若要复制的数据集非常大表，那么势必每次同步都需要生成很大的快照文件并将这些快照文件逐一导入到订阅数据库中，因此同步时间和同步间隔都会很长。
快照复制中服务器之间并不具有很高的一致性，快照复制是按照作业计划或人工操作进行数据同步的，在数据同步之前，发布服务器上的数据与订阅服务器上的数据可能存在很大的差别。

快照复制的工作机制

从上图可以看出，当快照复制运行时，在发布服务器上快照代理执行了以下操作：

在分发服务器到发布服务器之间建立连接，然后根据需要在已发布表上使用锁
- 对于合并发布，快照代理不使用任何锁
- 对于事务发布，快照代理只在快照生成的初始阶段使用锁
- 对于快照发布，整个快照生成过程中都使用锁
快照复制将每个项目的表架构副本写入一个.sch文件。若发布其他数据库对象（如索引、约束、存储过程、视图、用户定义函数等），则生成其他脚本文件。
从发布服务器上已发布的表中复制数据，然后将数据写入快照文件夹。快照哦数据文件将以一组 BCP 导出文件的形式生成
对于快照发布和事务发布，快照代理将向分发数据库的 MSrepl_commands 表和 MSrepl_transactions 表中添加行。
- MSrepl_commands
  表中包含的是命令,这些命令指示.sch和.bcp文件、其他快照文件，以及对快照前或快照后脚本的引用位置。
- MSrepl_transactions
  表中包含的是与同步订阅服务器相关的命令
释放已发布表上的所有锁
快照文件生成后，接下来由分发代理执行分发工作
- 与分发服务器建立连接
- 检查分发服务器上分发数据库中的 MSrepl_commands 和 MSrepl_transactions表。代理从第一个表中读取快照文件的位置，并从这两个表中读取订阅服务器同步命令。
- 复制快照中的数据，将架构和命令应用于订阅数据库

快照复制的适用场景

在一段时间内允许订阅服务器使用相对已过时的数据副本并且需要复制的整体数据量较小
数据库在短期内出现了大量更改并且需要复制的整体数据量较小
发布的表较小，且可接受一定的同步滞后时间，也可选择快照复制来传递表上的数据更改。
很少更改数据

快照复制是消耗 SQL Server 额外维护检查成本最低的复制类型

事务复制 ( Transactional Replication )

原理

事务复制具有很高的一致性，当发布服务器中的数据发生更改时，订阅服务器上的数据也会很快得到更改。事务复制通常从发布数据库对象和数据的快照开始。接着在发布服务器上所做的数据更改和架构修改通常在修改发生时（几乎实时）便传递给订阅服务器。数据更改将按照其在发布服务器上发生的顺序和事务边界，应用于订阅服务器，因此，在发布内部可以保证事务的一致性。

事务复制的工作流程

SQL 通过日志读取代理和分发代理程序，将发布服务器上所做的数据更改和架构修改几乎实时地传递给订阅服务器。所有的数据更改都会以事务为单位，按照其在发布服务器上发生的顺序，同步到订阅服务器上。如此，订阅服务器就获得了与发布服务器相同的数据副本。参与事务复制的表必须提前建立主键或者唯一约束。

所有的数据或架构更改必须在发布服务器中进行，订阅服务器应作只读处理，不应发生任何更改，因为这里的更改不会传播回发布服务器。但若需要在订阅服务器上进行数据更改并且希望这些更改能回传到发布服务器上，有两个选择：

可通过使用事务复制的“立即更新”或“排队更新”选项来启动所谓的“可更新订阅的事务复制”。使用排队更新选项时，SQL Server 在事务复制中引入第三种代理程序-队列读取器代理( Queue Reader Agent )。队列读取器代理运行于分发服务器，它用于将订阅服务器上所做更改传递回发布服务器。“可更新订阅的事务复制”可能会发生订阅服务器和发布服务器之间的数据更新冲突
在SQL Server 2005 中加入了一种新的事务复制类型，叫作“对等事务复制”。在对等事务复制的拓扑结构中，可以有多个数据库实例彼此互为订阅服务器和发布服务器，并且对于彼此间的更新冲突，对等事务复制也定义了冲突解决的机制

事务复制的工作过程

在进行新的事务复制之前需要初始化数据，新的事务复制订阅服务器上必须包含一些表，这些表需要与发布服务器上的表具有相同的架构和数据，这样才能从发布服务器上接受增量更改。初始数据集通常是由快照代理创建并由分发代理分发和应用的快照。初始数据集还可以通过备份或其他方式提供
日志读取器代理在分发服务器上运行，通常连续运行，但也可按照用户制订的计划运行。执行日志读取器代理时，代理首先读取发布事务日志，并标识任何 INSERT、UPDATE，以及DELETE语句，或者对已标记为要复制的事务进行其他数据修改。然后，该代理将这些事务批量复制到分发服务器上的分发数据库中。日志读取器代理使用内部存储过程 sp_replcmds从日志中获取标记为要复制的下一个命令集。这样，分发数据库就成为一个存储转发队列，从该队列中将更改发送到订阅服务器上。
当整批事务都成功写入分发数据库之后，发布数据库将提交这批事务。在每一批命令都提交到分发服务器后，日志读取器代理将调用sp_repldone以标记最终完成复制的位置。最后，代理在事务日志中标记可以清除的行。仍在等待复制的行不会被清除。事务命令在传播到所有订阅服务器或达到最大分发保持器之前，一直存储在分发数据库中。订阅服务器按事务在发布服务器上应用的相同顺序接收胡事务。

对等事务复制的拓扑结构图

事务复制的使用场景

事务复制通常用于需要高吞吐量的服务器到服务器方案（包括提高伸缩性和可用性、数据仓库和报告、集成多个站点的数据、集成异类数据，以及减轻批处理的负荷）

需要较短的同步时间，数据更改要较快地从发布服务器上传给订阅服务器
订阅服务器上的应用环境需要追踪的中间状态。例如，如果某一行在发布服务器上更改了五次，在订阅服务器上要针对每一次更改都触发相应的操作（例如激活五次触发器）
发布服务器有大量的插入、更新和删除动作
发布服务器或订阅服务器其中之一不是 SQL Server 数据库（例如 Oracle）

说明
事务复制中的订阅服务器应视为只读，即在订阅服务器上对数据进行更改将不会传播回发布服务器。但事务复制确实提供了允许在订阅服务器上进行更新的选项。

合并复制 ( Transactional Replication )

不管是快照复制还是事务复制，只能在发布服务器上进行数据修改。而合并复制能允许用户同时修改订阅服务器和发布服务器上的数据，并把这些修改“合并”成一个统一的结果。由于更新是在多个服务器上进行的，同一数据可能在发布服务器和多个订阅服务器上都进行了更新。因此在合并更新时可能会产生冲突。为此合并复制提供了多种处理冲突的方法

原理

合并复制从发布数据库对象和数据的快照开始，并且用触发器跟踪在发布服务器和订阅服务器上所做的后续数据更改和架构修改。合并复制情况下允许对发布服务器和定义服务器中的数据进行更改，订阅服务器并不一直与发布服务器保持连接，只有订阅服务器在连接到网络时才与发布服务器进行同步，系统将自动合并自上次同步以来发布服务器和订阅服务器之间发生更改的所有行。

合并复制的工作机制

合并复制适用于下列情况

合并复制通常用于服务器到客户端的环境中，特别是移动数据库与服务器数据库之间

多个订阅服务器可能会在不同时间更新同一数据，并将其更改传播到发布服务器和其他订阅服务器
订阅服务器需要接受数据，脱机更改数据，并在以后与发布服务器和其他订阅服务器同步更改
多个服务器同时更改一个数据，可能会引发冲突。用户需要具有检测和解决冲突的功能
每个订阅服务器都需要不同的数据分区
应用程序需要最终的数据更改结果，而不是访问中间数据状态。例如，如果在订阅服务器与发布服务器进行同步之前，订阅服务器上的行更改了五次，则该行在发布服务器上仅更改一次来反映最终数据更改（即第五次更改的值）
订阅服务器是移动客户端，需要通过 web service 从发布服务器同步数据

三种复制类型，无论是哪种，目的都是把数据从发布服务器同步到订阅服务器。但是每种类型的复制跟踪数据更改的方式都不同。

快照复制不会跟踪快照生成后任何的数据更改，因此要同步数据变更就需要每次都把新的快照应用到订阅服务器上，完全覆盖现有数据。
事务复制通过 SQL Server 的事务日志跟踪更改，以事务为单位将更改发送到订阅服务器。
合并复制则通过触发器和系统表来跟踪数据和架构更改。

一般情况下，数据更改都发生在发布服务器上，订阅服务器不应有数据更改；但是合并复制、对等事务复制以及可更新订阅的事务复制允许在订阅服务器上进行更改，并使这些更改流向发布服务器。

复制代理

复制代理指的是执行与跟踪和分发数据关联的任务的 SQL Server 代理的独立程序。复制代理在 SQL Server 2012 中作为 SQL Server 代理安排的作业运行，必须运行 SQL Server 代理，这些作业才能运行。

复制代理类型

快照代理

适用范围
在各种类型的复制中都适用
功能
主要负责准备已发布表的架构和初始数据文件以及其他对象、存储快照文件并记录分发数据库中的同步信息

日志读取器代理

适用范围
仅在事务复制中使用
功能
负责将发布服务器上的事务日志中标记为复制的事务移至分发数据库中。使用事务复制发布的每个数据库都有自己的日志读取器代理。该代理运行于分发服务器上并与发布服务器连接。

分发代理

适用范围
在快照复制和事务性复制中使用
功能
分发代理负责将初始快照应用于订阅服务器，并将分发数据库中保存的事务移至订阅服务器。
分发代理运行在哪种服务器上
- 推送订阅中，分发代理运行于分发服务器上
- 请求订阅中，分发代理可运行于订阅服务器上

合并代理

适用范围
合并复制
功能
合并代理负责将初始快照应用于订阅服务器上，并移动和协调所发生的增量数据更改。在每个合并订阅上都有自己的合并代理，该代理同时连接到发布服务器和订阅服务器并对数据进行更新。
分发代理运行在哪种服务器上
默认情况下，合并代理将订阅服务器上的数据更改上传到发布服务器，然后将发布服务器你上的更改下载到订阅服务器
- 推送订阅中，分发代理运行于分发服务器上
- 请求订阅中，分发代理可运行于订阅服务器上

队列读取器代理

适用范围
包含排队更新选项的事务复制中使用
功能
运行于分发服务器上，负责将订阅服务器上所做的更改移回至发布服务器。与分发代理和合并代理不同，只有一个队列读取器代理的实例为给定分发数据库的所有发布服务器和发布提供服务。

订阅 ( Subscription )

订阅的定义

订阅是对发布中的数据和数据库对象副本的请求。订阅定义将接受哪个发布，以及接受的时间和位置。

订阅的类型

推送订阅

发布服务器或分发服务器（取决于所使用的复制类型）主动的将数据更改发送到订阅服务器，而无需订阅服务器发出请求。好比订阅杂志的用户，杂志会经发行商寄到你家来。你有三种选择来决定何时把发布推送到订阅服务器上：按需、连续、按照计划推送。

推送订阅使用场景

数据将连续同步或按照经常重复执行的计划同步
发布要求数据近似实时地移动
分发服务器上较高的处理器开销不会影响性能
通常与快照和事务复制一起使用

请求订阅

订阅服务器主动请求去获得发布服务器上所做的修改。好比订阅者主动到发行商的销售网点去买杂志。此种模式下，接受发布的时间是由订阅服务器来确定的。

请求订阅使用场景

数据通常按需或按计划同步，而非连续同步
发布具有大量订阅服务器，并且在分发服务器上运行所有代理会消耗大量资源
订阅服务器是自主的、断开连接的和移动的。订阅服务器将确定连接和同步更改的时间
通常与合并复制一起使用

灾难恢复和复制

发布/订阅服务器选择

当使用事务复制来作为灾难恢复方案时，应当把主服务器选为发布服务器，把备用服务器选为订阅服务器。

订阅模式

建议使用推送模式，并且设置为“连续发送”，这样分发服务器会立刻将接受到的分布发送到订阅服务器上。一旦发布数据库出了问题，订阅数据库上还有副本数据可用。

复制的订阅服务器能起到的作用

复制中的订阅服务器是可以访问的，因此可将一些只读的应用，如报表系统运行在订阅服务器上，如此可分流分布数据库的负载。但若想将数据库用于灾难恢复，则应禁止任何人或应用更新订阅服务器上的数据

复制中发布&订阅服务器之间同步滞后时间

事务复制的同步滞后时间会小于日志传送，但是无法像数据库镜像技术那样实现完全同步和数据零损失。

复制于服务器的负载

事务复制带来的额外负载一般会高于日志传送。

复制使用最佳方法

事务复制最适合用于数据库对象级别的复制，例如仅复制一个或几个表，而不是复制整个数据库。其可只同步几个表，甚至是表中的部分数据，这是数据库镜像和事务日志传送都无法达到的功能。而将事务复制作为灾难恢复方案只适用于同步较小量数据的情况。

复制作为灾难恢复方案存在以下问题

复制是以表和其他数据库对象为单位的数据同步功能，使用系统表来维护所有表的变更，因此需要大量的额外开销（如触发器等）来监控数据的变更并维护系统表。若要将库中的所有内容都发布出去，则这部分开销会变得非常大，一般不建议这么做。
复制在主服务器（发布服务器）和备用服务器（订阅服务器）之间，还使用一个额外的角色分发服务器来做中转。这额外增加了同步的开销并且使滞后的时间更长。复制需要使用不同的代理程序来传送数据，这些代理程序都是独立于 SQL Server 进程以外的可执行程序，这些程序和 SQL Server 之间的进程交互也增加了复制带来的开销
复制需要将事务日志文件的内容解析成二进制格式的命令写入系统表中，然后再将这些命令发送到订阅端的数据库上去执行。这些造成了两次数据传输过程。当变更量非常大时，这样的过程会造成较长时间的延迟
复制对表的定义有要求，不是所有的表都能做复制。它需要在所有参与复制的表上创建主键或者增加 rowguid 的列。因此实施复制需要在数据库设计阶段就要考虑。对已经上线的系统中使用复制功能，可能需要一些二次开发的工作。
复制非常依赖分发数据库来作为数据的中转。一旦分发数据库出了问题而又没有启用 sync with backup 功能，保存在分发数据库中那些还没发送出去的更新会全部丢失，即分发数据库的存在增加了整个灾备方案失败和数据损失的可能性。此外，一旦分发数据库出问题，整个复制也需要重建，重建意味着重新在订阅服务器上做初始化，费时费力
与数据库镜像和日志传送不同，订阅数据库本身不限制写操作。即从系统层面上复制无法杜绝在订阅数据库发生更新操作，而只能靠人为的管理和安全措施。因此，订阅服务器上数据的可靠性是存在一定风险的。

参考资料

<<SQL Server 2012实施与管理实战指南>>

SQL Server复制入门(一)----复制简介

question

复制是什么，它能做什么事情
复制的使用场景
复制的优劣势
sql server 和 mysql 可以通过复制来
复制有哪些类型