通过

在停机时间和数据丢失最少的情况下升级和更新可用性组服务器

  • 项目

将服务器实例从 SQL Server 2012 更新或升级到 Service Pack 或更高版本时，您可以通过执行顺序更新或升级将可用性组的停机时间降低到一个手动故障转移所需的时间。 对于升级 SQL Server 版本，它称为“滚动升级”；对于使用修复程序或 Service Pack 更新当前 SQL Server 版本，它称为“滚动更新”。

此主题仅讨论 SQL Server 升级/更新。 对于正在运行高可用的 SQL Server 实例的与操作系统相关的升级/更新，请参阅针对操作系统升级的 AlwaysOn 可用性组的跨群集迁移

AlwaysOn 可用性组的滚动升级/更新最佳做法

在执行服务器升级/更新时应遵循以下最佳做法以尽量减小可用性组的停机时间和数据丢失量：

  • 在启动滚动升级/更新前，

    • 至少对一个同步提交副本执行实际手动故障转移

    • 通过对每个可用性数据库执行完整数据库备份来保护您的数据

    • 在每个可用性数据库上运行 DBCC CHECKDB

  • 始终首先升级/更新远程辅助副本节点，然后升级/更新本地辅助副本节点，最后升级/更新主副本节点。

  • 无法在正在升级的数据库中执行备份。 在升级辅助副本之前，请将自动备份首选项配置为仅在主副本上运行备份。 在升级主副本之前，请修改此设置以便仅在辅助副本上运行备份。

  • 要防止可用性组在升级/更新过程中执行意外的故障转移，请在开始前从所有同步提交副本中删除可用性故障转移。

  • 在没有首先将可用性组故障转移到具有辅助副本的已升级节点上前，不要升级主副本节点。 否则，在主副本上进行升级/更新期间，客户端应用程序的停机时间可能更长。

  • 始终将可用性组故障转移到同步提交的辅助副本节点。 如果故障转移到异步提交的辅助副本，数据库将发生数据丢失，且数据移动自动挂起，直到您手动恢复数据移动。

  • 在没有升级/更新任何其他辅助副本节点前，不要升级/更新主副本节点。 已升级的主副本不再将日志传送到尚未升级到同一版本的任何辅助副本。 在挂起到辅助副本的数据移动时，对于该副本无法进行自动故障转移，且您的可用性数据库很可能发生数据丢失。

  • 在故障转移可用性组前，请验证故障转移目标的同步状态为 SYNCHRONIZED。

滚动升级/更新过程

实际上，确切的过程取决于一些因素，如可用性组的部署拓扑和每个副本的提交模式。 但是在最简单的方案中，滚动升级/更新是涉及以下步骤的多阶段过程：

HADR 方案中的可用性组升级

  1. 在所有同步提交的副本上删除自动故障转移

  2. 升级/更新运行异步提交辅助副本的所有远程服务器实例

  3. 升级/更新当前未运行主副本的所有本地服务器实例

  4. 将可用性组手动故障转移到同步提交的辅助副本

  5. 升级/更新以前承载主副本的服务器实例

  6. 根据需要配置自动故障转移伙伴

如果需要，您可以执行额外的手动故障转移以将可用性组恢复到原始配置。

具有一个远程辅助副本的可用性组

如果您仅为灾难恢复部署了一个可用性组，可能需要将该可用性组故障转移到异步提交的辅助副本。 这样的配置如下图所示：

DR 方案中的可用性组升级

在此情况下，在滚动升级/更新期间必须将可用性组故障转移到异步提交的辅助副本。 要防止数据丢失，请在故障转移可用性组前将提交模式更改为同步提交并等待辅助副本同步。 因此，滚动升级/更新过程可能如下所示：

  1. 升级/更新远程服务器

  2. 将提交模式更改为同步提交

  3. 等待直到同步状态为 SYNCHRONIZED

  4. 将可用性组故障转移到远程站点

  5. 升级/更新本地（主站点）服务器

  6. 将可用性组故障转移到主站点

  7. 将提交模式更改为异步提交

因为同步提交模式不是用于数据同步到远程站点的建议设置，客户端应用程序可能发现在设置更改后，数据库延迟时间立即增加。 此外，执行故障转移将导致丢弃所有未确认的日志消息。 由于两个站点之间的高网络延迟，丢弃的日志消息量可能很大，这导致客户端经历大量事务失败。 您可以通过执行以下操作之一来尽量降低对客户端应用程序的影响：

  • 在低客户端流量期间认真选择一个维护窗口

  • 在主站点上升级/更新 SQL Server 时，将可用性模式改回异步提交，在准备好再次故障转移到主站点时再将其恢复为同步提交

具有故障转移群集实例节点的可用性组

如果可用性组包含故障转移群集实例 (FCI) 节点，您应在升级/更新活动节点前升级/更新不活动的节点。 下图显示一个常见的可用性组方案（它包含 FCI 用于本地高可用性且用于远程灾难恢复的 FCI 之间采用异步提交模式）和升级顺序。

具有 FCI 的可用性组升级

  1. 升级/更新 REMOTE2

  2. 将 FCI2 故障转移到 REMOTE2

  3. 升级/更新 REMOTE1

  4. 升级/更新 PRIMARY2

  5. 将 FCI1 故障转移到 PRIMARY2

  6. 升级/更新 PRIMARY1

升级/更新具有多个可用性组的 SQL Server 实例

如果您正在单独的服务器节点（活动/活动配置）上运行包含主副本的多个可用性组，则升级/更新路径涉及更多故障转移步骤以在过程中保持高可用性。 假定您正在三个服务器节点上运行三个可用性组（如下表所示），所有辅助副本正在同步提交模式下运行。

可用性组

Node1

Node2

Node3

AG1

主

AG2

主

AG3

主

按以下顺序执行负载平衡的滚动升级/更新可能在您的情况下是合适的：

  1. 将 AG2 故障转移到 Node3（以空出 Node2）

  2. 升级/更新 Node2

  3. 将 AG1 故障转移到 Node2（以空出 Node1）

  4. 升级/更新 Node1

  5. 将 AG2 和 AG3 故障转移到 Node1（以空出 Node3）

  6. 升级/更新 Node3

  7. 将 AG3 故障转移到 Node3

此升级/更新顺序具有每个可用性组小于两个故障转移的平均停机时间。 最终配置如下表所示。

可用性组

Node1

Node2

Node3

AG1

主

AG2

主

AG3

主

根据您的特定实现，您的升级/更新路径可能不同，客户端应用程序经历的停机时间也可能不同。