SQL Server的“高可用性”与“灾难恢复” 之五 复制

复制（replication）也是SQLServer上一个非常“资深”的功能了。它采用了独特的“发布-订阅”的模式，将SQLServer中的数据分发到各个服务器或客户端上去。

需要说明的是，复制并不是一个为灾难恢复而设计的的功能，它更注重的，是数据同步。用复制来作为灾难恢复的解决方案，往往是使用较多的代价和资源，但只是实现的效果很一般，可以说是性价比不高。大多数情况下，你可以使用日志传送或者数据库镜像，以更低的代价获得类似的甚至更好的效果。复制真正强大的地方是在于它灵活的数据同步功能。比如，它能够在多个数据源之间进行数据的同步与合并，移动设备可以通过复制功能从SQLServer上同步到它所需要的数据等等。

由于复制不是一个“合格”的灾难恢复/高可用技术，本书只对复制做简单的介绍，不会深入地展开。

复制的基本概念

复制使用了出版发行领域的术语来描述它的组件。虽然这些术语无法完全覆盖复制的各种功能，你依旧可以通过这些术语来理解每个组件在复制的拓扑结构所处的位置和作用。

项目（Article）

项目是SQL Server数据库中的对象，它可以是表、视图、存储过程，自定义函数或其他的对象。项目就好比是杂志中的文章，文章可以有不同的类型，包括杂文，传记，新闻等等。如果项目是一个表的话，你可以通过添加筛选条件来过滤掉表中的某些行和列，这就好比是对文章经行了编辑工作，确保了订阅者可以只会收到有限的内容。

发布（Publication）

发布是一个或多个项目的集合， 一次发布可以包含不同类型的项目。发布就好比是一本杂志，其中包含了各种类型的文章。发布是用于复制的基本单位。通常我们将逻辑上相关联的数据库对象（比如外键和被外键关联的两个表）组合在一起形成一个发布，这样可以确保被复制的内容在逻辑上一致。

发布服务器（Publisher）

发布服务器就好比是杂志的出版商，它生产一种或者多种杂志提供给订阅者。在复制的结构中，发布服务器是一个数据库实例，上面配了一个或多个发布。这些发布中的对象和数据通过复制发送给其他的服务器或客户端。

分发服务器（Distributer）

分发服务器也是一个数据库实例，它服务于一个或多个发布服务器。 每个发布服务器都对应分发服务器中的一个数据库，这种关联的数据库被称作分发数据库。分发数据库上保存着复制的状态信息以及每个发布的元数据。从发布服务器发往订阅者的数据会在分发服务器上排队，依次发送出去。分发服务器就好像是发行商，杂志通过它们到达最终的订阅者手中。

订阅（Subscription）

订阅就是将发布从分发服务器发送到订阅服务器上，它定义了“什么时间，从哪里，得到哪些发布”。这就好比一个订阅者要获得他想要的杂志，需要知道什么时候这期的杂志会出版，到哪里可以买到，以及买什么样的杂志。根据数据发送的方式，订阅有两种类型：推送订阅和请求订阅。

推送订阅：发布服务器主动将数据更改发送到订阅服务器，而无需订阅服务器发出请求。 就好比你是订阅杂志的用户，杂志会由发行商寄到你家来。你有三种选择来决定何时把发布推送到订阅服务器上：手动发送，连续发送，按计划时间定期发送。

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

订阅服务器（Subscribers）

订阅服务器就好像是杂志的订阅者。订阅服务器是接收复制数据的数据库实例。 订阅服务器可以接收来自多个发布服务器的数据。根据所选的复制类型，用户可以在订阅服务器上对复制过来的数据做修改，然后将修改发送回发布服务器或者将数据重新发布到其他订阅服务器上。订阅服务器不一定是SQLServer，Oracle 和 IBM DB2 也可以使用推送订阅方式来订阅“快照”和“事务发布”。关于快照和事物发布的概念，稍后我们再讲。

把上面这些组件全部组合起来，就形成了数据如何从发布服务器发送到订阅服务器的全过程。

复制的类型

SQL Server的复制有3种基本类型：快照复制，事务复制以及合并复制。要选择一种适合的复制的类型，你需要考虑多种因素，包括：被复制数据的类型和数量，是否在订阅服务器上更新数据，复制中所涉及的计算机数量和位置，以及这些计算机是客户端（工作站、便携式电脑或手持设备）还是服务器，等等。

