SQL Server 2012 からサービス パックまたは新しいバージョンにサーバー インスタンスを更新またはアップグレードする場合、順次更新またはアップグレードを実行することで、可用性グループのダウンタイムを 1 回の手動フェールオーバーのみに減らすことができます。 SQL Server のバージョンをアップグレードする場合、ローリング アップグレードと呼ばれます。現在の SQL Server バージョンを修正プログラムまたはサービス パックで更新する場合は、ローリング 更新プログラムと呼ばれます。
このトピックでは、SQL Server のアップグレード/更新のみに限定します。 高可用性 SQL Server インスタンスが実行されているオペレーティング システム関連のアップグレード/更新については、「オペレーティング システムアップグレードのための AlwaysOn 可用性グループのクロスクラスター移行」を参照してください。
AlwaysOn 可用性グループのローリング アップグレード/更新のベスト プラクティス
可用性グループのダウンタイムとデータ損失を最小限に抑えるために、サーバーのアップグレード/更新を実行する場合は、次のベスト プラクティスを確認する必要があります。
ローリングアップグレードや更新を開始する前に、
少なくとも 1 つの同期コミット レプリカで手動フェールオーバーを実行する
すべての可用性データベースを対象にデータベースの完全バックアップを実行し、データを保護する。
すべての可用性データベースで DBCC CHECKDB を実行する
常にリモート セカンダリ レプリカ ノードを最初にアップグレード/更新し、次にローカル セカンダリ レプリカ ノードを更新し、プライマリ レプリカ ノードを最後に更新します。
アップグレード中のデータベースではバックアップを実行できません。 セカンダリ レプリカをアップグレードする前に、プライマリ レプリカでのみバックアップを実行するように自動バックアップ設定を構成します。 プライマリ レプリカをアップグレードする前に、セカンダリ レプリカでのみバックアップを実行するようにこの設定を変更します。
アップグレード/更新プロセス中に可用性グループが意図しないフェールオーバーを防ぐには、開始する前にすべての同期コミット レプリカから可用性フェールオーバーを削除します。
最初にセカンダリ レプリカを使用してアップグレードされたノードに可用性グループをフェールオーバーする前に、プライマリ レプリカ ノードをアップグレードしないでください。 そうしないと、プライマリ レプリカのアップグレード/更新中に、クライアント アプリケーションに長時間のダウンタイムが発生する可能性があります。
常に同期コミット型のセカンダリ レプリカ ノードに可用性グループをフェールオーバーします。 非同期コミット セカンダリ レプリカにフェールオーバーすると、データベースはデータ損失を受け、データ移動は手動でデータ移動を再開するまで自動的に中断されます。
他のセカンダリ レプリカ ノードをアップグレードまたは更新する前に、プライマリ レプリカ ノードをアップグレードまたは更新しないでください。 アップグレードされたプライマリ レプリカは、同じバージョンにまだアップグレードされていないセカンダリ レプリカにログを発送できなくなりました。 セカンダリ レプリカへのデータ移動が中断されているときには、そのレプリカに対する自動フェールオーバーは実行されず、可用性データベースでデータ損失が発生する危険性が高まります。
可用性グループをフェールオーバーする前に、フェールオーバー ターゲットの同期状態が SYNCHRONIZED であることを確認します。
ローリング アップグレード/更新プロセス
実際には、正確なプロセスは、可用性グループのデプロイ トポロジや各レプリカのコミット モードなどの要因によって異なります。 ただし、最も単純なシナリオでは、ローリング アップグレード/更新は、最も単純な形式で次の手順を含むマルチステージ プロセスです。
)
すべての同期コミット レプリカの自動フェールオーバーを削除する。
非同期コミット セカンダリ レプリカを実行しているすべてのリモート サーバー インスタンスをアップグレードまたは更新する
現在プライマリ レプリカを実行していないすべてのローカル サーバー インスタンスをアップグレードまたは更新する
可用性グループを同期コミットのセカンダリレプリカに手動でフェイルオーバーする
以前にプライマリ レプリカをホストしていたサーバー インスタンスをアップグレードまたは更新する
必要に応じて自動フェールオーバー パートナーを構成する
必要に応じて、追加の手動フェールオーバーを実行して、可用性グループを元の構成に戻すことができます。
1 つのリモート セカンダリ レプリカを持つ可用性グループ
ディザスター リカバリー専用に可用性グループをデプロイした場合は、可用性グループを非同期コミット セカンダリ レプリカにフェールオーバーすることが必要になる場合があります。 次の図に、そのような構成の例を示します。
このような場合は、ローリング アップグレード/更新中に可用性グループを非同期コミット セカンダリ レプリカにフェールオーバーする必要があります。 データ損失を防ぐには、コミット モードを同期コミットに変更し、セカンダリ レプリカが同期されるまで待ってから可用性グループをフェールオーバーします。 そのため、ローリング アップグレード/更新プロセスは次のようになります。
リモート サーバーのアップグレード/更新
コミット モードを同期コミットに変更する。
同期状態が SYNCHRONIZED になるまで待機する
可用性グループをリモート サイトにフェールオーバーする
ローカル (プライマリ サイト) サーバーをアップグレードまたは更新する
可用性グループをプライマリ サイトにフェールオーバーする
コミット モードを非同期コミットに変更する。
同期コミット モードはリモート サイトへのデータ同期の推奨設定ではないため、クライアント アプリケーションでは、設定変更後のデータベース待機時間がすぐに増加する場合があります。 さらに、フェールオーバーを実行すると、未確認のログ メッセージがすべて破棄されます。 破棄されたログ メッセージの量は、2 つのサイト間のネットワーク待ち時間が長いために非常に大きくなる可能性があるため、クライアントで大量のトランザクション エラーが発生する可能性があります。 次の手順を実行することで、クライアント アプリケーションへの影響を最小限に抑えることができます。
クライアント トラフィックが少ない時間帯にメンテナンス予定を設定する。
プライマリ サイト上の SQL Server のアップグレード/更新中に、可用性モードを非同期コミットに戻し、プライマリ サイトに再度フェールオーバーする準備ができたら同期コミットに戻します
フェールオーバー クラスター インスタンス ノードを含む可用性グループ
可用性グループにフェールオーバー クラスター インスタンス (FCI) ノードが含まれている場合は、アクティブなノードをアップグレードまたは更新する前に、非アクティブなノードをアップグレード/更新する必要があります。 次の図は、ローカル高可用性のために FCI を使用し、リモート ディザスター リカバリーには非同期コミットを行う一般的な可用性グループのシナリオと、アップグレード シーケンスを示しています。
)
REMOTE2のアップグレード/更新
FCI2 をREMOTE2にフェールオーバーする
リモート1のアップグレード/更新
PRIMARY2のアップグレード/更新
FCI1 をPRIMARY2にフェールオーバーする
アップグレード/アップデートPRIMARY1
複数の可用性グループを使用した SQL Server インスタンスのアップグレード/更新
個別のサーバー ノード (アクティブ/アクティブ構成) でプライマリ レプリカを持つ複数の可用性グループを実行している場合、アップグレード/更新パスには、プロセスの高可用性を維持するためのフェールオーバー手順がさらに必要になります。 次の表に示すように、3 つのサーバー ノードで 3 つの可用性グループを実行していて、すべてのセカンダリ レプリカが同期コミット モードで実行されているとします。
| 可用性グループ | Node1 | Node2 | Node3 |
|---|---|---|---|
| AG1 | プライマリ | ||
| AG2 | プライマリ | ||
| AG3 | プライマリ |
次の順序で負荷分散されたローリング アップグレード/更新を実行することが適切な場合があります。
AG2 を Node3 にフェールオーバーする (Node2 を解放するには)
Node2 のアップグレード/更新
AG1 を Node2 にフェールオーバーする (Node1 を解放するには)
Node1 のアップグレード/更新
AG2 と AG3 の両方を Node1 にフェールオーバーする (Node3 を解放するには)
Node3 のアップグレード/更新
AG3 から Node3 へのフェールオーバー
このアップグレード/更新シーケンスの平均ダウンタイムは、可用性グループあたり 2 回未満です。 結果の構成を次の表に示します。
| 可用性グループ | Node1 | Node2 | Node3 |
|---|---|---|---|
| AG1 | プライマリ | ||
| AG2 | プライマリ | ||
| AG3 | プライマリ |
特定の実装に基づいて、アップグレード/更新パスが異なる場合があり、クライアント アプリケーションで発生するダウンタイムも異なる場合があります。