可用性组的恢复时间影响

Question

我们进行了不同类型的基本测试，并且 AlwaysOn 通过了许多测试。我们终于对 AlwaysOn 进行了大量的写测试，它给出了令人惊讶的结果。

实际的测试详细信息在这里，目标是查看 AlwaysOn 可用性组是否可以容纳高写入负载。

1. 我有两个虚拟机，每个虚拟机都运行在 8 个内核和 17GB 的 RAM 上，分配给 SQL Server。

2. 我们编写了一个脚本来生成相当不错的写 I/O（在 20 个线程中）。

3. 每个线程基本上将 24 MB 的数据插入到一个表中，然后在无限循环中删除。

在测试运行的 15 分钟内，自动故障转移的恢复时间估计达到了 12 分钟，这是非常糟糕的。我们尝试了故障转移来确认是否真的需要 12 分钟，大约需要 5 分钟，这仍然太高了。此外，如果我们继续测试三个小时的恢复时间，ETA 几乎是 3 小时，并且在故障转移时需要几个小时才能恢复（显然，如果是集群故障转移，情况就不应该如此，因为所有事务都是已提交的事务）。

所以有几件事..

很明显，synchronous次要副本无法跟上主要正在生成的负载（即使两台机器的配置相同）。这样做的副作用是主日志将继续增长（即使我们进行日志备份，它也无法截断日志）。

我们知道辅助节点每 4 个 CPU 核心使用一个线程来执行重做，这看起来是一个明显的限制。如果主节点运行 100 个线程来生成负载，那么辅助节点无论如何都不能使用那么多线程。

此外，主要在内存中执行其所有事务，并将实际数据文件写入到检查点。但是，secondary 似乎必须从物理日志驱动器读取所有事务并重做。辅助日志池应该使这个过程更快？但是在这种情况下它做得不好。

最后向 AlwaysOn 专家提问：

1. 有谁知道这个redo过程究竟是如何发生的？
   • 它被缓存了吗？
   • 是否涉及缓冲池？

2. 二级是否使用日志池来缓存日志条目以进行重做？

3. 日志池的大小是多少？它可以增长到最大可用内存吗？

4. 当重做发生时，重做线程将页面读取到缓冲池并像正常事务一样维护它们？

5. 如果二级不能跟上怎么来AlwaysOn文章说恢复时间是几秒？

这使得可用性组的高可用性部分存在问题，因为这些恢复时间是不可持续的。

---

[由提问者编辑]澄清，由于人们似乎认为这已得到回答，因此主服务器上的事务确实得到了确认（即日志已硬化），因为辅助服务器的状态始终是“同步的”。所以日志的硬化不是问题。因此，在故障转移时永远需要重做过程。这意味着对于生成日志 > 重做线程容量的任何负载，AlwaysOn 将始终比没有它需要更长的时间来恢复。

Answer 1

很明显，同步次要副本无法跟上正在生成的负载（即使两台机器的配置相同）。这样做的副作用是主日志将继续增长（即使我们进行日志备份，它也无法截断日志）

在同步镜像中/始终，辅助节点必须在允许主节点的提交继续之前确认它已硬化（写入磁盘）日志。然后主节点可以根据需要自由截断/重用它自己的日志。如果您无法截断主节点，则意味着辅助节点未同步。这将表明将日志传送到辅助节点并将其写入磁盘的能力存在问题。两个明显的瓶颈是网络速度和辅助的日志文件存储。两者都易于测量和诊断，因为它们是直接的USE（利用率、饱和度、错误）操作系统级别指标。

请注意，我从未提到过恢复（二级的重做）。如果问题确实是辅助节点无法同步，那么重做在这里没有任何实际作用。