HADR可用性组长同步时间

Question

我有以下问题/挑战：

我们使用几个可用性组操作一个HA集群。

为了充分利用负载平衡，我将SQL选择重定向到辅助主机，这样主主机就不会额外加载。

这也是完美和超快的工作。

但是..。

如果我从应用程序中执行插入、更新或其他dml操作，并且在选择结果之后，新更新的条目将无法正确显示。

我怀疑二级复制的速度太慢了。

这可能是因为加强日志的延迟吗？

我怎么才能完全加快速度呢？

Answer 1

如果我从应用程序中执行插入、更新或其他dml操作，并且在选择结果之后，新更新的条目将无法正确显示。

这是正确的。如果需要最最新的数据，则需要查询主副本。这也适用于您使用的任何形式的事务性复制(严格的TR，P2P)。

我怀疑二级复制的速度太慢了。

会慢点吗？也许吧。然而，“通过设计”，无论人们是否喜欢这种设计，在这个过程中都会有延迟。也许有一天我会写一些东西，但在那之前，我一直是更新文档。

具体而言，与上述问题相关的锚是在不久前为回答这些问题而设置的。对于一种新类型的同步，我们有几个请求，即“在事务在/all辅助副本上重放之前不要移动”。您可以想象到，在任何云环境中，以及我所看到的大多数(如果不是全部的话)prem环境中，都会有大量的延迟，比如使用慢速的SAN，不太吸引人的网络，以及cpu/内存的不足。

如果您的只读工作负载可以容忍某些数据延迟，则实现对辅助副本的只读访问非常有用。在数据延迟不可接受的情况下，考虑对主副本运行只读工作负载。这可能是因为加强日志的延迟吗？

耸肩。有可能。

这里有很多因素。简化的工作流概述是@Aaron Bertrand在他的评论中包含的第一个链接(这是一个很好的链接)。硬化和重做是解耦的。这也没有考虑到SQL Server、load、硬件、串行/并行重做等版本，因此需要捕获数据，这对于问答站点来说也是非常重要的。此外，您还需要剪切数据，这也是不平凡的，这就是为什么在SSMS中没有一个简单的右键菜单来实现它。

我怎么才能完全加快速度呢？

接受这是不可能“完全”加快它。根据事务的大小和我之前回避过的各种其他项目，您可能能够在10s的毫秒内重做并看到它，但它不会是即时的。