升级可用性组副本

适用于：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当更新过程中没有相应的同步次要副本数时，主副本可能无法进行读/写。

将辅助副本 (replica) 就地升级到较新版本的 SQL Server 时，可用性组中的数据库将保持“正在同步/正在恢复”或“已同步/在恢复中”状态，直到手动故障转移可用性组，从而完成恢复并升级数据库。 升级的主副本无法再将日志寄送到任何较低版本的次要副本和数据移动停止，该副本不会发生自动故障转移，并且可用性数据库容易受到数据丢失的影响。 升级旧主数据库后，可能需要恢复同步。 建议先升级所有次要副本，然后再使用新版本故障转移到副本。 这样，就可以选择在数据库（es）升级到新格式后执行故障转移。

具有一个远程次要副本的 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（主动/主动配置），升级路径涉及更多故障转移步骤，以在进程中保留高可用性。 假设你在三个服务器节点上运行三个 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。

如果每个可用性组中存在第三个副本，则会在之前和NODE1\SQLAG之前NODE3\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