我们遇到了使用SQL服务器扩展的问题。这主要是由于以下几个原因：1）设计不良的数据结构，2）繁重的工作和业务/处理逻辑都是在T-SQL中完成的。这是由我们聘请的Redmond的Microsoft SQL人员在我们的服务器上进行分析验证的。我们通过不断增加命令超时来解决问题，这是荒谬的，而不是一个好的长期解决方案。我们已经将以下策略和一系列阶段放在一起：
这包括一些不同的东西，比如缓存服务器，但是我想在这里问每个人有关在新SQL服务器上实现双向事务复制的具体问题。我们有两个用例想要实现这个：
我们考虑在这个新的SQL“处理盒”上运行长时间运行（和表/行锁定）SELECT并将它们放入缓存层并让UI从缓存中读取它们。这些SELECT正在生成报告，并在网络上返回结果。
大多数业务逻辑都在SQL中。我们有一些 LONG 运行查询，用于执行处理逻辑的SELECT，INSERT，UPDATE和DELETE。最终结果实际上只是在处理完成后（大量游标）充满了INSERT，UPDATE和DELETE。我们的想法是平衡这两台服务器之间的负载。
我有一些问题：
这些是用于双向事务复制的好用例吗？
我需要确保此解决方案“正常工作”而不必担心冲突。在这个解决方案中会出现哪些冲突？我已经阅读了一些关于重置身份种子增量的文章，以防止冲突，这是有道理的，但它如何处理UPDATE / DELETE或其他可能发生冲突的地方？
我可能会遇到哪些其他问题，我们需要注意哪些问题？
这个问题有更好的解决方案吗？
这显然需要一段时间，这就是为什么我们想看看是否有一些初步步骤可以阻止用户遇到的痛苦。
感谢。
答案 0 :(得分：5)
Imho双向复制与'它只会工作'非常相似。防止更新冲突需要精心规划，确保精心编排的所有“处理”永远不会处理重叠数据。主 - 主复制是最困难的解决方案之一。
考虑一下：您设想的解决方案是提供廉价的2倍扩展，几乎不需要修改代码。这样的解决方案非常有用，人们期望看到它在任何地方部署。然而，无处可见。
我建议你搜索许多博客和文章，描述关于（更受欢迎的）MySQL master-master部署（例如If You Must Deploy Multi-Master Replication, Read This First）的陷阱和警告，自己判断是值得的。< / p>
我没有你做的所有细节，但我会专注于应用程序。如果你想在短期内解决这个问题，我会确保在考虑横向扩展（SSD / Fusion驱动器，更多内存）之前，廉价的扩展已经耗尽。如果锁定是主要问题，还要先调查快照隔离级别/读取提交的快照。