对等事务复制

更新日期： 2006 年 12 月 12 日

对等事务复制是专为可以读取或修改任何参与复制的数据库中的数据的应用程序设计的。例如，在线购物应用程序非常适合对等复制：通过将读取数据的查询分散到多个数据库，可以提高应用程序的性能。此外，如果任意承载数据库的服务器不可用，可以编制应用程序来将流量路由到剩余的服务器，这些服务器包含数据的相同副本。由于活动可以分散到所有节点，因此读取性能将得到提高。拓扑的更新、插入和删除总性能与单个节点的性能类似，因为所有更改最终将传播到所有节点。

对等拓扑中的所有节点都是对等的：每个节点所发布和订阅的架构和数据都是相同的。在所有节点都可进行更改（插入、更新和删除）。复制可以识别何时将更改应用到给定节点，从而避免所做的更改在节点间循环多次。

注意：
访问和更改数据的自定义应用程序必须确保其插入、更新和删除操作都按分区进行，这样对来自某结点的给定行所做的修改可以在其他节点修改该行之前与拓扑中所有其他数据库同步。如果应用程序对多节点上的给定行执行并发修改时发生冲突，请使用合并复制，这种复制非常适合处理冲突。有关合并复制的详细信息，请参阅合并复制概述。

标准事务复制采用只读订阅服务器，并且其结构为层次结构：通常，一台发布服务器向一台或多台订阅服务器发布数据。标准事务复制还支持重新发布层次结构：将更新从发布服务器传递到一组重新发布订阅服务器，这些订阅服务器依次将更新传递到最终的一组“叶节点”**订阅服务器。更新订阅为订阅服务器提供了将更改推送回发布服务器的功能，但因为更改在订阅服务器和发布服务器之间移动时遵循层次结构，所以更改的排列仍为层次结构。与只读事务复制和具有更新订阅的事务复制相比，对等复制拓扑中节点之间的关系是对等关系而不是层次结构关系，每个节点均包含完全相同的架构和数据。

注意：
虽然可以在多个参与的数据库中进行更新，但是请务必了解：对等拓扑不需要或不允许立即或排队对发布选项的更新。有关立即更新和排队更新的详细信息，请参阅事务复制的可更新订阅。

对等拓扑

下列方案说明了对等复制的典型应用。

包含两个参与数据库的拓扑

上面每个关系图都显示了两个参与数据库，以及通过应用程序服务器将用户流量定向到数据库。此配置可用于从网站到工作组应用程序等多种应用程序，并具有下列优点：

• 由于将读取操作分散到两台服务器上，因此提高了读取的性能。
• 当需要维护或某一节点出现故障时，可以提供更高的可用性。

从这两张图中可以看到，读取活动在参与数据库间进行负载平衡，但更新的处理方式则有所不同：

• 在左图中，在两台服务器间对更新进行了分区。例如，如果数据库包含产品目录，则可以令自定义应用程序把对名称以 A-M 开头的产品进行的更新定向到节点 A，把对名称以 N-Z 开头的产品进行的更新定向到节点 B。然后将更新复制到另一个节点。
• 在右图中，所有更新都定向到节点 B。再从那里将更新复制到节点 A。如果 B 脱机（例如，为了维护），则应用程序服务器可以将所有活动定向到节点 A。当节点 B 恢复联机状态后，更新可以流向 B，并且应用程序服务器可以将所有更新移动回节点 B，或继续将更新定向到节点 A。

对等复制对这两种方法均支持，但右图中的中心更新示例也经常同标准事务复制一起使用。

包含三个或更多参与数据库的拓扑

上图显示了三个参与数据库，它们作为一家在洛杉矶、伦敦和台北均设有办事处的国际软件支持单位的后端数据库。每个办事处的支持工程师接听客户电话，并输入和更新每个客户电话的相关信息。三个办事处的时区各相差八小时，因此不会出现工作日的重叠：台北办事处下班时，伦敦办事处正开始一天的工作。如果办事处下班时电话仍在进行中，则电话将被转接到下一个开始办公的办事处的代表。

每个地点都有一台数据库服务器和一台应用程序服务器，供支持工程师在输入和更新客户电话的相关信息时使用。拓扑按时间进行分区，因此更新只发生在正在办公的节点。然后更新流动到其他参与数据库。此拓扑具有下列优点：

• 独立，但不孤立：每个办事处都可以独立插入、更新或删除数据，还可以共享数据，因为数据将复制到其他所有的参与数据库。
• 出现故障或维护任一参与数据库的同时可提供更高的可用性。
  

