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