升级可用性组副本

适用于：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 故障转移到同步提交的次要副本实例。 如果故障转移到异步提交的次要副本实例，数据库易丢失数据，且数据移动会自动暂停，直到手动恢复数据移动为止。

• 在升级或更新任何其他的次要副本实例之前，不要升级主要副本实例。 已升级的主要副本不再将日志传送到 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 故障转移到异步提交的次要副本。 为防止数据丢失，请将提交模式更改为同步提交，并在将可用性组故障转移之前等待次要副本完成同步。 因此，滚动升级过程可能如下所示：

1. 升级远程站点上的辅助副本实例。
2. 将提交模式更改为同步提交。
3. 等待，直到同步状态为 SYNCHRONIZED。
4. 将可用性组故障转移到远程站点的次要副本。
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，其中所有副本都处于同步提交模式，如下表所示：

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

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