升级可用性组副本

适用于：SQL Server

在将承载 Always On 可用性组 (AG) 的 SQL Server 实例升级到新的 SQL Server 版本、安装新的 SQL Server 服务包或累积更新，或者安装新的 Windows 服务包或累积更新时，可以通过执行滚动升级，将主副本的停机时间缩短到仅一次手动故障转移所需的时间（如果要故障回复到原始主副本，则需要进行两次手动故障转移）。

在升级过程中，辅助副本将无法用于故障转移或只读操作。升级完成后，辅助副本可能需要一些时间才能赶上主副本节点，具体取决于主副本节点上的活动量（因此预计会出现较高的网络流量）。

另请注意，在首次故障转移到运行较新版本 SQL Server 的次要副本后，该 AG 中的数据库将经历升级过程，以将其升级到最新版本。 在此期间这些数据库都没有可读副本。 初始故障转移后的停机时间取决于 AG 中的数据库数量。 若计划故障回复至原始的主副本，那么在故障回复时将不会重复此步骤。

先决条件

开始之前，请仔细阅读以下重要信息：

• 支持的版本和版本升级：验证是否可以从 Windows 操作系统版本和 SQL Server 版本升级到最新版本的 SQL Server。 例如，如果直接从 SQL Server 2005 实例升级，则会升级数据库兼容性级别。

• 选择数据库引擎升级方法：要按正确顺序升级，请检查支持的版本和版本升级以及环境中安装的其他组件，并据此选择适当的升级方法和步骤。

• 规划和测试数据库引擎升级计划：查看发行说明和已知升级问题、预升级清单，并开发和测试升级计划。

• 安装 SQL Server 的硬件和软件要求：查看安装 SQL Server 的软件要求。 如果需要其他软件，则应在升级过程开始之前在每个节点上安装该软件，从而最大程度减少故障时间。

• 检查更改数据捕获或复制是否用于任何 AG 数据库：如果 AG 中的任何数据库已启用更改数据捕获 (CDC)，请完成这些操作。

可用性组的滚动升级基础知识

在执行服务器升级或更新时请按照以下准则操作，以最大程度减少 AG 的故障时间和数据丢失量：

• 在开始滚动升级之前：

  • 在至少一个同步提交副本实例上执行一次手动故障转移演练。

  • 通过在每个可用性数据库上执行完整数据库备份来保护数据。

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

• 始终首先升级远程次要副本实例，然后升级本地次要副本实例，最后升级主要副本实例。

• 无法在正在升级的数据库中执行备份。 在升级辅助副本之前，请将自动备份首选项配置为仅在主副本上运行备份。 在版本升级期间，任何副本都不可读取并且不能用于备份。 在非版本升级期间，可以将自动备份配置为在升级主副本之前在次要副本上运行。

• 在版本升级期间，在升级可读次要副本之后，以及在主要副本故障转移到已更新的次要副本或者升级主要副本之前，无法读取可读的次要副本。

• 若要防止 AG 在升级过程中意外故障转移，请先从所有同步提交副本中删除自动故障转移，然后再开始。

• 在先将 AG 故障转移到已升级的辅助副本所在实例之前，不要升级主副本实例。 否则，在主副本实例的升级过程中，客户端应用程序可能会长时间停机。

• 始终将 AG 故障转移到同步提交的次要副本实例。 如果故障转移到异步提交的次要副本实例，数据库存在数据丢失风险，并且数据移动会自动暂停，直到你手动恢复数据移动为止。

• 在升级或更新任何其他的次要副本实例之前，不要升级主要副本实例。 已升级的主要副本不再将日志传送到 SQL Server 实例尚未升级到同一版本的任何次要副本。 当到辅助副本的数据移动被暂停时，该副本将无法进行自动故障转移，并且您的可用性数据库将面临数据丢失的风险。 这也适用于滚动升级期间，你将从旧主数据库手动故障转移到新的主数据库。 因此，升级旧主数据库后，可能需要恢复同步。

