升级 AlwaysOn 可用性组副本实例Upgrading Always On Availability Group Replica Instances

适用于:Applies to: 是SQL ServerSQL Server(所有支持的版本)yesSQL ServerSQL Server (all supported versions) 适用于:Applies to: 是SQL ServerSQL Server(所有支持的版本)yesSQL ServerSQL Server (all supported versions)

在将托管 Always On 可用性组 (AG) 的 SQL ServerSQL Server 实例升级到新的 SQL Server 2019 (15.x)SQL Server 2019 (15.x) 版本、新的 SQL ServerSQL Server 服务包或积累更新,或在安装到新的 Windows 服务包或积累更新时,可以通过执行滚动升级将主要副本的故障时间降低到仅需一次手动故障转移(或者如果无法故障转移回原始的主要副本,则需两次手动故障转移)。When upgrading a SQL ServerSQL Server instance that hosts an Always On Availability Group (AG) to a new SQL Server 2019 (15.x)SQL Server 2019 (15.x) version, to a new SQL ServerSQL Server service pack or cumulative update, or when installing to a new Windows service pack or cumulative update, you can reduce downtime for the primary replica to only a single manual failover by performing a rolling upgrade (or two manual failovers if failing back to the original primary). 在升级过程中,次要副本将不可用于故障转移或只读操作,并且在升级之后,次要副本可能需要花费一些时间来与主要副本节点保持同步,具体时间取决于主要副本节点上的活动量(因此需要较高的网络流量)。During the upgrade process, a secondary replica will not be available for failover or for read-only operations, and after the upgrade, it may take some time for the secondary replica to catch up with the primary replica node depending upon the volume of activity on the primary replica node (so expect high network traffic). 另请注意,初始故障转移到运行较新版本 SQL Server 的次要副本后,可用性组中的数据库会运行升级进程,将其升级到最新版本。Also be aware that after the initial failover to a secondary replica running a newer version of SQL Server, the databases in that Availability Group will run through an upgrade process to bring them to the latest version. 在此期间这些数据库都没有可读副本。During this time, there will be no readable replicas for any of these databases. 初始故障转移之后的故障时间取决于可用性组中的数据库数量。Downtime after the initial failover will depend on the number of databases in the Availability Group. 若计划故障回复至原始的主副本,那么在故障回复时将不会重复此步骤。If you plan on failing back to the original primary, this step will not be repeated when you fail back.

备注

本文仅讨论 SQL Server 本身的升级。This article limits the discussion to the upgrade of SQL Server itself. 它不涵盖升级包含 Windows Server 故障转移群集 (WSFC) 的操作系统。It does not cover upgrading the operating system containing the Windows Server Failover Cluster (WSFC). Windows Server 2012 R2 之前的操作系统不支持升级承载故障转移群集的 Windows 操作系统。Upgrading the Windows operating system hosting the failover cluster is not supported for operating systems before Windows Server 2012 R2. 若要升级在 Windows Server 2012 R2 上运行的群集节点,请参阅群集操作系统滚动升级To upgrade a cluster node running on Windows Server 2012 R2, see Cluster Operating System Rolling Upgrade.

先决条件Prerequisites

开始之前,请仔细阅读以下重要信息:Before you begin, review the following important information:

备注

在滚动升级之外,不支持在同一 AG 中混合使用 SQL Server 实例版本,并且不应该长时间保持该状态,因为升级应该快速进行。Mixing versions of SQL Server instances in the same AG is not supported outside of a rolling upgrade and should not exist in that state for extended periods of time as the upgrade should take place quickly. 升级 SQL Server 2016 及更高版本的其他选项是使用分布式可用性组。The other option for upgrading SQL Server 2016 and later is through the use of a distributed availability group.

Always On AG 的滚动升级基础Rolling Upgrade Basics for Always On AGs

