合并复制与更新主服务器和事务性 repl

Question

我工作的公司有两个不同的 SQL 服务器。一个是我们的主要生产服务器，而另一个基本上是一些表的副本，该服务器用于我们的帐户网站之类的东西。更改发生在第二台服务器上，然后通过合并复制同步到主服务器，然后同步到用于其他事情的所有其他订阅者。这些其他订阅者不必使用合并复制，因为他们只读取数据而不更新数据，但这是我们现在使用的。

我的问题是：有谁知道这种拓扑对性能的影响是什么？我正在考虑做两件事中的一件，并想知道我会从中获得什么样的表现。

1) 将其全部更改为事务复制。然后帐户网站只会更新主服务器，然后将内容复制回来。不利的一面是网站在几分钟内不会显示更改，但我认为复制的性能（和管理）可能会让这变得可以接受。

2) 更改它，以便主服务器和第二服务器使用合并，但我对其他所有内容都使用事务复制。我知道事务复制在服务器上的负载比合并少，但是我没有看到在同一个表上同时使用合并和事务的任何内容。实际上，我认为这样做的唯一好处是对这一切的管理。

Answer 1

您的解决方案取决于“其他”服务器需要做什么以及它们必须是最新的。让我解释一下。

对于任何多服务器数据基础架构，您有以下选项：

• 复制
• 日志传送
• 数据库镜像

复制是主服务器和帐户服务器之间的最佳方法。 如果您有带宽（甚至更好，两台服务器都位于 LAN 上），我建议您使用事务复制。这将使其在两个服务器上保持最新并接近实时，如果服务器之间有快速连接，性能不会受到太大影响。 （P.S. 您可以采用相同的方法将您的辅助服务器用作您正在复制的表的热备用设备，但这仅对恢复那些特定的表有用。）

对于所有其他服务器（似乎它们主要用于报告？），我建议尽量减少对主服务器的性能影响。为此，您可以考虑在高性能模式下使用日志传送或数据库镜像。

• 可以将日志传送设置为仅在晚上传送您的日志，从而减少在线时间的网络流量。

• 高性能模式下的数据库镜像将异步传送您的事务，还有助于减少流量（基于日志传送）

注意：这两种方法都意味着您只能从“其他”服务器上的数据库中读取。没有插入或更新。根据选择的实施，您的“其他”服务器也可能在更新方面落后于主服务器几分钟到几小时。

希望这会有所帮助。