通过

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

将服务器实例从 SQL Server 2012 更新或升级到 Service Pack 或更新版本时，可以通过执行顺序更新或升级，将可用性组的停机时间减少到单个手动故障转移。 对于升级 SQL Server 版本，称为滚动升级;若要使用修补程序或服务包更新当前 SQL Server 版本，则称为滚动更新。

本主题仅将讨论限制为 SQL Server 升级/更新。 有关运行高可用性 SQL Server 实例的操作系统相关的升级/更新，请参阅 适用于操作系统升级的 AlwaysOn 可用性组的跨群集迁移

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

在执行服务器升级/更新时，应遵守以下最佳做法，以最大程度地减少可用性组的停机时间和数据丢失：

  • 在开始滚动升级/更新之前，

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

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

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

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

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

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

  • 在先将可用性组故障转移到具有辅助副本的升级节点之前，请勿升级主副本节点。 否则，在主副本的升级/更新期间，客户端应用程序可能会长时间停机。

  • 始终将可用性组故障转移到同步提交辅助副本节点。 如果发生故障转移到异步提交次要副本，数据库将遭受数据丢失，数据移动会自动暂停，直到您手动恢复为止。

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

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

滚动升级/更新过程

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

在 HADR 方案中升级可用性组

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

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

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

  4. 手动将 SQL Server 可用性组故障转移到同步提交的次要副本

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

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

如有必要，可以手动执行故障转移，将可用性组恢复到其原始配置。

具有一个远程辅助复制品的可用性组

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

DR 情景中的可用性组升级

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

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

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

  3. 等待同步状态达到“已同步”状态

  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 主要

根据具体的实现，升级/更新路径可能会有所不同，客户端应用程序体验的停机时间也可能有所不同。