通过

对等 - 事务复制

  • 项目

适用范围：SQL Server

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

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

  • 目录查询和其他读取操作被分散到多个节点上。 这样，当读取操作增多时，仍能够保持原有的性能。

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

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

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

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

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

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

注意

为了避免潜在的数据不一致性，即便已经启用了冲突检测功能，也应尽力避免对等拓扑中发生冲突。 为了确保仅在某一个节点上执行特定行的写入操作，访问并更改数据的应用程序必须对其插入、更新和删除操作进行分区。 分区可确保在一个节点上对给定行的修改可以在其他节点修改该行之前，与拓扑中所有其他节点同步。 如果应用程序需要完善的冲突检测与解决功能，请使用合并复制。 有关详细信息，请参阅合并复制和检测并解决合并复制冲突。

对等拓扑

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

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

对等复制，双节点

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

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

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

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

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

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

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

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

向分散位置的对等复制

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

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

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

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

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

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

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

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

请注意，在三节点拓扑和四节点拓扑中，所有的数据库都向其他数据库发布和订阅数据。 在需要进行维护或者一个或多个节点发生故障时，这样可提供最大的可用性。 添加节点后，必须针对性能以及部署和管理的复杂性来权衡可用性和可伸缩性的需要。

配置对等复制

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

使用对等复制的注意事项

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

一般注意事项

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

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

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

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

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

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

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

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

  • 必须使用备份或 replication support only 选项来初始化订阅。 有关详细信息，请参阅 初始化事务订阅（不使用快照）中手动初始化订阅。

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

功能限制

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

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

  • 行筛选器和列筛选器。

  • 时间戳列。

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

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

  • 匿名订阅。

  • 部分订阅。

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

  • 共享分发代理。

  • 分发代理参数 -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 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 编程）。

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

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

相关内容