• 在对 AG 执行故障转移之前，请验证故障转移目标的同步状态为 SYNCHRONIZED。

  警告

  将新实例或新版本的 SQL Server 安装到安装了较旧版本的 SQL Server 的服务器时，可能会无意中 导致由旧版 SQL Server 托管的任何可用性组发生中断。 这是因为在安装 SQL Server 实例或版本期间，SQL Server 高可用性模块 （RHS.EXE） 会升级。 这会导致服务器上主要角色中的现有可用性组暂时中断。 因此，强烈建议在将较新版本的 SQL Server 安装到已托管具有可用性组的较旧版本的 SQL Server 的系统时执行以下作之一：

  • 在维护时段内安装新版本的 SQL Server。

  • 将可用性组故障转移到次要副本，以便在安装新 SQL Server 实例期间它不处于主副本角色。

滚动升级过程

实际上，具体过程取决于诸多因素，例如你的 AG 的部署拓扑结构以及每个副本的提交模式。 但在最简单的方案中，滚动升级是一个多阶段过程，其最简单的形式涉及以下步骤：

1. 在所有同步提交的副本上删除自动故障转移
2. 升级所有异步提交辅助副本实例。
3. 升级所有远程同步提交的次要副本实例。
4. 升级所有本地同步提交的次要副本实例。
5. 手动将 AG 故障转移到（新近升级的）本地同步提交辅助副本。
6. 升级或更新以前承载主要副本的本地副本实例。
7. 根据需要配置自动故障转移伙伴。

如果需要，可以再执行一次手动故障转移，将 AG 恢复到其原始配置。

升级同步提交副本并将其脱机不会延迟主副本上的事务。 次要副本断开连接后，事务可在主副本上提交，而无需等待次要副本上的日志完成硬化。 如果 REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT 设置为 1 或 2 之一，则在更新过程中，如果没有足够数量的对应同步次要副本可用，主副本可能无法进行读写操作。

将辅助副本就地升级到 SQL Server 的较新版本时，可用性组中的数据库会一直保持“正在同步 / 正在恢复”或“已同步 / 正在恢复”状态，直到手动将可用性组故障转移，才会完成恢复并升级数据库。 升级后的主副本无法再将日志传送到任何较低版本的次要副本，数据移动将停止，该副本也无法进行自动故障转移，并且你的可用性数据库将面临数据丢失风险。 升级旧主数据库后，可能需要恢复同步。 我们建议先升级所有次要副本，然后再故障转移到采用新版本的副本。 这样，您可以选择在一个或多个数据库升级到新格式后执行故障转移。

具有一个远程次要副本的 AG

如果 AG 仅用于灾难恢复部署，则可能需要将 AG 故障转移至异步提交辅助副本。 下图演示了此类配置：

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

1. 升级远程站点上的辅助副本实例。
2. 将提交模式更改为同步提交。
3. 等待，直到同步状态为 SYNCHRONIZED。
4. 将 AG 故障转移至远程站点上的次要副本。
5. 升级或更新本地（主站点）副本实例。
6. 将 AG 故障转移回主站点。
7. 将提交模式更改为异步提交。

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

• 在低客户端流量期间，请仔细选择维护时段。

• 在主站点上升级或更新 SQL Server 时，请将可用性模式改回异步提交；然后在准备再次故障转移回主站点时，再改回同步提交。

包含故障转移群集实例节点的 AG

如果 AG 包含故障转移群集实例 (FCI) 节点，应先升级不活动的节点，再升级活动的节点。 下图说明了一个常见的 AG 场景：使用 FCI 实现本地高可用性，并在 FCI 之间采用异步提交以实现远程灾难恢复，以及升级顺序。

1. 升级或更新 REMOTE2
2. 将 FCI2 故障转移到 REMOTE2
3. 升级或更新 REMOTE1
4. 升级或更新 PRIMARY2
5. 将 FCI1 故障转移到 PRIMARY2
6. 升级或更新 PRIMARY1

升级或更新包含多个 AG 的 SQL Server 实例