快照复制（SnapshotReplication）

快照代理将数据库的某个瞬时状态生成一个快照，并将这个快照发送到订阅服务器。由于快照文件通常都比较大，因此快照复制同步数据的时候会比较长。而且快照是静态的，复制不会将数据变化自动传递给订阅服务器。

在快照复制的过程中，快照是通过文件夹来传送到订阅服务器上的，它没有经过分发服务器。但是快照代理程序会在分发数据库中记录历史信息。

当你的复制环境符合以下条件之一时，选择快照复制会比较合适：

·        数据很少更改数据。

·        用户允许订阅服务器使用相对已过时的数据副本。

·        数据复制量小。

·        数据库在短期内出现了大量更改。

在数据每次更改量很大，但更改次数不多时，快照复制是最合适的。（例如，用户用一句Delete语句，一次删掉了100万条记录。）另外，如果发布的表比较小，且可以接受一定的同步滞后时间，也可以选择快照复制来传递表上的数据更改。

事务复制（TransactionalReplication）

快照复制每次同步的是整个订阅的内容。如果发布包含非常大的表，那么势必每次同步都需要很长时间，同步间隔也会很长。事务复制能够有效地解决快照复制的这些缺陷，实现快速的数据同步。

SQL通过日志读取代理和分发代理程序，将发布服务器上所做的数据更改和架构修改几乎实时地传递给订阅服务器。 所有的数据更改都会以事务为单位，按照其在发布服务器上发生的顺序，应用订阅服务器上。这样，订阅服务器就获得了与发布服务器相同的数据副本。

这种工作流程下的事务复制，所有的数据或架构更改必须在发布服务器中进行；而订阅服务器应作只读处理，不应发生任何更改，因为这里的更改不会传播回发布服务器。但是，如果你真的需要在订阅服务器上进行数据更改并且希望这些更改能回传到发布服务器上，有两个选择：

1.  可以通过使用事务复制的“立即更新”或“排队更新”选项，来启动所谓的“可更新订阅的事务复制”。使用排队更新选项时，SQLServer在事务复制中又引入了第三种代理程序 - 队列读取器代理(Queue Reader Agent)。队列读取器代理运行于分发服务器，它用于将订阅服务器上所做更改传递回发布服务器。“可更新订阅的事务复制”可能会发生订阅服务器和发布服务器之间的更新冲突。

2.  在SQL Server 2005，加入了一种新的事务复制类型，叫做“对等事务复制”。在对等事务复制的拓扑结构中，可以有多个数据库实例彼此互为订阅服务器和发布服务器，并且对于彼此间的更新冲突，对等事务复制也定义了冲突解决的机制。

关于“可更新订阅的事务复制”和“对等事务复制”，碍于篇幅这里就不详细展开了。你可以参考SQLServer的联机丛书来获得更多的信息。

事务复制是一种最常见的复制方法，通常用于服务器到服务器环境中。在以下各种情况下适合采用事务复制：

·        只想把数据更新发送给订阅服务器而不是整个数据集。

·        需要较短的同步时间，数据更改要较快地从发布服务器上传送给订阅服务器。

·        订阅服务器上的应用环境需要追踪数据更改的中间状态。 例如，如果某一行在发布服务器上更改了五次，在订阅服务器上要针对每一次更改都触发相应的操作（例如，激活五次触发器）。

·        发布服务器有大量的插入、更新和删除动作。

·        发布服务器或订阅服务器不是 SQL Server数据库。

 

合并复制（MergeReplication）

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

合并复制的实现机制最为复杂。

合并复制适用于下列情况：

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

到这里，已经介绍了三种基本的复制类型。不管是那种类型，它们最终的目的都是把数据从发布服务器同步到订阅服务器。但是每种类型的复制跟踪数据更改的方式都不同。快照复制不会跟踪快照生成后任何的数据更改，因此要同步数据变更就需要每次都把新的快照应用订阅服务器上，完全覆盖现有数据。事务复制通过SQL Server的 事务日志跟踪更改，复制以事务为单位将更改发送到订阅服务器。而合并复制则通过触发器和系统表来跟踪数据和架构更改。一般情况下，数据更改都发生在发布服务器上，订阅服务器上不应有数据更改；但是合并复制、对等事务复制以及可更新订阅的事物复制允许在订阅服务器上进行更改，并使这些更改流向发布服务器。

 

