可用性グループのレプリカのアップグレード

適用対象:SQL Server

Always On 可用性グループ (AG) をホストする SQL Server インスタンスを新しい SQL Server バージョン、新しい SQL Server サービス パックまたは累積更新プログラムにアップグレードしている場合、または新しい Windows サービス パックまたは累積更新プログラムにインストールしている場合、ローリング アップグレードを実行して、単一の手動フェールオーバー (または、元のプライマリにフェールバックする場合は、2 回の手動フェールオーバー) におけるプライマリ レプリカのダウンタイムを減らすことができます。

アップグレード プロセス中、セカンダリ レプリカはフェールオーバーまたは読み取り専用操作に使用できません。アップグレード後、プライマリ レプリカ ノードでのアクティビティの量によっては、セカンダリ レプリカがプライマリ レプリカ ノードに追いつくまで時間がかかる場合があります (そのため、ネットワーク トラフィックが多くなります)。

また、新しいバージョンの SQL Server を実行しているセカンダリ レプリカに最初にフェールオーバーした後は、その AG のデータベースは、最新バージョンに移動するためにアップグレード プロセス経由で実行されることに注意してください。 この間、これらのいずれのデータベースにも読み取り可能なレプリカはありません。 最初のフェールオーバー後のダウンタイムは、AG 内のデータベースの数によって異なります。 元のプライマリへのフェールバックを計画する場合、フェールバックするときに、この手順が繰り返されることはありません。

Note

この記事では、SQL Server 自体のアップグレードについてのみ説明します。 Windows Server フェールオーバー クラスター (WSFC) を含むオペレーティング システムのアップグレードについては説明しません。 フェールオーバー クラスターをホストする Windows オペレーティング システムのアップグレードは、Windows Server 2012 R2 より前のオペレーティング システムではサポートされていません。 Windows Server 2012 R2 で実行されているクラスター ノードのアップグレードについては、「Cluster Operating System Rolling Upgrade」(クラスター オペレーティング システムのローリング アップグレード) を参照してください。

前提条件

作業を開始する前に、次の重要な情報を確認してください。

• サポートされるバージョンとエディションのアップグレード: お使いのバージョンの Windows オペレーティング システムと SQL Server から最新のバージョンの SQL Server にアップグレードできることを確認します。 たとえば、SQL Server 2005 インスタンスから直接アップグレードすると、データベース互換性レベルがアップグレードされます。

• データベース エンジンのアップグレード方法の選択: 正しい順序でアップグレードするには、サポートされるバージョンとエディションのアップグレードに基づいて、また、自分の環境にインストールされているその他のコンポーネントに基づいて、適切なアップグレードの方法と手順を選択します。

• データベース エンジンのアップグレード計画を計画してテストする: リリース ノートと既知のアップグレードの問題、アップグレード前のチェックリストを確認し、アップグレード計画を開発してテストします。

• SQL Server のインストールに必要なハードウェアおよびソフトウェア:SQL Server のインストールにおけるソフトウェア要件を確認します。 その他のソフトウェアが必要な場合は、ダウンタイムを最小限に抑えるために、アップグレード プロセスを開始する前に、各ノードにソフトウェアをインストールします。

• 変更データ キャプチャまたはレプリケーションを AG データベースに使用するかどうかの確認: AG のデータベースを変更データ キャプチャ (CDC) に対して有効にする場合は、この手順を完了してください。

Note

• 同じ AG 内の SQL Server インスタンスのバージョンの混在は、ローリング アップグレードの外部ではサポートされていないため、アップグレードを迅速に行う必要があるため、長期間その状態に存在することはできません。 SQL Server 2016 (13.x) 以降のバージョンをアップグレードするためのもう 1 つのオプションは、分散型可用性グループを使用することです。
• Cluster-Aware 更新 (CAU) Windows 機能を使用して Always On 可用性グループを更新することはサポートされていません。

可用性グループのローリング アップグレードの基本

サーバーのアップグレードまたは更新を行う時に、AG のダウンタイムとデータ損失を最小限に抑えるには、次のガイドラインに従ってください。

• ローリング アップグレードを始める前に:

  • 少なくとも 1 つの同期コミット レプリカ インスタンスに対して手動フェールオーバーを実行します。

  • すべての可用性データベースでデータベースの完全バックアップを実行して、データを保護します。

  • すべての可用性データベースで 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にインプレース アップグレードすると、可用性グループ内のデータベースは、可用性グループが手動でフェールオーバーされるまで、同期中/復旧中または同期済/復旧中状態のままになり、データベースの復旧とアップグレードが完了します。 アップグレードされたプライマリ レプリカは、下位バージョンのセカンダリ レプリカにログを発送できなくなり、データ移動が停止し、そのレプリカに対して自動フェールオーバーが行われず、可用性データベースはデータ損失に対して脆弱になります。 古いプライマリをアップグレードした後、同期を再開することが必要になる場合があります。 新しいバージョンのレプリカにフェールオーバーする前に、すべてのセカンダリ レプリカをアップグレードすることをお勧めします。 これにより、データベースを新しい形式にアップグレードした後にフェールオーバーを実行できます。

