4

我们在使用 SQL Server 进行横向扩展时遇到问题。这主要是因为几个原因：1）数据结构设计不佳，2）繁重的工作和业务/处理逻辑都是在 T-SQL 中完成的。我们聘请了一位来自 Redmond 的 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 存储过程以仅执行基于集合的操作，因为它也应该如此。

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

谢谢。

4

1 回答 1

5

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

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

我建议您搜索许多描述关于（更流行的）MySQL 主-主部署的陷阱和警告的博客和文章（例如，如果您必须部署多主复制，请先阅读此内容），自己判断问题是否存在值得。

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

于 2012-11-21T23:09:36.847 回答