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

Question

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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