在执行服务器升级或更新时请按照以下准则操作,以最大程度减少 AG 的故障时间和数据丢失量:Observe the following guidelines when performing server upgrades or updates in order to minimize downtime and data loss for your AGs:

  • 在开始滚动升级前,Before starting the rolling upgrade,

    • 至少对一个同步提交副本实例执行实际手动故障转移Perform a practice manual failover on at least one of your synchronous-commit replica instances

    • 通过对每个可用性数据库执行完整数据库备份来保护您的数据Protect your data by performing a full database backup on every availability database

    • 在每个可用性数据库上运行 DBCC CHECKDBRun DBCC CHECKDB on every availability database

  • 始终首先升级远程次要副本实例,然后升级本地次要副本实例,最后升级主要副本实例。Always upgrade the remote secondary replica instances first, then local secondary replica instances next, and the primary replica instance last.

  • 无法在正在升级的数据库中执行备份。Backups cannot occur on a database that is in the process of being upgraded. 在升级辅助副本之前,请将自动备份首选项配置为仅在主副本上运行备份。Prior to upgrading the secondary replicas, configure the automated backup preference to run backups only on the primary replica. 在版本升级期间,任何副本都不可读取并且不能用于备份。During a version upgrade, no replicas are readable or available for backups. 在非版本升级期间,可以先配置要在次要副本上运行的自动备份,再升级主要副本。During a non-version upgrade, you can configure automated backups to run on secondary replicas prior to upgrading the primary replica.

  • 在版本升级期间,在升级可读次要副本之后,以及在主要副本故障转移到已更新的次要副本或者升级主要副本之前,无法读取可读的次要副本。During a version upgrade, readable secondaries cannot be read after an upgrade of the readable secondary and before either the primary replica is failed over to an upgraded secondary or the primary replica is upgraded.

  • 要防止 AG 在升级过程中执行意外的故障转移,请在开始前从所有同步提交副本中删除可用性故障转移。To prevent the AG from unintended failovers during the upgrade process, remove availability failover from all synchronous-commit replicas before you begin.

  • 在将 AG 故障转移到具有次要副本的已升级实例之前,不要升级主要副本实例。Do not upgrade the primary replica instance before failing over the AG to an upgraded instance with a secondary replica first. 否则,在主要副本实例上进行升级期间,客户端应用程序的故障时间可能更长。Otherwise, client applications may suffer extended downtime during the upgrade on the primary replica instance.

  • 始终将 AG 故障转移到同步提交的次要副本实例。Always fail over the AG to a synchronous-commit secondary replica instance. 如果故障转移到异步提交的次要副本实例,数据库易丢失数据,且数据移动会自动暂停,直到手动恢复数据移动为止。If you fail over to an asynchronous-commit secondary replica instance, the databases are vulnerable to data loss, and data movement is automatically suspended until you manually resume data movement.

  • 在升级或更新任何其他的次要副本实例之前,不要升级主要副本实例。Do not upgrade the primary replica instance before upgrading or updating any other secondary replica instance. 已升级的主要副本不再将日志传送到 SQL Server 2019 (15.x)SQL Server 2019 (15.x) 实例尚未升级到同一版本的任何次要副本。An upgraded primary replica can no longer ship logs to any secondary replica whose SQL Server 2019 (15.x)SQL Server 2019 (15.x) instance that has not yet been upgraded to the same version. 在挂起到辅助副本的数据移动时,对于该副本无法进行自动故障转移,且您的可用性数据库很可能发生数据丢失。When data movement to a secondary replica is suspended, no automatic failover can occur for that replica, and your availability databases are vulnerable to data loss. 这也适用于滚动升级过程,在此过程中将从旧的主要副本手动故障转移到新的主要副本。This also applies during a rolling upgrade where you manually failover from an old primary to a new primary. 因此,在升级旧的主要副本后,可能需要恢复同步。As such, after you upgrade the old primary, you may need to resume synchronization.

  • 在故障转移 AG 前,请验证故障转移目标的同步状态为 SYNCHRONIZED。Before failing over an AG, verify that the synchronization state of the failover target is SYNCHRONIZED.

警告

将 SQL Server 的新实例或新版本安装到安装了旧版 SQL Server 的服务器可能会无意中“导致旧版 SQL Server 托管的任何可用性组中断。”Installing a new instance or new version of SQL Server to a server that has an older version of SQL Server installed may inadvertently cause an outage for any availability group that is hosted by the older version of SQL Server. 这是因为在安装 SQL Server 实例或版本期间,SQL Server 高可用性模块 (RHS.EXE) 会升级。This is because during the installation of the instance or version of SQL Server, the SQL Server high availability module (RHS.EXE) gets upgraded. 这会导致服务器上主要角色中的现有可用性组暂时中断。This results in a temporary interruption of your existing availability groups in the primary role on the server. 因此,强烈建议在将较新版本的 SQL Server 安装到已托管具有可用性组的旧版 SQL Server 系统时执行以下操作之一:Therefore, it is highly recommended that you do one of the following when installing a newer version of SQL Server to a system already hosting an older version of SQL Server with an availability group:

  • 在维护时段内安装新版本的 SQL Server。Install the new version of SQL Server during a maintenance window.
  • 将可用性组故障转移到次要副本,这样在安装新 SQL Server 实例期间它便不再是主要副本。Failover the availability group to the secondary replica so it is not primary during the installation of the new SQL Server instance.

