为什么完全恢复模型是可用性组的一项要求？

Question

我们的所有生产数据库都采用简单恢复模型，对此我们感到非常高兴，因为它完全满足我们的 RPO 和 RTO。

现在我们想为我们的数据库实施 AG DR 解决方案，我们发现完全恢复模型是一个要求。

我的问题是为什么？从理论上讲，AG 或其他 SQL Server DR 解决方案（日志传送、数据库镜像）不应该与简单恢复模型一起使用是否存在任何技术原因？

Answer 1

如果在简单恢复中允许使用 DR 技术，那么 HA 就没有任何意义。事务日志是时间点恢复的必要条件。事务日志是 DR 技术用来重放在 Logshipped/mirrored 数据库上完成的事务的内容，并且由于在简单恢复中无法进行日志备份，因此您也无法在简单恢复中配置 HA/DR。在镜像中，将事务日志块更改发送到镜像服务器；在日志传送中，发送事务日志备份。因此，您可以看到 Mirroring/Logshipping/AlwayON 工作的基本概念是事务日志。

事务日志是数据库中最重要的部分——它是唯一可以保证在发生崩溃时描述对数据库所做的所有更改的地方。单个事务的日志记录由它们的 LSN 链接，几乎就像一个时间戳。此时间戳在内部用于链接各种事务并在 DR 服务器上重放。

DR 技术的主要目标是提供尽可能少的数据丢失，而这只有在事务日志在结构上保持一致时才能实现。在简单恢复中，事务日志在事务提交的那一刻就被截断，这意味着不需要这些信息，旧事务占用的空间现在将用于写入新事务。在这种情况下，旧信息将丢失。如果你想以某种方式得到它，你就不能。但在完全康复后，您可以做到。

Answer 2

这是因为这些方法依赖于事务日志，而事务日志本身仅在完整恢复模型中可靠。请完整阅读以下页面，因为其中有几个关于简单恢复和完全恢复之间差异的提示，以及为什么完全恢复对 DR 如此重要：

• 为什么事务日志不断增长或空间不足？

如果您想使用简单恢复，则只能通过进行完整备份和差异备份来实现 DR。在这种情况下，您将失去时间点恢复。

在某些情况下没问题，但我们不知道您的 RPO/RTO 是什么，也不知道您对数据丢失的容忍度、备份使用的磁盘空间等。您可以保持简单恢复模式并拥有相对可靠的 RPO，如果您想整天每分钟进行一次完整或差异备份。日志备份往往是实现最佳 RPO 的更快、更简单和更可靠的方法，我怀疑大多数人已经出于这个原因使用完全恢复。因此，对利用此模型的 AlwaysOn 和其他技术的要求通常不是绊脚石或令人头疼的问题。但它是一个硬性要求，原因相当无关紧要，但您可能会假设最基本的原因之一是，在简单恢复（甚至批量记录）中，您实际上可能会丢失永远不会发送到辅助服务器的事务，让它处于不一致的状态。

一切都是一种权衡。我的感觉是，很多人更喜欢简单的恢复，因为他们需要处理的关于事务日志的问题较少（但是，这些问题减少到 0 是一个神话）。就像很多事情一样 - 这种权衡非常有效，直到您真正遇到磁盘故障、人为错误或其他需要您恢复备份的中断。在完全恢复中，您被迫主动管理您的日志（否则它们会消耗您的磁盘），并且您始终可以在发生故障时到达特定时间点。简单来说，这在我看来是一个非常简单的方法，可以让您完全不注意备份。这只是一种意见，而不是技术事实，但它基于非常大的样本量。

Answer 3

假设我在恢复模型为 full 的数据库上运行以下查询：

INSERT INTO dbo.MY_FAVORITE_MSFT_EMPLOYEES WITH (TABLOCK)
SELECT 'SEAN GALLARDY' UNION ALL SELECT 'JOE SACK';

在完全恢复模式下，SQL Server 将写入插入到事务日志中的数据的一些表示。这允许辅助数据库上的重做线程读取事务日志并将主数据库上发生的事务应用到辅助数据库。这是唯一可能的，因为有一些“JOE SACK”和“SEAN GALLARDY”的表示写入了事务日志。

现在假设我在恢复模型为 simple 的数据库上运行相同的查询，并且我的插入符合最少日志记录：

INSERT INTO dbo.MY_FAVORITE_MSFT_EMPLOYEES WITH (TABLOCK)
SELECT 'SEAN GALLARDY' UNION ALL SELECT 'JOE SACK';

在这种情况下，SQL Server 可能不会写入插入事务日志的数据的完整表示。相反，它可能只记录页面 ID 或范围 ID。这篇博文很有启发性：

在最少日志记录下，SQL Server 不会记录单个行而只记录页面和范围分配。所以如果每个页面可以容纳 100 行，我们用 100 条日志记录交换 1 条日志记录，这是一个显着的改进。

了解更改内容的页面 ID 或范围 ID 足以让 SQL Server 根据需要执行回滚。但是，重做写入器将事务应用到辅助数据库的信息还不够。主备库需要逐字节拷贝，所以简单恢复模式与AG不兼容。