1 つのリモート セカンダリ レプリカを含む AG

ディザスター リカバリー専用に AG をデプロイした場合は、AG を非同期コミット セカンダリ レプリカにフェールオーバーすることが必要になる場合があります。 次の図は、このような構成を示しています。

この場合には、ローリング アップグレード時に AG を非同期コミット セカンダリ レプリカにフェールオーバーする必要があります。 データ損失を防ぐには、コミット モードを同期コミットに変更し、セカンダリ レプリカが同期されるまで待ってから AG をフェールオーバーします。 そのため、ローリング アップグレード プロセスは次のようになります。

1. リモート サイトのセカンダリ レプリカ インスタンスをアップグレードします。
2. コミット モードを同期コミットに変更します。
3. 同期状態が SYNCHRONIZEDされるまで待ちます。
4. AG をリモート サイトのセカンダリ レプリカにフェールオーバーします。
5. ローカル (プライマリ サイト) レプリカ インスタンスをアップグレードまたは更新します。
6. AG をプライマリ サイトにフェールオーバーします。
7. コミット モードを非同期コミットに変更します。

同期コミット モードはリモート サイトへのデータ同期に推奨される設定ではないので、クライアント アプリケーションでは、設定の変更後にデータベース待機時間がすぐに増加する可能性があります。 さらに、フェールオーバーを実行すると未確認のログ メッセージがすべて破棄されます。 破棄されたログ メッセージの数は、2 つのサイト間のネットワーク待機時間が長いために大きくなる可能性があるため、クライアントで大量のトランザクション エラーが発生する可能性があります。 クライアント アプリケーションへの影響を最小限に抑えるには、次のようにします。

• クライアント トラフィックが少ない場合は、メンテナンス期間を慎重に選択します。

• プライマリ サイト上の SQL Server のアップグレードまたは更新中に、可用性モードを非同期コミットに戻し、プライマリ サイトに再度フェールオーバーする準備ができたら同期コミットに戻します。

フェールオーバー クラスター インスタンス ノードを含む AG

AG にフェールオーバー クラスター インスタンス (FCI) ノードが含まれている場合、非アクティブなノードをアップグレードした後で、アクティブなノードをアップグレードする必要があります。 次の図では、ローカルでの可用性を高めるために FCI を使用し、リモートのディザスター リカバリーのために FCI 間の非同期コミットを使用する、一般的な AG のシナリオを示します。さらに、アップグレード手順も示しています。

1. REMOTE2 をアップグレードまたは更新する
2. FCI2 を REMOTE2 にフェールオーバーする
3. REMOTE1 をアップグレードまたは更新する
4. PRIMARY2 をアップグレードまたは更新する
5. FCI1 を PRIMARY2 にフェールオーバーする
6. PRIMARY1 をアップグレードまたは更新する

複数の AG を含む SQL Server インスタンスをアップグレードまたは更新する

個別のサーバー ノード (アクティブ/アクティブ構成) でプライマリ レプリカを持つ複数の AG を実行している場合、アップグレード パスには、プロセスの高可用性を維持するためのフェールオーバー手順がさらに必要になります。 次の表に示すように、すべてのレプリカが同期コミット モードの 3 つのサーバー ノードで 3 つの AG を実行しているとします。

AG	Node1	Node2	Node3
AG1	プライマリ
AG2		プライマリ
AG3			プライマリ

次の順序で負荷分散されたローリング アップグレードを実行することが、状況に適している場合があります。

1. AG2 を Node3 にフェールオーバーする (Node2 を解放するため)
2. Node2 をアップグレードまたは更新する
3. AG1 を Node2 にフェールオーバーする (Node1 を解放するため)
4. Node1 をアップグレードまたは更新する
5. AG2 と AG3 を Node1 にフェールオーバーする (Node3 を解放するため)
6. Node3 をアップグレードまたは更新する
7. AG3 を Node3 にフェールオーバーする

この順序でアップグレードを実行した場合、1 つの AG に対して 2 回のフェールオーバーを実行するよりも平均ダウンタイムが短くなります。 実行後の構成は、次の表のようになります。

AG	Node1	Node2	Node3
AG1		プライマリ
AG2	プライマリ
AG3			プライマリ

特定の実装に基づいて、アップグレード パスが異なる場合があり、クライアント アプリケーションで発生するダウンタイムも異なる場合があります。

Note

多くの場合、ローリング アップグレードが完了すると、元のプライマリ レプリカにフェールバックされます。

分散型可用性グループのローリング アップグレード