滚动升级过程Rolling Upgrade Process

实际上,确切的过程取决于一些因素,如 AG 的部署拓扑和每个副本的提交模式。In practice, the exact process depends on factors such as the deployment topology of your AGs and the commit mode of each replica. 但在最简单的方案中,滚动升级是涉及以下步骤的多阶段过程:But in the simplest scenario, a rolling upgrade is a multi-stage process that in its simplest form involves the following steps:

HADR 方案中的 AG 升级AG Upgrade in HADR Scenario

  1. 在所有同步提交的副本上删除自动故障转移Remove automatic failover on all synchronous-commit replicas

  2. 升级所有异步提交的次要副本实例。Upgrade all asynchronous-commit secondary replica instances.

  3. 升级所有远程同步提交的次要副本实例。Upgrade all remote synchronous-commit secondary replica instances.

  4. 升级所有本地同步提交的次要副本实例。Upgrade all local synchronous-commit secondary replica instances.

  5. 手动将 AG 故障转移到(新升级的)本地同步提交的次要副本。Manually fail over the AG to a (newly upgraded) local synchronous-commit secondary replica.

  6. 升级或更新以前承载主要副本的本地副本实例。Upgrade or update the local replica instance that formerly hosted the primary replica.

  7. 根据需要配置自动故障转移伙伴。Configure automatic failover partners as desired.

如果需要,可以执行额外的手动故障转移将 AG 恢复到原始配置。If necessary, you can perform an extra manual failover to return the AG to its original configuration.

备注

  • 升级同步提交的副本并使它处于脱机状态不会延迟主要副本上的事务。Upgrading a synchronous-commit replica and taking it offline will not delay transactions on the primary. 次要副本断开连接后,无需等待在次要副本上强制执行日志操作,事务即可在主要副本上提交。Once the secondary replica is disconnected, transactions are committed on the primary without waiting for logs to harden on the secondary replica.
  • 如果 REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT 设置为 12,那么在更新过程中,当相应数量的同步次要副本不可用时,主要副本则不可用于读/写。If REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT is set to either 1 or 2, the Primary replica may be unavailabile for read/writes when a corresponding number of sync secondary replicas are not available during the update process.

具有一个远程次要副本的 AGAG with One Remote Secondary Replica

如果仅为灾难恢复部署了一个 AG,可能需要将该 AG 故障转移到异步提交的次要副本。If you have deployed an AG only for disaster recovery, you may need to fail over the AG to an asynchronous-commit secondary replica. 这样的配置如下图所示:Such configuration is illustrated by the following figure:

DR 方案中的 AG 升级AG Upgrade in DR Scenario

在此情况下,在滚动升级期间必须将 AG 故障转移到异步提交的次要副本。In this situation, you must fail over the AG to the asynchronous-commit secondary replica during the rolling upgrade. 要防止数据丢失,请在故障转移 AG 前将提交模式更改为同步提交并等待次要副本同步。To prevent data loss, change the commit mode to synchronous commit and wait for the secondary replica to be synchronized before you fail over the AG. 因此,滚动升级过程可能如下所示:Therefore, the rolling upgrade process may look as follows:

  1. 在远程站点上升级次要副本实例Upgrade the secondary replica instance on the remote site

  2. 将提交模式更改为同步提交Change the commit mode to synchronous commit

  3. 等待直到同步状态为 SYNCHRONIZEDWait until synchronization state is SYNCHRONIZED

  4. 在远程站点上将 AG 故障转移到次要副本Fail over the AG to the secondary replica on the remote site

  5. 升级或更新本地(主站点)副本实例Upgrade or update the local (primary site) replica instance

  6. 将 AG 故障转移回主站点Fail over the AG back to the primary site

  7. 将提交模式更改为异步提交Change the commit mode to asynchronous commit

