适用于：
SQL Server
合并复制与事务复制一样，通常从发布数据库对象和数据的快照开始。 在发布者和订阅者上进行的后续数据更改和架构修改将使用触发器进行跟踪。 订阅者在连接到网络时将与发布者进行同步，并交换自上次同步以来发布者和订阅者之间发生更改的所有行。
合并复制通常用于服务器到客户端的环境中。 合并复制适用于下列各种情况：
多个订阅者可能在不同时间更新相同的数据，并将这些更改传播给发布者和其他订阅者。
订阅者需要接收数据，脱机更改数据，并在以后与发布者和其他订阅者同步更改。
每个订阅者都需要不同的数据分区。
冲突可能会发生；当冲突发生时，你需要能够检测和解决冲突。
应用程序需要最终的数据更改结果，而不是访问中间数据状态。 例如，如果一行在与发布者同步之前在订阅者上更改了五次，则该行在发布者上将只更改一次，以反映净数据更改（即第五个值）。
合并复制允许不同站点自主工作，并在以后将更新合并成一个统一的结果。 由于更新是在多个节点上进行的，因此发布服务器和多个订阅服务器可能已更新相同的数据。 因此，合并更新时可能会发生冲突，合并复制提供了几种处理冲突的方法。
合并复制是由 SQL Server 快照代理和合并代理实现的。 如果发布未经筛选或使用静态筛选器，快照代理将创建单个快照。 如果发布使用参数化筛选器，则快照代理将为每个数据分区创建一个快照。 合并代理将初始快照应用于订阅者。 它还将合并自初始快照创建后发布者或订阅者上所发生的增量数据更改，并根据所配置的规则检测和解决任何冲突。
若要跟踪更改，合并复制（和带有排队更新订阅的事务复制）必须能够唯一地标识每个已发布表中的每一行。 若要完成此合并复制，需要向每个表中添加列 rowguid，除非该表中已有数据类型为 uniqueidentifier 且设置了 ROWGUIDCOL 属性的列（在这种情况下，将使用该列）。 如果表从发布中删除了，则 rowguid 列会被移除；如果现有列用于跟踪，则不会删除该列。 筛选器不得包含复制用于标识行的 rowguidcol。 newid() 函数被作为rowguid列的默认提供，不过客户可以根据需要为每行提供一个GUID。 但是，不要提供值 00000000-0000-0000-0000-000000000000。
下图显示了合并复制中使用的组件。
