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

Question

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

第 1 阶段:使用硬件/软件解决问题以止血。

这包括一些不同的东西，例如缓存服务器，但我想向这里的每个人询问的是与在新的 SQL 服务器上实现双向事务复制特别相关的问题。我们有两个用例想要实现这一点:

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

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

我有一些问题:

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

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

3. 我可能会遇到哪些其他问题并且需要注意？

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

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

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

谢谢。

Answer 1

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

考虑一下:您设想一种解决方案，可以提供廉价的 2 倍横向扩展，而几乎无需修改代码。这样的解决方案将非常有用，人们希望看到它部署到任何地方。然而却不见踪影。

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

我没有您提供的所有详细信息，但我会重点关注应用程序。如果你想短期内花钱解决这个问题，我会确保在考虑横向扩展(SSD/Fusion 驱动器、更多 RAM)之前先用尽廉价的纵向扩展。如果锁定是主要问题，还要首先调查快照隔离级别/读取已提交快照。