因为同步提交模式不是用于数据同步到远程站点的建议设置,客户端应用程序可能发现在设置更改后,数据库延迟时间立即增加。Since the synchronous-commit mode is not a recommended setting for data synchronization to a remote site, client applications may notice an immediate increase in database latency after the setting change. 此外,执行故障转移将导致丢弃所有未确认的日志消息。Moreover, performing a failover causes all unacknowledged log messages to be discarded. 由于两个站点之间的高网络延迟,丢弃的日志消息量可能很大,这导致客户端经历大量事务失败。The number discarded log messages can be significant due to the high network latency between the two sites, causing clients to experience a high volume of transactional failure. 可以通过执行以下操作之一来尽量降低对客户端应用程序的影响:You can minimize impact to client applications by doing the following actions:

  • 在低客户端流量期间认真选择一个维护窗口Carefully select a maintenance window during low client traffic

  • 在主站点上升级/更新 SQL Server 2019 (15.x)SQL Server 2019 (15.x) 时,将可用性模式改回异步提交,在准备好再次故障转移到主站点时再将其恢复为同步提交While upgrading or updating SQL Server 2019 (15.x)SQL Server 2019 (15.x) on the primary site, change the availability mode back to asynchronous commit, then revert to synchronous commit when you are ready to fail over to the primary site again

具有故障转移群集实例节点的 AGAG with Failover Cluster Instance Nodes

如果 AG 包含故障转移群集实例 (FCI) 节点,应先升级不活动的节点,再升级活动的节点。If an AG contains failover cluster instance (FCI) nodes, you should upgrade the inactive nodes before you upgrade the active nodes. 下图显示一个常见的 AG 方案(它包含 FCI 用于本地高可用性且用于远程灾难恢复的 FCI 之间采用异步提交模式)和升级顺序。The following figure illustrates a common AG scenario with FCIs for local high availability and asynchronous commit between the FCIs for remote disaster recovery, and the upgrade sequence.

包含 FCI 的 AG 升级AG Upgrade with FCIs

  1. 升级或更新 REMOTE2Upgrade or update REMOTE2

  2. 将 FCI2 故障转移到 REMOTE2Fail over FCI2 to REMOTE2

  3. 升级或更新 REMOTE1Upgrade or update REMOTE1

  4. 升级或更新 PRIMARY2Upgrade or update PRIMARY2

  5. 将 FCI1 故障转移到 PRIMARY2Fail over FCI1 to PRIMARY2

  6. 升级或更新 PRIMARY1Upgrade or update PRIMARY1

升级或更新包含多个 AG 的 SQL Server 实例Upgrade or Update SQL Server Instances with Multiple AGs

如果正在单独的服务器节点(活动/活动配置)上运行包含主要副本的多个 AG,则升级路径涉及更多故障转移步骤以在过程中保持高可用性。If you are running multiple AGs with primary replicas on separate server nodes (an Active/Active configuration), the upgrade path involves more failover steps to preserve high availability in the process. 假定正在所有副本均处于同步提交模式下的三个服务器节点上运行三个 AG,如下表所示:Suppose you are running three AGs on three server nodes with all replicas in synchronous commit mode as shown in the following table:

AGAG Node1Node1 Node2Node2 Node3Node3
AG1AG1 Primary
AG2AG2 Primary
AG3AG3 Primary

按以下顺序执行负载平衡的滚动升级可能适合你的情况:It may be appropriate in your situation to perform a load-balanced rolling upgrade in the following sequence:

  1. 将 AG2 故障转移到 Node3(以空出 Node2)Fail over AG2 to Node3 (to free up Node2)

  2. 升级或更新 Node2Upgrade or update Node2

  3. 将 AG1 故障转移到 Node2(以空出 Node1)Fail over AG1 to Node2 (to free up Node1)

  4. 升级或更新 Node1Upgrade or update Node1

  5. 将 AG2 和 AG3 故障转移到 Node1(以空出 Node3)Fail over both AG2 and AG3 to Node1 (to free up Node3)

  6. 升级或更新 Node3Upgrade or update Node3

  7. 将 AG3 故障转移到 Node3Fail over AG3 to Node3

此升级顺序具有每个 AG 小于两个故障转移的平均故障时间。This upgrade sequence has an average downtime of fewer than two failovers per AG. 最终配置如下表所示。The resulting configuration is shown in the following table.

