在重新发布模型中，发布服务器将数据发送到订阅服务器，然后将数据重新发布到任何其他数量的订阅服务器。 当发布服务器必须通过缓慢或昂贵的通信链接将数据发送到订阅服务器时，这非常有用。 如果该链接的远端有多个订阅者，那么使用重新发布器会将分发负载的大部分转移到链接的远端。
重新发布数据涉及以下步骤：
在出版平台上创建出版物。
为重新发布的订阅者创建出版物的订阅。
初始化订阅。 在重新发布订阅服务器上创建发布之前，必须初始化订阅，否则复制将失败。
在重新发布的订阅服务器上在订阅数据库中创建发布。
在重新发布的订阅服务器上为其他订阅服务器创建订阅。
初始化订阅。
注释
如果在重新发布拓扑中使用合并复制，则所有重新发布的订阅者都必须使用服务器订阅。 有关订阅类型的详细信息，请参阅 “订阅发布”。
在下图中，发布服务器和重新发布者都充当自己的本地分发服务器。 如果每个分发服务器都设置为使用远程分发服务器，则每个分发服务器需要位于与其发布服务器相同的慢速或昂贵的通信链接的一侧。 发布者必须通过可靠的高速通信链接连接到远程分发服务器。
任何服务器都可以充当发布服务器和订阅服务器。 例如，请考虑以下示意图，其中存在一个在伦敦发布的表格，必须分发到美国的四个不同城市：芝加哥、纽约、圣地亚哥和西雅图。 纽约的服务器被选为订阅源自伦敦的已发布表，因为纽约站点满足以下条件：
回到伦敦的网络链接相对可靠。
伦敦到纽约的通信成本是可以接受的。
有良好的网络通信线路从纽约到美国所有其他订户站点。
复制支持下表中显示的重新发布方案。
| 发布者 | 发布订阅者 | 订户 |
|---|---|---|
| 事务性发布 | 事务订阅/事务发布 | 交易订阅 |
| 事务性发布 | 事务订阅/合并发布1 | 合并订阅 |
| 合并发布 | 合并订阅/合并发布 | 合并订阅 |
| 合并发布 | 合并订阅和事务性出版物 | 交易型订阅 |
1应在合并发布上设置 @published_in_tran_pub 属性。 默认情况下，事务复制要求订阅服务器上的表被视为只读。 如果合并复制对事务订阅中的表进行数据更改，则可能会出现数据不收敛的情况。 为避免此风险，建议在合并发布中将任何此类表指定为仅下载表。 这样可以阻止合并订阅者将数据更改上传到表。 有关详细信息，请参阅使用仅下载项目优化合并复制性能。