灾难恢复和复制

 

一个灾难恢复的方案，必定需要一个和主数据库保持同步的备用数据库。因为复制可以创建并维护一份数据副本，所以也可以用来创建备用数据库。在作备份数据库时，一般用户都希望同步的间隔能越短越好，最好是完全同步；并且希望同步给主服务器带来的负担越少越好。基于这个要求，如果要使用复制来作为灾难恢复的方案，事务复制是最佳的选择。

当使用事务复制来作为灾难恢复方案时，应当把主服务器选为发布服务器，把备用服务器选为订阅服务器。关于订阅模式，一般我们建议使用推送订阅，并且设置为“连续发送”，这样分发服务器会立刻将接收到的发布给发送到订阅服务器上。一旦发布数据库出了问题，订阅数据库上还有副本数据可以使用。复制的订阅服务器是可以访问的，因此你可以将一些只读的应用，如报表系统，运行在订阅服务器上，这能够分流发布数据库的负载。但是，由于数据库是用于灾难恢复的目的，你应该禁止任何人或应用更新订阅服务器上的数据。

一般来说，事务复制的同步滞后时间会小于日志传送，但是无法像数据库镜像技术那样实现完全同步和数据零损失。同时，事务复制带来的额外负载一般会高于日志传送。事实上，事务复制最适合用于数据库对象级别的复制，例如仅复制一个或几个表，而不是复制整个数据库。事务复制的强大之处在于它可以只同步几个表，甚至是表中的部分数据，这是数据库镜像和日志传送都无法达到的功能。微软也建议只在同步比较小量数据的情况下使用事务复制作为灾难恢复方案。

另外，复制只同步表格里的数据，而不会同步其他数据库对象，例如，数据库用户、存储过程、索引、约束、外键、触发器等。仅仅使用复制，是无法得到一个完整的数据库的。应用程序一般无法直接使用订阅服务器上的数据库。用户常常是在主服务器出现问题的时候，先恢复数据库结构，然后将订阅服务器上的表导回到主服务器（发布服务器）。在服务器上恢复数据库的某几个表往往比恢复整个数据库更困难，你除了需要确保表中的数据恢复回来之外，还要确保和表相关的对象（索引，约束，外键，触发器等）也被全部恢复回来。

所以，复制是一个用来实现数据同步的技术，而不是设计用来实现灾难恢复的。复制作为灾难恢复方案，存在以下这些问题：

1.  复制是以表和其他数据库对象为单位的数据同步功能，使用系统表来维护所有表的变更，因此需要大量的额外开销（如触发器等）来监控数据的变更并维护系统表。如果要把整个数据库中的所有内容都发布出去，则这部分开销会变得非常大，一般是不建议的。

2.   复制在主服务器（发布服务器）和备用服务器（订阅服务器）之间，还使用一个额外的角色分发服务器来做中转。这额外增加了同步的开销并且使滞后时间更长。复制需要使用不同的代理程序来传送数据，这些代理程序都是独立于SQLServer进程以外的可执行程序，这些程序和SQL Server之间的进程交互也增加了复制带来的开销。

3.   复制需要将事务日志文件的内容解析成二进制格式的命令写入系统表中，然后再将这些命令发送到订阅端的数据库上去执行。这些造成了两次数据传递过程。当变更量非常大的时候，这样的过程会造成较长时间的延迟。

4.   复制对表的定义有要求，不是所有的表格都能做复制。它需要在所有参与复制的表上创建主键或者增加rowguid的列。因此实施复制需要在数据库设计阶段就要考虑。对已经上线的系统中使用复制功能，可能需要一些二次开发的工作。

5.   复制非常依赖分发数据库来作为数据的中转。一旦分发数据库出了问题，保存在分发数据库中那些还没发送出去的更新会全部丢失，也就是说分发数据库的存在增加了整个灾备方案失败和数据损失的可能性。此外，一旦分发数据库出问题，整个复制也需要重建，重建意味着重新在订阅服务器上做初始化，这都是费时费力的工作。

6.  与数据库镜像和日志传送不同，订阅数据库本身不限制写操作。也就是说从系统层面上复制无法杜绝在订阅数据库发生更新操作，而只能依靠人为的管理和安全措施。因此，订阅服务器上数据的可靠性是存在一定风险的。