AGAG Node1Node1 Node2Node2 Node3Node3
AG1AG1 Primary
AG2AG2 Primary
AG3AG3 Primary

基于你的特定实现,你的升级路径可能不同,客户端应用程序经历的故障时间也可能不同。Based on your specific implementation, your upgrade path may vary, and the downtime that client applications experience may vary as well.

备注

在许多情况下,滚动升级完成后,将会故障转移回原始的主要副本。In many cases, after the rolling upgrade is completed, you will fail back to the original primary replica.

分布式可用性组的滚动升级Rolling upgrade of a distributed Availability Group

要执行分布式可用性组的滚动升级,首先升级所有次要副本。To perform a rolling upgrade of a distributed availability group, first upgrade all of the secondary replicas. 接下来,故障转移转发器,升级第二个可用性组的最后一个剩余实例。Next, failover the forwarder, and upgrade the last remaining instance of the second availability group. 升级其他所有副本后,故障转移全局主要副本,升级第一个可用性组的最后一个剩余实例。Once all other replicas have been upgraded, failover the global primary, and upgrade the last remaining instance of the first availability group. 下面提供了包含步骤的详细关系图。A detailed diagram with steps is provided below.

基于你的特定实现,你的升级路径可能不同,客户端应用程序经历的故障时间也可能不同。Based on your specific implementation, your upgrade path may vary, and the downtime that client applications experience may vary as well.

备注

在许多情况下,滚动升级完成后,将会故障转移回原始的主要副本。In many cases, after the rolling upgrade is completed, you will fail back to the original primary replicas.

升级分布式可用性组的一般步骤General steps to upgrade a distributed availability group

  1. 备份所有数据库,其中包括系统数据库,以及参与可用性组的数据库。Backup all databases, including system databases, and those participating in the availability group.
  2. 升级并重启第二个可用性组(下游)的所有次要副本。Upgrade and restart all secondary replicas of the second availability group (the downstream).
  3. 升级并重启第一个可用性组(上游)的所有次要副本。Upgrade and restart all secondary replicas of the first availability group (the upstream).
  4. 将主要转发器故障转移到第二个可用性组的已升级次要副本。Fail over the forwarder primary to an upgraded secondary replica of the secondary availability group.
  5. 等待数据同步。Wait for data synchronization. 数据库应显示为在所有同步提交副本上同步,且全局主要副本应与转发器同步。The databases should show as synchronized on all synchronous-commit replicas, and the global primary should be synchronized with the forwarder.
  6. 升级并重启第二个可用性组的最后一个剩余实例。Upgrade and restart the last remaining instance of the secondary availability group.
  7. 将全局主要副本故障转移到第一个可用性组的已升级次要副本。Fail over the global primary to an upgraded secondary of the first availability group.
  8. 升级主要可用性组的最后一个剩余实例。Upgrade the last remaining instance of the primary availability group.
  9. 重启新升级的服务器。Restart the newly upgraded server.
  10. (可选)将两个可用性组故障回复到其原始主要副本。(optional) Fail both availability groups back to their original primary replicas.

重要

  • 验证各步骤间的同步。Verify synchronization between every step. 在进行下一步前,确认同步提交副本在可用性组中同步,且全局主要副本与分布式 AG 中的转发器同步。Before proceeding to the next step, confirm that your synchronous-commit replicas are synchronized within the availability group, and that your global primary is synchronized with the forwarder in the distributed AG.
  • 建议:每当验证同步时,在 SQL Server Management Studio 中刷新数据库节点和分布式 AG 节点。Recommendation: Every time you verify synchronization, refresh both the database node and the distributed AG node in SQL Server Management Studio. 所有项同步后,保存每个副本状态的屏幕截图。After everything is synchronized, save a screenshot of the states of each replica. 这有助于跟踪当前步骤,在进行下一步前确保一切运行正常,并帮助你在故障发生时进行故障排除。This will help you keep track of what step you're on, provide evidence that everything was working correctly before the next step, and assist you with troubleshooting if anything goes wrong.

分布式可用性组的滚动升级的示例图Diagram example for a rolling upgrade of a distributed availability group

可用性组 (availability group)Availability group 主副本Primary replica 次要副本Secondary Replica
AG1AG1 NODE1\SQLAGNODE1\SQLAG NODE2\SQLAGNODE2\SQLAG
AG2AG2 NODE3\SQLAGNODE3\SQLAG NODE4\SQLAGNODE4\SQLAG
DistributedagDistributedag AG1(全局)AG1 (global) AG2(转发器)AG2 (forwarder)
     