分散型可用性グループのローリング アップグレードを実行するには、まずすべてのセカンダリ レプリカをアップグレードします。 次に、フォワーダーをフェールオーバーし、2 番目の可用性グループの最後の残りのインスタンスをアップグレードします。 他のすべてのレプリカがアップグレードされたら、グローバル プライマリをフェールオーバーし、最初の可用性グループの最後の残りのインスタンスをアップグレードします。 手順を含む詳細な図については、後のセクションで説明します。

特定の実装に基づいて、アップグレード パスが異なる場合があり、クライアント アプリケーションで発生するダウンタイムも異なる場合があります。

Note

多くの場合、ローリング アップグレードが完了すると、元のプライマリ レプリカにフェールバックされます。

分散型可用性グループをアップグレードする一般的な手順

1. システム データベースと可用性グループに参加しているデータベースを含むすべてのデータベースをバックアップします。
2. セカンダリ可用性グループ (ダウンストリーム) のセカンダリ レプリカがすべてアップグレードおよび再起動されます。
3. 最初の可用性グループ (アップストリーム) のセカンダリ レプリカがすべてアップグレードおよび再起動されます。
4. フォワーダー プライマリがセカンダリ可用性グループのアップグレードされたセカンダリ レプリカにフェールオーバーされます。
5. データ同期を待ちます。 データベースはすべての同期コミット レプリカ上で同期されたと示され、グローバル プライマリはフォワーダーと同期されます。
6. セカンダリ可用性グループの最後の残りのインスタンスがアップグレードして再起動されます。
7. グローバル プライマリが最初の可用性グループのアップグレードされたセカンダリにフェールオーバーされます。
8. プライマリ可用性グループの最後の残りのインスタンスがアップグレードされます。
9. 新しくアップグレードされたサーバーが再起動されます。
10. (省略可能) 両方の可用性グループが元のプライマリ レプリカにフェールバックされます。

重要

すべてのステップ間の同期を確認します。 次のステップに進む前に、同期コミット レプリカが可用性グループ内で同期され、グローバル プライマリが分散型 AG 内のフォワーダーと同期されていることを確認します。

推奨事項:同期を確認するたびに、データベース ノードと SQL Server Management Studio 内の分散型 AG ノードの両方を更新してください。 すべてが同期されたら、各レプリカの状態のスクリーンショットを保存します。 これにより、現在のステップを追跡し、次の手順の前にすべてが正しく動作していたという証拠が提供され、問題が発生した場合のトラブルシューティングが支援されます。

分散型可用性グループのローリング アップグレードの例の図

可用性グループ	プライマリ レプリカ	セカンダリ レプリカ
AG1	NODE1\SQLAG	NODE2\SQLAG
AG2	NODE3\SQLAG	NODE4\SQLAG
DistributedAG	AG1 (グローバル)	AG2 (フォワーダー)

この図のインスタンスをアップグレードするステップ

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 にフェールバックします。

各可用性グループに 3 つ目のレプリカが存在する場合は、 NODE3\SQLAG して NODE1\SQLAGする前にアップグレードします。

重要

すべてのステップ間の同期を確認します。 次のステップに進む前に、同期コミット レプリカが可用性グループ内で同期され、グローバル プライマリが分散型 AG 内のフォワーダーと同期されていることを確認します。

推奨事項: 同期を確認するたびに、データベース ノードと SQL Server Management Studio 内の分散型 AG ノードの両方を更新してください。 すべてが同期されたら、スクリーンショットを撮って保存します。 これにより、現在のステップを追跡し、次の手順の前にすべてが正しく動作していたという証拠が提供され、問題が発生した場合のトラブルシューティングが支援されます。

変更データ キャプチャまたはレプリケーションの特別な手順

適用される更新プログラムによっては、変更データ キャプチャまたはレプリケーションが有効になっている AG レプリカ データベースに追加の手順が必要になる場合があります。 次の手順が必要かどうかを確認するには、更新プログラムのリリース ノートを参照してください。

1. 各セカンダリ レプリカをアップグレードします。

2. すべてのセカンダリ レプリカがアップグレードされてから、AG をアップグレードされたインスタンスにフェール オーバーします。

3. プライマリ レプリカをホストするインスタンスで、次の Transact-SQL を実行します。

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

   Note

   このコマンドの実行には数分かかる場合があります。 SQL Server 2019 CU1 以降の場合は、この手順をスキップしてください。 詳細については、 KB4530283を確認してください。

4. 元はプライマリ レプリカであったインスタンスをアップグレードします。

背景情報については、「 最新の CU にアップグレードした後に CDC 機能が中断する可能性がある」を参照してください。

関連コンテンツ

• インストール ウィザードを使用して SQL Server をアップグレードする (セットアップ)
• コマンド プロンプトから Windows に SQL Server をインストールして構成する