辅助副本 AlwaysOn AG 上的检查点

Question

设置

3 节点 Alwayson 群集 - 1 个同步和 1 个异步辅助副本 - SQL Server 2012

情况

从异步辅助副本读取时，我们正在目睹 PageIOLatches。这主要是由于 SAN 的吞吐量受到限制造成的。托管合作伙伴告诉我们，由于硬件限制，无法立即缓解此限制。
主副本和同步副本使用具有更高吞吐量的其他 SAN。虽然这种情况远非理想，但这是一个很快就会解决的暂时情况，不是我的问题。

在调查 IO 等待时，我们注意到这些与检查点页数/秒的增加同时发生。

我的印象是检查点不会出现在 AG 中的辅助副本上，就像这里讨论的那样。

为了验证这种行为，我设置了一个扩展事件来监视异步副本上的检查点事件。正如预期的那样，没有为此数据库捕获任何检查点，也没有从其他数据库中找到与该模式匹配的任何检查点。

接下来，我在主副本上创建了相同的扩展事件，并启动了一个 perfmon 来验证我们是否可以见证相同的行为。在这里，我们能够捕获（自动）检查点，它们大约发生。每分钟一次。这些检查点与辅助（和主要）副本上检查点页数/秒的增加同时发生。似乎正在主副本上生成检查点并在辅助副本上重做。这意味着检查点确实隐式发生在 AG 中的辅助副本上。

题

我的假设是否正确，在 AG 检查点是在主副本上生成并在所有辅助副本上重做？
因此，如果TARGET_RECOVERY_TIME未设置数据库，recovery interval主副本的设置将规定这些数据库的所有辅助副本上的检查点。

Answer 1

我的假设是否正确，即在 AG 中，在主副本上生成检查点并在所有辅助副本上重做？

是的。

ACHECKPOINT是一个记录操作，因为它是 SQL Server 恢复策略的一部分。当数据库启动时，它需要知道哪些修改的页面（在日志文件中）尚未写入数据文件 - 因此它可以在用户查询开始访问数据库之前重做这些更改。

我将从我的博客文章中获取一个屏幕截图，查看某些类型的日志记录活动：

如您所见，CHECKPOINT“开始”和“结束”被写入事务日志。

AG 工作方式的简化视图是，它们在所有辅助副本上重做来自主副本的日志条目。

因此，由于CHECKPOINTs 已被记录，因此它们将在辅助副本上重播。

作为旁注，John Eisbrener有用地指出，如果辅助副本上还有其他数据库，这些CHECKPOINT操作也将被此 Perfmon 跟踪记录下来。