分布式 AG 的示例图

此图中关于实例升级的步骤:The steps to upgrade the instances in this diagram:

  1. 备份所有数据库,其中包括系统数据库,以及参与可用性组的数据库。Backup all databases, including system databases, and those participating in the availability group.
  2. 升级 NODE4\SQLAG(AG2 的次要副本)并重启服务器。Upgrade NODE4\SQLAG (secondary of AG2) and restart the server.
  3. 升级 NODE2\SQLAG(AG1 的次要副本)并重启服务器。Upgrade NODE2\SQLAG (secondary of AG1) and restart the server.
  4. 将 AG2 从 NODE3\SQLAG 故障转移到 NODE4\SQLAG。Fail AG2 over from NODE3\SQLAG to NODE4\SQLAG.
  5. 升级 NODE3\SQLAG 并重启服务器。Upgrade NODE3\SQLAG and restart the server.
  6. 将 AG1 从 NODE1\SQLAG 故障转移到 NODE2\SQLAG。Fail AG1 over from NODE1\SQLAG to NODE2\SQLAG.
  7. 升级 NODE1\SQLAG 并重启服务器。Upgrade NODE1\SQLAG and restart the server.
  8. (可选)故障回复到原始主要副本。(optional) Fail back to the original primary replicas.
    1. 将 AG2 从 NODE4\SQLAG 故障转移到 NODE3\SQLAG。Fail AG2 over from NODE4\SQLAG back to NODE3\SQLAG.
    2. 将 AG1 从 NODE2\SQLAG 故障转移到 NODE1\SQLAG。Fail AG1 over from NODE2\SQLAG back to NODE1\SQLAG.

如果每个可用性组中存在第三个副本,将在 NODE3\SQLAG and NODE1\SQLAG 前升级。If a third replica existed in each availability group, it would be upgraded before NODE3\SQLAG and NODE1\SQLAG.

重要

  • 验证各步骤间的同步。Verify synchronization between every step. 在进行下一步前,确认同步提交副本在可用性组中同步,且全局主要副本与分布式 AG 中的转发器同步。Before proceeding to the next step, confirm that your synchronous-commit replicas are synchronized within the availability group, and that your global primary is synchronized with the forwarder in the distributed AG.
  • 建议:每当验证同步时,在 SQL Server Management Studio 中刷新数据库节点和分布式 AG 节点。Recommendation: Every time you verify synchronization, refresh both the database node and the Distributed AG node in SQL Server Management Studio. 同步所有项后,拍摄屏幕快照并保存。If After everything is synchronized, then take a screenshot and save it. 这有助于跟踪当前步骤,在进行下一步前确保一切运行正常,并帮助你在故障发生时进行故障排除。This will help you keep track of what step you're on, provide evidence that everything was working correctly before the next step, and assist you with troubleshooting if anything goes wrong.

更改数据捕获或复制的特殊步骤Special steps for change data capture or replication

根据正在应用的更新,其他步骤可能需要 AG 副本数据库启用变更数据捕获或复制。Depending on the update being applied, additional steps may be required for AG replica databases that are enabled for change data capture or replication. 请参阅更新的发行说明以确定是否需要执行以下步骤:Refer to the release notes for the update to determine if the following steps are required:

  1. 升级每个次要副本。Upgrade each secondary replica.

  2. 升级所有次要副本之后,将 AG 故障转移到已升级的实例。After all secondary replicas have been upgraded, fail over the AG to an upgraded instance.

  3. 在托管主要副本的实例上运行下列 Transact-SQL:Run the following Transact-SQL on the instance that hosts the primary replica:

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

    备注

    此命令可能需要几分钟才能运行。This command may take several minutes to run.

  4. 升级最初为主要副本的实例。Upgrade the instance that was originally the primary replica.

有关背景信息,请参阅升级到最新 CU 后,CDC 功能可能会中断For background information, see CDC functionality may break after upgrading to the latest CU.

另请参阅See Also

使用安装向导(安装程序)升级到 SQL Server 2016Upgrade to SQL Server 2016 Using the Installation Wizard (Setup)

从命令提示符安装 SQL Server 2016Install SQL Server 2016 from the Command Prompt