对等 - 事务复制

适用范围：SQL Server

对等复制通过在多个服务器实例中维护数据副本，提供了一种可横向扩展且高可用的解决方案，这些服务器实例也称为 节点。 对等复制建立在事务复制的基础之上，近乎实时地传播事务上一致的更改。 这样，需要扩展读取操作的应用程序就可以将来自客户端的读取操作分布到多个节点上。 由于对等复制以近乎实时的方式维护节点上的数据，从而提供了数据冗余，提高了数据的可用性。

以某个 Web 应用程序为例。 它可以通过以下方式从对等复制中获益：

  • 目录查询和其他读取操作被分散到多个节点上。 这样，即使读取操作增加，性能也能保持稳定。

  • 如果系统中的某个节点失效，应用层可将该节点的写入操作重定向到其他节点。 这样便可保持可用性。

  • 如果节点需要维护或整个系统需要升级，则可以将各个节点脱机并在完成操作后再将其重新添加回系统中，而不影响到应用程序的可用性。

虽然点对点复制能够扩展读取操作，但该拓扑的写入性能与单个节点相当。 这是因为所有的插入、更新和删除操作最终都会传播到所有节点上。 复制可识别出更改已应用于给定节点这一情况，避免在节点间多次循环应用更改。 强烈建议仅在一个节点上执行每一行的写入操作，理由如下：

  • 如果在多个节点上修改了某一行，则将该行传播给其他节点时会导致冲突甚至丢失更新。

  • 复制更改时总是存在一定的延迟。 对于要求立即显示最新更改的应用程序而言，在多个节点上对应用程序执行动态负载平衡可能会出现问题。

对等复制提供了在对等拓扑中启用冲突检测的选项。 此选项有助于防止因未检测到的冲突引起的各种问题，包括不一致的应用程序行为和丢失更新。 启用该选项后，默认情况下，发生冲突的更改被视为导致分发代理失败的关键错误。 发生冲突时，拓扑将始终处于不一致的状态，直至手动解决冲突并使拓扑中的数据一致。 有关详细信息，请参阅 Conflict Detection in Peer-to-Peer Replication。

注意

为避免潜在的数据不一致，请确保在点对点拓扑中避免发生冲突，即使启用了冲突检测也是如此。 为了确保仅在某一个节点上执行特定行的写入操作，访问并更改数据的应用程序必须对其插入、更新和删除操作进行分区。 这种分区方式可确保：对给定行源自某一节点的修改，会先与该拓扑中的所有其他节点同步，然后才会由其他节点修改该行。 如果应用程序需要完善的冲突检测与解决功能，请使用合并复制。 有关详细信息，请参阅合并复制和检测并解决合并复制冲突。

点对点拓扑

以下场景说明了对等复制的典型使用场景。

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

对等复制，双节点

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

  • 由于将读取操作分散到两台服务器上，因此提高了读取的性能。

  • 当需要维护或某一节点出现故障时，可以提供更高的可用性。

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

  • 在左图中，在两台服务器间对更新进行了分区。 例如，如果数据库包含产品目录，则可以令自定义应用程序把对名称以 A-M 开头的产品进行的更新定向到节点 A ，把对名称以 N-Z 开头的产品进行的更新定向到节点 B 。然后将更新复制到另一个节点。

  • 在右侧，所有更新都定向到节点 B。在此处，更新将复制到节点 A。如果 B 处于脱机状态（例如维护），则应用程序服务器可以将所有活动定向到 A。当 B 重新联机时，更新可以流向其中，应用程序服务器可以将所有更新移回 B 或继续将它们定向到 A。

对等复制可以支持这两种方法中的任一种，但右侧所示的中心更新示例也经常与标准事务复制一起使用。

包含三个或三个以上参与数据库的拓扑

分散站点间的对等复制

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

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

  • 独立但不孤立：每个办事处都可以独立插入、更新或删除数据，但还可以共享数据，因为数据会复制到其他所有的参与数据库。

  • 在出现故障或需要维护一个或多个参与数据库时可提供更高的可用性。

    对等复制，三节点和四节点

    上图显示了向三节点拓扑添加节点的过程。 在此应用情景中，可能会由于以下原因再添加一个节点：

  • 因为又新开了一家办事处。

  • 为了提供更高的可用性以支持维护或提高发生磁盘故障或其他重大故障时的容错能力。

请注意，在三节点拓扑和四节点拓扑中，所有的数据库都向其他数据库发布和订阅数据。 在需要进行维护或者一个或多个节点发生故障时，这样可提供最大的可用性。 随着节点的增加，您必须在可用性和可扩展性需求与性能以及部署和管理的复杂性之间进行权衡。

配置点对点复制

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

配置 TLS 1.3 加密

