大规模对等复制拓扑？

Question

我们有一个在地理上分布在偏远社区的客户端，每个物理位置之间的网络/互联网连接都有些不可靠。有一个中央位置和 52 个卫星位置。

通常，我们的应用程序部署为一个中央解决方案，其中只有一个数据库，所有位置都连接到一个数据库。数据本身由大多数表中的位置列进行分区（某些数据是集中的），并且应用程序的操作使得在一个物理位置接触数据不会接触另一个物理位置的数据，包括集中数据（至少，我们很确定它没有——如果有，那很可能是一个错误）。我们的客户希望进行集中报告（我们通常支持），以及跨企业同步多个集中配置表（相同，因为通常只有一个表副本）。

每个位置都有自己的数据中心，并获得 SQL Server 2008 R2 Enterprise 的许可。

我们的目标是部署我们的应用程序，使断开的网络/互联网连接不能阻止本地读/写操作，因为我们的应用程序是关键任务。

---

我的第一个想法是使用一个巨大的对等拓扑来复制数据库中的每个对象。我一直无法找到使用这种方法进行如此多的扩展的任何安装的任何文档或参考，所以我不知道它在技术上是否可行，如果是，将需要什么硬件。这是否适用于集中式分发数据库（为了便于管理）？这甚至是个好主意吗？如何部署数据库架构更改？索引维护是否会产生大量的网络开销？

还可以选择创建自己的解决方案，我认为这将涉及将数据库的单独副本（每个非中心位置仅包含其数据的分区部分）的日志传送到中心位置，然后使用一个合并工具（我们已经有了）来创建一个报告数据库。配置表更改将通过其他某种机制推出，可能是合并复制，可能是自制解决方案。

我考虑并测试了在整个数据库上使用合并复制，但我们需要大量的数据库和应用程序更改/重新设计/等。为了使这项工作正常进行，因此由于时间限制，我已经排除了这一点。（对此有何想法？）

---

我在这里寻找的是来自有更多经验的人的一些指导。显然，为此做好规划至关重要。我在正确的道路上吗？还有其他选择吗？_{^{（网址？）}}

Answer 1

对于仅仅 52 个客户端站点，复制就可以了。将您的本地副本视为“主”站点，并且始终让应用程序仅在本地副本上工作。使用复制将数据聚合到中央存储库以进行聚合报告。索引维护操作通常不会产生复制流量。通过应用程序部署迁移管理架构更改，即。每个发布版本都有升级脚本。

随着站点数量的增加，管理复制变得越来越困难。此外，许可将推动在外围部署 Express。当涉及复制时，SQL Server 升级绝对是一件痛苦的事情，因为升级组件（发布者、分发者、订阅者）的顺序很关键，但很难与许多站点协调。我所知道的 +1500 个站点的部署使用基于 Service Broker 的自定义数据移动。有关示例，请参阅使用 Service Broker 而不是复制。我什至见过使用 Service Broker 将新位（应用程序更改）推送到外围的设计，这些位反过来部署，当激活时，迁移和模式更改，使整个部署从中心操作。