AlwaysOn 可用性グループのレプリカ インスタンスのアップグレードUpgrading Always On Availability Group Replica Instances

適用対象: ○SQL Server XAzure SQL Database XAzure SQL Data Warehouse XParallel Data WarehouseAPPLIES TO: yesSQL Server noAzure SQL Database noAzure SQL Data Warehouse noParallel Data Warehouse

Always On 可用性グループ (AG) をホストする SQL ServerSQL Server インスタンスを新しい SQL Server 2017SQL Server 2017 バージョン、新しい SQL ServerSQL Serverサービス パックまたは累積更新プログラムにアップグレードしている場合、または新しい Windows サービス パックまたは累積更新プログラムにインストールしている場合、ローリング アップグレードを実行して、単一の手動フェールオーバー (または、元のプライマリにフェールバックする場合は、2 回の手動フェールオーバー) におけるプライマリ レプリカのダウンタイムを減らすことができます。When upgrading a SQL ServerSQL Server instance that hosts an Always On Availability Group (AG) to a new SQL Server 2017SQL Server 2017 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 オペレーティング システムのアップグレードは、Windows Server 2012 R2 より前のオペレーティング システムではサポートされません。Upgrading the Windows operating system hosting the failover cluster is not supported for operating systems before Windows Server 2012 R2. Windows Server 2012 R2 で実行されているクラスター ノードのアップグレードについては、「Cluster Operating System Rolling Upgrade」(クラスター オペレーティング システムのローリング アップグレード) を参照してください。To upgrade a cluster node running on Windows Server 2012 R2, see Cluster Operating System Rolling Upgrade.

PrerequisitesPrerequisites

作業を開始する前に、次の重要な情報を確認してください。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,

    • 少なくとも 1 つの同期コミット レプリカ インスタンスで試験的に手動フェールオーバーを実行する。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 CHECKDB コマンドを実行する。Run 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 2017SQL Server 2017 インスタンスのあるセカンダリ レプリカにログを送信できなくなります。An upgraded primary replica can no longer ship logs to any secondary replica whose SQL Server 2017SQL Server 2017 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.

  • 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_COMMIT1 または 2 に設定されている場合、更新処理中に対応する数の同期セカンダリ レプリカが使用できない場合、プライマリ レプリカから読み書きできない場合があります。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.

1 つのリモート セカンダリ レプリカを含む 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. 同期状態が SYNCHRONIZED になるまで待機する。Wait 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. 2 つのサイト間のネットワーク待機時間が長いと、破棄されるログ メッセージの数が膨大になり、クライアントで大量のトランザクション エラーが発生することがあります。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 2017SQL Server 2017 をアップグレードまたは更新するときに、可用性モードを非同期コミットに戻し、もう一度プライマリ サイトへのフェールオーバーの準備が完了したときに、同期コミットに戻す。While upgrading or updating SQL Server 2017SQL Server 2017 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. 次の図では、ローカルでの可用性を高めるために FCI を使用し、リモートのディザスター リカバリーのために FCI 間の非同期コミットを使用する、一般的な AG のシナリオを示します。さらに、アップグレード手順も示しています。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. REMOTE2 をアップグレードまたは更新する。Upgrade or update REMOTE2

  2. FCI2 を REMOTE2 にフェールオーバーする。Fail over FCI2 to REMOTE2

  3. REMOTE1 をアップグレードまたは更新する。Upgrade or update REMOTE1

  4. PRIMARY2 をアップグレードまたは更新する。Upgrade or update PRIMARY2

  5. FCI1 を PRIMARY2 にフェールオーバーする。Fail over FCI1 to PRIMARY2

  6. PRIMARY1 をアップグレードまたは更新する。Upgrade 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. 次の表に示すように、3 つのサーバー ノードで 3 つの 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. Node2 をアップグレードまたは更新する。Upgrade or update Node2

  3. AG1 を Node2 にフェールオーバーする (Node1 を解放)。Fail over AG1 to Node2 (to free up Node1)

  4. Node1 をアップグレードまたは更新する。Upgrade or update Node1

  5. AG2 および AG3 を Node1 にフェールオーバーする (Node3 を解放)。Fail over both AG2 and AG3 to Node1 (to free up Node3)

  6. Node3 をアップグレードまたは更新する。Upgrade or update Node3

  7. AG3 を Node3 にフェールオーバーする。Fail over AG3 to Node3

この順序でアップグレードを実行した場合、1 つの AG に対して 2 回のフェールオーバーを実行するよりも平均ダウンタイムが短くなります。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 プライマリ レプリカ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.

各可用性グループに 3 番目のレプリカが存在する場合は、NODE3\SQLAG と 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 2016 へのアップグレード (セットアップ)Upgrade to SQL Server 2016 Using the Installation Wizard (Setup)

コマンド プロンプトからの SQL Server 2016 のインストールInstall SQL Server 2016 from the Command Prompt