如果你运行了多个 AG，且它们的主副本分别位于不同的服务器节点上（Active/Active 配置），则升级过程需要执行更多次故障转移，以在整个过程中保持高可用性。 假设你在三个服务器节点上运行三个 AG，其中所有副本都处于同步提交模式，如下表所示：

在您的情况下，按以下顺序执行负载平衡滚动升级可能比较合适：

1. 将 AG2 故障转移到 Node3（以释放 Node2）
2. 升级或更新 Node2
3. 将 AG1 故障转移到 Node2（以空出 Node1）
4. 升级或更新 Node1
5. 将 AG2 和 AG3 都故障转移到 Node1（以释放 Node3）
6. 升级或更新 Node3
7. 将 AG3 故障转移到 Node3

此升级顺序的平均停机时间为每个 AG 少于两次故障转移。 最终配置如下表所示。

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

分布式可用性组的滚动升级

要执行分布式可用性组的滚动升级，首先升级所有次要副本。 接下来，对转发器执行故障转移，并升级第二个可用性组中最后一个剩余实例。 升级所有其他副本后，故障转移全局主副本并升级第一个可用性组的最后一个剩余实例。 后面部分提供了包含步骤的详细关系图。

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

升级分布式可用性组的一般步骤

1. 备份所有数据库，包括系统数据库和参与可用性组的数据库。
2. 升级并重启第二个可用性组（下游）的所有次要副本。
3. 升级并重启第一个可用性组（上游）的所有次要副本。
4. 将转发器主副本故障转移到辅助可用性组中已升级的辅助副本。
5. 等待数据同步。 数据库在所有同步提交副本上都应显示为“已同步”状态，且全局主副本应与转发器保持同步。
6. 升级并重启第二个可用性组的最后一个剩余实例。
7. 将全局主副本故障转移到第一个可用性组中已升级的辅助副本。
8. 升级主可用性组中仅剩的最后一个实例。
9. 重启新升级的服务器。
10. （可选）将两个可用性组都故障转移回各自原始的主副本。

分布式可用性组的滚动升级的示例图

此图中实例升级的步骤如下：

1. 备份所有数据库，其中包括系统数据库，以及参与可用性组的数据库。
2. 升级 NODE4\SQLAG（AG2 的次要副本）并重启服务器。
3. 升级 NODE2\SQLAG（AG1 的次要副本）并重启服务器。
4. 将 AG2 从 NODE3\SQLAG 故障转移至 NODE4\SQLAG。
5. 升级 NODE3\SQLAG 并重启服务器。
6. 将 AG1 从 NODE1\SQLAG 故障转移至 NODE2\SQLAG。
7. 升级 NODE1\SQLAG 并重启服务器。
8. （可选）故障回复到原始主要副本。
   1. 将 AG2 从 NODE4\SQLAG 故障转移回 NODE3\SQLAG。
   2. 将 AG1 从 NODE2\SQLAG 切换回 NODE1\SQLAG。

如果每个可用性组中都存在第三个副本，则应先升级该副本，然后再升级 NODE3\SQLAG 和 NODE1\SQLAG。

更改数据捕获或复制的特殊步骤

视所应用的更新而定，对于已启用变更数据捕获或复制的 AG 副本数据库，可能需要执行其他步骤。 请参阅更新的发行说明以确定是否需要执行以下步骤：

1. 升级每个次要副本。

2. 在所有次要副本均已升级后，对 AG 执行故障转移，切换到已升级的实例。

3. 在托管主要副本的实例上运行下列 Transact-SQL：

   EXECUTE [master].[sys].[sp_vupgrade_replication];
   

   注意

   此命令可能需要几分钟才能运行。 如果使用 SQL Server 2019 CU1 或更高版本，请跳过此步骤。 若要了解详细信息，请查看 KB4530283。

4. 升级原本作为主副本的实例。

有关背景信息，请参阅 CDC 功能在升级到最新 CU 后可能会中断。

相关内容

• 使用安装向导升级 SQL Server（安装程序）
• 使用命令提示符在 Windows 上安装和配置 SQL Server