SQL Server 双向事务复制 - 这是一个很好的用例吗？

Posted 2023-02-15

【中文标题】SQL Server 双向事务复制 - 这是一个很好的用例吗？

【英文标题】：SQL Server Bi-Directional Transactional Replication - Is it a good use-case?

【发布时间】：2012-11-10 06:48:41

【问题描述】：

我们在使用 SQL Server 进行横向扩展时遇到问题。这主要是因为以下几个原因：1）数据结构设计不佳，2）繁重的工作和业务/处理逻辑都是在 T-SQL 中完成的。我们聘请了一位来自 Redmond 的 Microsoft SQL 人员验证了这一点，该人员在我们的服务器上执行分析。我们实际上是通过不断增加命令超时来解决问题，这很荒谬，而且不是一个好的长期解决方案。此后，我们制定了以下策略和阶段：

第 1 阶段：解决问题的硬件/软件以止血。

这包括一些不同的东西，比如缓存服务器，但我想在此向大家询问的具体内容与在新 SQL 服务器上实现双向事务复制有关。我们有两个想要实现它的用例：

我们正在考虑在这个新的 SQL“处理框”上运行长时间运行（和表/行锁定）的 SELECT，并将它们放入缓存层并让 UI 从缓存中读取它们。这些 SELECT 生成报告并在网络上返回结果。

大部分业务逻辑都在 SQL 中。我们有一些 LONG 运行查询，用于执行处理逻辑的 SELECT、INSERT、UPDATE 和 DELETE。处理完成后，最终结果实际上只是一堆 INSERT、UPDATE 和 DELETE（大量游标）。想法是平衡这两个服务器之间的负载。

我有一些问题：

这些是双向事务复制的好用例吗？

我需要确保这个解决方案能够“正常工作”并且不必担心冲突。在这个解决方案中哪里会出现冲突？我已经阅读了一些关于重置身份种子的增量以防止冲突的文章，这是有道理的，但是它如何处理更新/删除或其他可能发生冲突的地方？

我可能会遇到哪些其他问题需要我们注意？

这个问题有更好的解决方案吗？

第 2 阶段：将逻辑重写到 .NET 中，并优化 SQL 存储过程以仅执行基于集合的操作，这也是应该的。

这显然需要一段时间，这就是为什么我们想看看是否可以采取一些初步措施来阻止用户所经历的痛苦。

谢谢。

【参考方案1】：

恕我直言，双向复制与“它会正常工作”相去甚远。防止更新冲突需要精心规划，确保所有“处理”都经过精心策划，绝不会处理重叠数据。主-主复制是最难实现的解决方案之一。

考虑一下：您设想一种解决方案，该解决方案提供廉价的 2 倍横向扩展，几乎无需修改代码。这样的解决方案将非常有用，人们希望看到它部署在无处不在。却无处可寻。

我建议您搜索许多描述关于（更流行的）mysql 主-主部署的陷阱和警告的博客和文章（例如If You Must Deploy Multi-Master Replication, Read This First），自己判断麻烦是否值得。

我没有你所做的所有细节，但我会专注于应用程序。如果您只想在短期内解决问题，我会确保在考虑横向扩展（SSD / Fusion驱动器，更多RAM）之前用尽廉价的纵向扩展。如果锁定是主要问题，还要先调查快照隔离级别/读取提交的快照。