上图显示了向三节点拓扑添加节点的过程。当出现下列情形时，可以添加一个节点：

• 因为又开设了一家办事处。
• 为了提供更高的可用性以支持维护或提高发生灾难性错误时的容错能力。
• 请注意：在三节点拓扑和四节点拓扑中，所有的数据库都向其他数据库发布和订阅，从而在需要维护或者一个或多个节点发生故障时，提供最大的可用性。添加节点后，必须针对性能以及部署和管理的复杂性来权衡可用性和可伸缩性的需要。

配置对等复制

配置对等复制拓扑的过程与配置一系列标准事务发布和订阅的过程非常类似。下列主题中介绍的步骤显示了一个三节点系统的配置，与上面左图中显示的配置相似。

配置对等事务复制

• SQL Server Management Studio: 如何配置对等事务复制 (SQL Server Management Studio)
• 复制 Transact-SQL 编程：How to: Configure Peer-to-Peer Transactional Replication (Replication Transact-SQL Programming)

使用对等复制的注意事项

使用对等复制时请谨记下列注意事项：

一般注意事项

• 对等复制仅在 SQL Server 2005 Enterprise Edition 中可用。
• 所有参与数据库都应包含相同的架构和数据：
  • 参与数据库之间的对象名称、对象架构和发布名称都应相同。
  • 发布必须允许复制架构更改（即将发布属性 replicate_ddl 设置为 1，这是默认设置）。有关详细信息，请参阅对发布数据库进行架构更改。
  • 不支持行筛选和列筛选。
• 建议每个节点都使用自己的分发数据库。这样将消除出现单点故障的可能性。
• 表和其他对象不能包含在一个发布数据库内的多个对等发布中。
• 必须为对等复制启用发布后，才能创建订阅。
• 必须使用备份或 replication support only 选项对订阅进行初始化。有关详细信息，请参阅初始化事务订阅（不使用快照）。
• 不提供冲突的检测和解决。对给定行的更新应该仅在一个数据库上进行，直到此数据库与对等方同步为止。例如，可以通过将一组行的更新定向到特定节点的应用程序来达到此目的。
• 建议不要使用标识列。使用标识时，必须手动管理所分配的每个参与数据库中表的范围。有关详细信息，请参阅复制标识列主题中的“为手动标识范围管理分配范围”部分。

功能限制

对等复制支持事务复制的核心功能。它不支持以下选项：

• 使用快照进行初始化和重新初始化。
• 行筛选器和列筛选器。
• 时间戳列。
• 非 SQL Server 的发布服务器和订阅服务器。
• 立即更新订阅和排队更新订阅。
• 匿名订阅。
• 部分订阅。
• 可附加的订阅和可转换的订阅（在 SQL Server 2005 中均不推荐使用）。
• 共享分发代理。
• 分发代理参数 -SubscriptionStreams 和日志读取器代理参数 -MaxCmdsInTran。
• 项目属性 @destination_owner 和 @destination_table。

以下属性具有特殊的注意事项：

• 发布属性 @allow_initialize_from_backup 需要值“true”。
• 项目属性 @replicate_ddl 需要值“true”；@identityrangemanagementoption 需要值“manual”；而 @status 需要设置选项“24”。
• 项目属性 @ins_cmd、@del_cmd 和 @upd_cmd 的值不能设置为“SQL”。
• 订阅属性 @sync_type 需要值“none”或“automatic”。

维护注意事项

• 下列操作要求系统停止（停止所有节点中已发布表的活动，并确保每个节点都已收到来自所有其他节点的更改）：
  • 将节点添加到现有拓扑
  • 将项目添加到现有发布
  • 进行架构更改
  • 从备份还原节点
    有关详细信息，请参阅如何配置对等事务复制 (SQL Server Management Studio)、How to: Quiesce a Replication Topology (Replication Transact-SQL Programming)和How to: Administer a Peer-to-Peer Topology (Replication Transact-SQL Programming)。
• 如果向对等拓扑添加了新节点，应只从添加新节点后创建的备份还原。有关详细信息，请参阅如何配置对等事务复制 (SQL Server Management Studio)。
• 无法重新初始化对等拓扑中的订阅。如果需要确保节点具有新的数据副本，请在该节点上还原备份。

更改历史记录

请参阅

概念

快照复制和事务复制的备份和还原策略
事务复制的发布类型

其他资源

How to: Administer a Peer-to-Peer Topology (Replication Transact-SQL Programming)

帮助和信息

获取 SQL Server 2005 帮助