等待 ADO.NET 或 TSQL 中的事务复制

Question

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

但是，我确实有一种情况，我想阻止直到事务在辅助站点提交。阻塞几秒钟是可以的，但向用户返回过时的页面则不行。ADO.NET 或 TSQL 中有什么方法可以指定我要等待复制完成吗？或者我可以从发布者处检查事务的复制状态，而无需手动连接到辅助服务器。

编辑] 99.9％的时间，订户中的数据“足够新鲜”。但有一项操作会使其失效。我不能每次都从出版商那里读取它，以防它变得无效。如果我无法在事务复制下解决这个问题，你能建议一个替代架构吗？

Answer 1

SQL Server 没有这样的解决方案，但以下是我在其他环境中解决该问题的方法。

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

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

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

Answer 2

您所描述的同步镜像的情况。复制无法根据定义，支持你的要求。复制的必须的等待一个事务从日志读取它，并将其输送到所述分配器并从那里到订户，这意味着根据定义的复制有机会数据要出的一个窗口之前提交同步。

如果您有要求的操作来读取数据的authorithative副本，那么你应该在客户端decission，并确保你在这种情况下发行人阅读。

虽然你可以在threory，验证阉一定的交易分发给用户或没有，你不应该立足于它设计。事务复制不作任何等待时间保证，通过设计，所以你不能依赖于一个“完美的一天”的操作模式。