推荐用于事务复制的分发服务器架构？

Question

我们计划在 SQL Server 2008 R2 的 2 个节点上创建一个事务复制，每个节点将是一个发布者和一个订阅者。

完成此场景的最佳实践是什么？微软一直建议分发者应该独立于发布者或订阅者，因此很明显，场景中要涉及到第三个节点。但是，由于每个节点将同时是发布者和订阅者，同一个（第三个节点）可以成为 2 个发布者的分发者吗？我应该创建 2 个分发服务器，还是仍然可以使用相同的架构，只使用 2 个节点，每个节点都充当分发服务器和发布服务器？

Answer 1

完成此场景的最佳实践是什么？

这取决于您要复制的数据量，即

• 您是否正在复制选定的列/表、整个数据库（所有表）等？
• 两个节点位于同一域还是不同域？
• 您是在同一区域还是跨区域（美国-英国等）进行复制？

我已经实现了 T-Rep，其中我使用相同的服务器作为发布者和分发者，因为需要复制的数据较少，并且还在单独的服务器上实现了单独的分发数据库，​​该数据库完成了将数据发布给订阅者的所有繁重工作我们有大量数据可以推送给订阅者。

您必须考虑以下因素 -

• 执行快照并将该快照应用于订阅者所花费的时间
• 当复制涉及的表发生重大（例如架构）更改时，可以重新初始化项目。

我应该创建 2 个经销商吗？ 您可以使用相同的分发数据库。不过，为了便于维护和提高性能[减少争用 - 写入和读取分发数据库]，我强烈建议您使用单独的分发数据库。

请记住，分发数据库是复制的核心。因此，它需要适当的维护、备份等。现在，如果您只有 1 个支持多个发布者的分发数据库，​​并且发生了灾难，那么从以前的备份恢复它将会影响所有发布者。

来自博尔：

在许多情况下，单个分发数据库就足够了。但是，如果多个发布服务器使用单个分发服务器，请考虑为每个发布服务器创建一个分发数据库。这样做可以确保流经每个分发数据库的数据是不同的。

最后一些可以帮助您的好参考：

深入探讨从备份初始化以进行事务复制

复制非聚集索引可提高订阅者查询性能

跟踪事务复制中的数据 - 白皮书

事务复制故障排除

横向扩展分发数据库