4

我的 Web 应用程序针对 SQL Server 2008 使用 ADO.NET。数据库写入发生在主（发布者）数据库上，但读取在主数据库和辅助（订阅者）数据库之间进行负载平衡。我们使用 SQL Server 的内置事务复制来使辅助服务器保持最新。大多数时候，几秒钟的延迟不是问题。

但是，我确实有一个案例，我想阻止直到事务在辅助站点提交。阻止几秒钟是可以的，但将陈旧的页面返回给用户则不行。ADO.NET 或 TSQL 中是否有任何方法可以指定我要等待复制完成？或者我可以从发布者那里检查事务的复制状态，而无需手动连接到辅助服务器。

[编辑] 99.9% 的时间，订阅者中的数据“足够新鲜”。但是有一种操作会使它无效。我不能每次都从出版商那里读到它，因为它已经失效了。如果我不能在事务复制下解决这个问题，你能建议一个替代架构吗？

4

2 回答 2

2

SQL Server 没有这样的解决方案，但这是我在其他环境中解决它的方法。

在您的应用程序中使用三个单独的连接字符串，并根据您的查询需要选择正确的一个：

  • 实时 - 直接指向一台主服务器。所有的写入都到这个连接字符串，只有最关键的读取到这里。
  • 近实时 - 指向负载平衡的订阅者池。这里没有写，只有读。用于绝大多数 OLTP 读取。
  • 延迟报告——在您现在的环境中，它将指向同一个负载平衡的订阅者池，但在未来，您可以使用日志传送之类的技术来延迟 8-24 小时拥有一个服务器池。这些扩展非常好，但数据远远落后。它非常适合报告、搜索、长期历史记录和其他非实时需求。

如果您从一开始就将您的应用程序设计为使用这 3 个连接字符串，那么缩放会容易得多，尤其是在您遇到的情况下。

于 2010-01-23T14:37:31.843 回答
0

您正在描述同步镜像情况。根据定义，复制不能支持您的要求。复制必须等待事务提交，然后才能从日志中读取它并将其交付给分发器，然后再从那里交付给订阅者，这意味着根据定义，复制有一个数据不同步的机会窗口。

如果您需要操作来读取数据的权威副本，那么您应该在客户端做出决定，并确保在这种情况下从发布者那里读取。

虽然您可以在理论上验证某个事务是否已分发给订阅者，但您的设计不应以此为基础。事务复制在设计上没有延迟保证，因此您不能依赖“完美的一天”操作模式。

于 2010-01-15T00:41:18.210 回答