事务复制

适用于：SQL ServerAzure SQL 数据库Azure SQL 托管实例

本文介绍 SQL Server 的事务复制。 事务复制通常从发布数据库对象和数据的快照开始。 创建了初始快照后，接着在发布服务器上所做的数据更改和架构修改通常在修改发生时（几乎实时）便传递给订阅服务器。 数据更改会按照其在发布服务器上发生的相同顺序，并在相同的事务边界内应用到订阅服务器；因此，在一个发布中可保证事务一致性。

概述

事务复制通常用于服务器到服务器环境中，在以下各种情况下适合采用事务复制：

  • 您希望在增量更改发生时将其传播到订阅方。

  • 从发布服务器上发生更改，至更改到达订阅服务器，应用程序需要这两者之间的滞后时间较短。

  • 应用程序需要访问中间数据状态。 例如，如果某一行被更改了五次，事务复制允许应用程序对每次更改作出响应（例如，触发触发器），而不只是对该行的净数据更改作出响应。

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

  • 发布服务器或订阅服务器是非 SQL Server 数据库（例如，Oracle）。

默认情况下，事务发布的订阅者应被视为只读，因为不会将更改传播回发布者。 但是，事务复制确实提供了允许在订阅服务器上进行更新的选项。

注意

对于快照复制和事务复制，Azure SQL 托管实例可以是发布服务器、分发服务器和订阅服务器。 对于快照复制和事务复制，Azure SQL 数据库中的数据库只能是推送订阅服务器。 有关详细信息，请参阅使用 Azure SQL 数据库和 Azure SQL 托管实例进行事务复制。

配置 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 快照代理、日志读取器代理和分发代理实现的。 快照代理准备快照文件（其中包含了已发布表和数据库对象的架构和数据），然后将这些文件存储在快照文件夹中，并在分发服务器中的分发数据库中记录同步作业。

日志读取器代理监控为事务复制配置的每个数据库的事务日志，并将标记为用于复制的事务从事务日志复制到分发数据库，分发数据库充当可靠的存储转发队列。 分发代理将快照文件夹中的初始快照文件和分发数据库表中的事务复制到订阅服务器中。

在发布服务器中所做的增量更改根据分发代理的计划流向订阅服务器，分发代理可以连续运行以尽量减少滞后时间，也可以按预定的时间间隔运行。 由于数据更改必须在发布服务器中进行（使用事务复制时，无需指定立即更新或排队更新选项），从而避免了更新冲突。 最后，所有订阅服务器都将获得与发布服务器相同的值。 如果在事务复制中使用了立即更新或排队更新选项，则可以在订阅服务器上进行更新，而使用排队更新时，则可能发生冲突。

下图显示了事务复制的主要组件。

事务复制组件和数据流

初始数据集

新的事务复制订阅服务器在能够接收来自发布服务器的增量更改之前，必须包含与发布服务器中的表具有相同架构和数据的表。 初始数据集通常是一个快照，由快照代理创建，并由分发代理分发和应用。 初始数据集也可通过备份或其他方式（例如 SQL Server Integration Services）提供。

在向订阅服务器分发并应用快照时，只有那些等待初始快照的订阅服务器才会受到影响。 该发布的其他订阅方（即已完成初始化的订阅方）不会受影响。

并发快照处理

在生成快照期间，快照复制会对所有作为复制组成部分而发布的表加共享锁。 这样可以防止对发布表进行更新。 并发快照处理（事务复制的默认值）不会在整个快照生成期间保留共享锁，这允许用户在复制创建初始快照文件时继续不间断工作。

快照代理

快照代理在事务复制中实现初始快照的过程与快照复制中使用的过程相同（前面概述的关于并发快照处理的过程除外）。

生成快照文件后，可以使用 Microsoft Windows 资源管理器在快照文件夹中查看这些快照文件。

修改数据和日志读取器代理

日志读取器代理在分发服务器中运行；它通常连续运行，但也可以按照您制定的计划运行。 在执行过程中，日志读取器代理首先读取发布数据库的事务日志（即在 SQL Server 数据库引擎正常运行期间用于事务跟踪和恢复的同一数据库日志），并识别任何 INSERT、UPDATE 和 DELETE 语句，或在已标记为复制的事务中对数据所做的其他修改。 然后，该代理将这些事务批量复制到分发服务器中的分发数据库中。 日志读取器代理使用内部存储过程 sp_replcmds 从日志中获取标记为要复制的下一个命令集。 这样，分发数据库就成为一个存储转发队列，更改将从该队列发送到订阅服务器。 只有已提交的事务才会被发送到分发数据库。

将整个批处理事务成功写入分发数据库后，将提交该事务。 在每一批命令都提交到分发服务器后，日志读取器代理将调用 sp_repldone 以标记最终完成复制的位置。 最后，代理在事务日志中标记可以清除的行。 尚在等待复制的行不会被清除。

事务命令存储在分发数据库中，直到传播到所有订阅服务器或达到最大分发保留期为止。 订阅服务器接收事务的顺序，与这些事务在发布服务器上应用的顺序相同。

分发代理

对于推送订阅，分发代理在分发服务器上运行；对于请求订阅，分发代理在订阅服务器上运行。 该代理将事务从分发数据库移动到订阅服务器中。 如果订阅被标记为需要验证，则分发代理还要检查发布服务器和订阅服务器中的数据是否匹配。

发布类型

事务复制提供了四种发布类型：

发布类型 说明
标准事务性发布 适用于所有数据在订阅服务器中都是只读的拓扑（事务复制不在订阅服务器上强制执行这一点）。

默认情况下，使用 Transact-SQL 或复制管理对象 (RMO) 时，会创建标准事务发布。 使用“新建发布向导”时，通过在“发布类型”页上选择事务发布来创建它们。

有关创建发布的详细信息，请参阅 发布数据和数据库对象。
具有可更新订阅的事务发布 此发布类型的特征如下：

-每个站点都有相同的数据，并且各有一个发布服务器和一个订阅服务器。
- 可以在订阅服务器上更新行
- 此拓扑最适合需要高可用性和读取可伸缩性的服务器环境。

有关详细信息，请参阅可更新订阅。
点对点拓扑 此发布类型的特征如下：
- 每个位置都具有相同的数据，兼作发布服务器和订阅服务器。
- 同一行每次只能在一个位置进行更改。
- 支持冲突检测
- 此拓扑最适合需要高可用性和读取可伸缩性的服务器环境。

有关详细信息，请参阅 Peer-to-Peer Transactional Replication。
双向事务复制 此发布类型的特征如下：
双向复制类似于对等复制，但它不提供冲突解决。 此外，双向复制仅限于 2 台服务器。

有关详细信息，请参阅双向事务复制
  • Last updated on