SQL Server 2025 （17.x） 引入了对对等复制的 TDS 8.0 支持，其中包括：

  • 将复制代理配置为在 SQL Server 2025（17.x）实例与 SQL Server 2025（17.x）和 Azure SQL 托管实例之间使用 TLS 1.3 加密 。
  • 复制拓扑中 SQL Server 2025 （17.x） 实例之间的实例间链接服务器通信的默认加密。 SQL Server 2025（17.x）中的链接服务器使用默认为 Encrypt=Mandatory 加密的 OLE DB v19 驱动程序。

注意

对于具有远程分发器的复制拓扑：

使用对等复制时的注意事项

本节提供在使用对等复制时要考虑的信息和指导原则。

一般注意事项

  • 对等复制仅在 SQL Server 企业版中提供。

  • 所有参与对等复制的数据库都应包含相同的架构和数据：

    • 对象名称、对象架构和发布名称都应相同。

    • 发布必须允许复制架构更改。 （这是发布属性 replicate_ddl 的 1 设置，即默认设置。）有关详细信息，请参阅对发布数据库进行架构更改。

    • 不支持行筛选和列筛选。

  • 每个节点应使用自己的分发数据库。 这样将消除出现单点故障的可能性。

  • 表和其他对象不能包含在一个发布数据库内的多个对等发布中。

  • 必须先将发布启用为对等复制，然后才能创建任何订阅。

  • 必须使用备份或 replication support only 选项来初始化订阅。 有关更多信息，请参阅不使用快照初始化事务订阅。

  • 不要使用标识列。 使用标识列时，必须手动管理每个参与数据库中分配给各个表的范围。 有关更多信息，请参阅为手动管理标识范围分配范围。

功能限制

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

  • 使用快照进行初始化和重新初始化。

  • 行筛选器和列筛选器。

  • 时间戳列。

  • 非 SQL Server 的发布服务器和订阅服务器。

  • 即时更新订阅和排队更新订阅。

  • 匿名订阅。

  • 部分订阅。

  • 可附加的订阅和可转换的订阅。 （SQL Server 2005 (9.x) 中已弃用这些选项。）

  • 共享分发代理。

  • 分发代理参数 -SubscriptionStreams 和日志读取器代理参数 -MaxCmdsInTran。

  • 文章属性 @destination_owner 和 @destination_table。

  • 对等事务复制不支持创建针对对等发布的单向事务订阅

  • 对等事务性复制不支持发布主键中包含计算列的表。

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

  • @allow_initialize_from_backuppublication 属性要求值为 true。

  • 文章属性 @replicate_ddl 要求值为 true；@identityrangemanagementoption 要求值为 manual；并且 @status 要求设置选项 24。

  • 项目属性 @ins_cmd@del_cmd 和 @upd_cmd 的值不能设置为 SQL。

  • 订阅属性 @sync_type 的值必须为 无 或 自动。

  • SQL Server 2019 (15.x) CU 13 引入了发布属性 @p2p_confictdetection_policy。 默认参数值为 originatorid，它会根据发起方 ID 解决冲突。 lastwriter 参数值按最后写入者优先的原则解决冲突。

维护注意事项

一些操作需要让系统静止。 也就是说，停止所有节点上已发布表中的活动，并确保每个节点都已收到来自所有其他节点的更改。

操作 仅包含 SQL Server 2005 对等节点，或者混合包含 SQL Server 2005 对等节点以及 SQL Server 2008 及更高版本的对等节点 仅使用 SQL Server 2005 对等，或混合使用 SQL Server 2005 对等与 SQL Server 2008 对等和更高版本 SQL2008 同级版本及更高版本 SQL2008 同级版本及更高版本
向拓扑添加节点 完整拓扑中有 2 个节点：无需处于静止状态。 使用 sync_type = 'initialize with backup'。 超过 2 个节点：需要静默。 sync_type = 'replication support only'：需要处于静止状态。 sync_type = 'initialize with backup' 和 'initialize from lsn'：无需进行静默处理。

拓扑架构更改（添加或删除条目）需要先使系统进入静止状态。 有关详细信息，请参阅管理对等拓扑（复制 Transact-SQL 编程）。

从拓扑中移除节点时，绝不需要先进入静默状态。

通过使用 sp_changearticle 更改项目属性时从不需要处于静止状态。 P2P 允许的更改有 description、 ins_cmd、 upd_cmd和 del_cmd 属性。

项目架构更改（添加/删除列）从不需要处于静止状态。

  • 添加文章：若要将项目添加到现有配置-我们需要静止系统，执行 CREATE TABLE 语句并在拓扑中的每个节点上加载初始数据，并在拓扑中的每个节点上添加新项目。

  • 删除文章：如果我们想让所有节点上的状态保持一致，就需要使拓扑进入静止状态

有关详细信息，请参阅停止复制拓扑（复制 Transact-SQL 编程）和管理对等拓扑（复制 Transact-SQL 编程）。

  • 如果要将新节点添加到对等拓扑中，只应从在添加新节点后创建的备份中进行还原。

  • 不能在对等拓扑中重新初始化订阅。 如果需要确保节点有新的数据副本，请在该节点上还原备份。

相关内容

  • Last updated on