Share via

ダウンタイムとデータ損失を最小限に抑えた可用性グループ サーバーのアップグレードおよび更新

  • [アーティクル]

SQL Server 2012 のサーバー インスタンスをサービス パックで更新するとき、または新しいバージョンにアップグレードするときに、順次更新または順次アップグレードを実行することにより、可用性グループのダウンタイムを手動フェールオーバー 1 回分のみに抑えることができます。 SQL Server のバージョンをアップグレードする場合、この操作をローリング アップグレードと呼びます。現在のバージョンの SQL Server に修正プログラムまたはサービス パックを適用して更新する場合、この操作をローリング アップデートと呼びます。

ここでは、SQL Server のアップグレードまたは更新についてのみ説明します。 高可用性SQL Server インスタンスが実行されているオペレーティング システム関連のアップグレード/更新については、「オペレーティング システムアップグレードのための AlwaysOn 可用性グループのクロスクラスター移行」を参照してください。

AlwaysOn 可用性グループのローリング アップグレードおよびローリング アップデートのベスト プラクティス

サーバーのアップグレードまたは更新の際に可用性グループのダウンタイムとデータ損失を最小限に抑えるには、次のベスト プラクティスに従ってください。

  • ローリング アップグレードまたはローリング アップデートを開始する前に、次の操作を実行します。

    • 少なくとも 1 つの同期コミット レプリカで試験的に手動フェールオーバーを実行する。

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

    • すべての可用性データベースに対して DBCC CHECKDB コマンドを実行する。

  • 常に、最初はリモートのセカンダリ レプリカ ノード、次にローカルのセカンダリ レプリカ ノード、最後にプライマリ レプリカ ノードという順序でアップグレードまたは更新してください。

  • アップグレード中のデータベースでバックアップを実行することはできません。 セカンダリ レプリカをアップグレードする前に、プライマリ レプリカでのみバックアップを実行するように自動バックアップ設定を構成します。 プライマリ レプリカをアップグレードする前に、この設定を変更してセカンダリ レプリカでのみバックアップを実行するようにします。

  • アップグレード プロセスまたは更新プロセスの間に可用性グループが誤ってフェールオーバーされることを防ぐために、作業開始前にすべての同期コミット レプリカから可用性フェールオーバーを削除してください。

  • 最初にセカンダリ レプリカを使用して可用性グループをアップグレード済みノードにフェールオーバーした後で、プライマリ レプリカ ノードをアップグレードするようにしてください。 このベスト プラクティスに従わなかった場合、プライマリ レプリカでのアップグレードまたは更新の際にクライアント アプリケーションで長時間のダウンタイムが発生する可能性があります。

  • 可用性グループは常に同期コミット セカンダリ レプリカ ノードにフェールオーバーしてください。 非同期コミット セカンダリ レプリカにフェールオーバーした場合、データベースでデータ損失が発生し、データ移動が自動的に中断されます。データ移動を再開するには、手動で操作する必要があります。

  • 他のセカンダリ レプリカ ノードをアップグレードまたは更新する前に、プライマリ レプリカ ノードをアップグレードまたは更新しないでください。 アップグレードされたプライマリ レプリカから、同じバージョンにまだアップグレードされていないセカンダリ レプリカにログを送信できなくなります。 セカンダリ レプリカへのデータ移動が中断されているときには、そのレプリカに対する自動フェールオーバーは実行されず、可用性データベースでデータ損失が発生する危険性が高まります。

  • 可用性グループをフェールオーバーする前に、フェールオーバー ターゲットの同期状態が SYNCHRONIZED であることを確認してください。

ローリング アップグレードおよびローリング アップデートのプロセス

実際のプロセスは、可用性グループの配置トポロジや各レプリカのコミット モードなどの要因によって変わります。 ただし、最も単純なシナリオにおけるローリング アップグレードおよびローリング アップデートは、次の手順で構成される単純な複数段階のプロセスになります。

HADR シナリオでの可用性グループのアップグレード HADR シナリオ

  1. すべての同期コミット レプリカの自動フェールオーバーを削除する。

  2. 非同期コミット セカンダリ レプリカを実行しているリモート サーバー インスタンスをすべてアップグレードまたは更新する。

  3. プライマリ レプリカを現在実行していないローカル サーバー インスタンスをすべてアップグレードまたは更新する。

  4. 可用性グループを手動で同期コミット セカンダリ レプリカにフェールオーバーする。

  5. それまでプライマリ レプリカをホストしていたサーバー インスタンスをアップグレードまたは更新する。

  6. 必要に応じて自動フェールオーバー パートナーを構成する。

必要であれば、さらに手動でフェールオーバーを実行して、可用性グループを元の構成に戻すこともできます。

1 つのリモート セカンダリ レプリカを含む可用性グループ

災害復旧のみを目的として可用性グループを配置していた場合、可用性グループを非同期コミット セカンダリ レプリカにフェールオーバーする必要がある場合があります。 次の図に、そのような構成の例を示します。

DR シナリオでの可用性グループのアップグレード DR シナリオ

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

  1. リモート サーバーをアップグレードまたは更新する。

  2. コミット モードを同期コミットに変更する。

  3. 同期状態が SYNCHRONIZED になるまで待機する。

  4. 可用性グループをリモート サイトにフェールオーバーする。

  5. ローカル (プライマリ サイト) サーバーをアップグレードまたは更新する。

  6. 可用性グループをプライマリ サイトにフェールオーバーする。

  7. コミット モードを非同期コミットに変更する。

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

  • クライアント トラフィックが少ない時間帯にメンテナンス予定を設定する。

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

フェールオーバー クラスター インスタンス ノードを含む可用性グループ

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

FCIs を使用した可用性グループのアップグレード FCI を

  1. REMOTE2 のアップグレード/更新

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

  3. REMOTE1 のアップグレード/更新

  4. PRIMARY2 のアップグレード/更新

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

  6. PRIMARY1 のアップグレード/更新

複数の可用性グループを含む SQL Server インスタンスのアップグレードまたは更新

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

可用性グループ 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 つの可用性グループに対して 2 回のフェールオーバーを実行するよりも平均ダウンタイムが小さくなります。 実行後の構成は、次の表のようになります。

可用性グループ Node1 Node2 Node3
AG1 プライマリ
AG2 プライマリ
AG3 プライマリ

実際の実装方法に応じて、アップグレードまたは更新の手順が変わる可能性があります。また、クライアント アプリケーションで発生するダウンタイムも変わります。