使用 SQL Server 复制对性能有何影响？

Question

Answer 1

要添加有关事务复制的更多信息：

它使用 SQL 代理日志读取器作业从发布数据库的事务日志中收集已提交的事务。这意味着在读取日志记录之前无法清除日志。如果日志读取器代理周期发生变化，那么您的日志可能会意外增长。日志读取器代理还可能导致大容量 OLTP 系统上的事务日志争用，这当然取决于您的 IO 子系统。
复制不保证零数据丢失，因为在读取日志记录并将它们通过分发器传递给订阅者时存在延迟。对于零数据丢失，请查看同步数据库镜像或同步 SAN 复制
对等复制是扩展查询工作负载的好方法，还可以为您的数据添加一些冗余
您必须对点对点进行一些仔细的模式设计，以避免由于不同节点的类似更改引起的冲突。不要为此使用分区标识。使用复合代理键（例如节点标识符 + bigint）
对于点对点，很难为拓扑中的各个节点添加额外的冗余。发布者可以镜像，订阅者可以镜像（2008 年相当容易，2005 年不太容易），但分发者不能。它必须集群以增加冗余。

编辑：好的 - 现在是午餐时间，我还有一些要补充的：

点对点复制：在 2005 年，如果您想完全更改拓扑（添加或删除节点），您必须停顿整个拓扑。2008 年不需要。
对等复制直到 2008 年才具有冲突检测功能，但即便如此，它的冲突解决也相当脑残——具有最高 ID（称为对等发起者 ID）的节点获胜——可能不是你想要的。
对等复制：所有节点都可以看到其他节点的所有更改。这意味着在三向拓扑中，例如西雅图、伦敦、东京——如果西雅图倒塌，伦敦和东京继续前进。如果东京随后宕机而西雅图上线，它将从伦敦获取所有伦敦更新以及伦敦知道的所有东京更新，来自伦敦。漂亮整齐。
没有任何形式的故障检测或带有复制的自动故障转移。也许看看镜像。我想你可以使用某种形式的 NLB。

在选择任何类型的 HA 解决方案时（因为我今天正在为内部 Microsoft DBA 教授 HA 课程，这是个好时机），您需要在评估技术之前先进行需求分析。在不了解您的所有要求的情况下给出建议有点困难。

再次编辑：

它的使用示例：具有中间层负载平衡的数据层中的各种服务器。点对点允许所有节点（最终）保持同步。
令人讨厌的问题是：如果用户被路由到节点 1 并进行交易，那么在将数据复制到其他节点之前需要多长时间，因为 repl 延迟可能会有所不同？如果用户再次连接到服务，将她路由到哪个节点？与以前相同的节点还是经过了足够的时间才能安全地路由到任何节点并保证她所做的先前事务已复制到所有节点？

好的 - 没有更多的编辑！:-)