18 一般的なシナリオでの自動フェイルオーバーの最適化による停止時間の最小化

次のトピックでは、停止時間をなくすか最小限にするためと、問題のある様々な状況を回避するための一般的なシナリオに関して、Oracle Data Guard MAAのベスト・プラクティスを示します。

プライマリ・データベースの停止の場合の自動データベース・フェイルオーバー

ファスト・スタート・フェイルオーバー(FSFO)は、プライマリ・データベースが停止したときに自動データベース・フェイルオーバーを実行するOracle Data Guard機能です。FSFOは、Data Guard Brokerの一部であるData Guardオブザーバ・プロセスによって制御されます。自動データベース・フェイルオーバーを制御するオブザーバ・プロセスが起動されると、プライマリ・データベースとスタンバイ・データベースの両方に接続するスレッドが作成されます。各スレッドにより、データベース・セッションが作成され、dbms_drsパッケージを使用してデータベース・ヘルスが検証されます。スレッドが応答しない場合は、新しいスレッドが作成され、Data Guardによってセッションの作成とdbms_drsパッケージの使用が試みられます。定義した期間(しきい値)までにスレッドが応答しない場合、データベースは使用不可とみなされます。

プライマリ・データベースが同時にスタンバイとオブザーバからネットワーク的に分離されると、プライマリはオブザーバまたはスタンバイに再度接続できるようになるまで停止します(新しいトランザクションはコミットできません)。これは、スプリット・ブレインを明示的に防ぐために実行されます。オブザーバとスタンバイが、どちらでもプライマリを認識できないことに同意しており、それらが接続を失った時点でFSFOが有効になっていた場合は、FSFOのしきい値を超えると自動フェイルオーバーが発生します。これと同時に、プライマリもFSFOのしきい値を超え、それが原因で、フェイルオーバー発生後に既存の接続で古いデータの読取りを続行できないように、プライマリが中断されます。プライマリは、FSFOのしきい値を満たす前にオブザーバ、またはフェイルオーバー・ターゲットとして指定されているスタンバイに接続できる場合は、トランザクションの処理を続行できます。FSFOのしきい値を超えたためにプライマリが中断された場合、プライマリは、再起動時の、オープンできるようになる前に、オブザーバまたはその元のスタンバイから許可を得る必要があります。接続の確立時に、それが離れていた間にフェイルオーバーが発生したため自動的にスタンバイ・データベースに変換されることか、または、フェイルオーバーが発生しなかった場合は、オープンを許可されることが通知されます。これにより、アクティブなプライマリが同時に2つ存在することがなくなります。

プライマリは、オブザーバまたはスタンバイのどちらかとの接続を失った場合は、まだ2つのパーティのどちらかと通信できるため、トランザクションの処理を続行します。プライマリとスタンバイの両方がオブザーバとの接続を失った場合、それらはUNOBSERVED状態になります。プライマリがスタンバイとの接続を失った場合、それはUNSYNCHRONIZED状態になります。このような方法で、オブザーバまたはスタンバイが停止するか両方が別々の時点で停止してもFSFO構成でのプライマリ・データベースの可用性に影響しないようにしています。

プライマリ・データベースをオブザーバで使用できないと思われる場合は、スタンバイが1)応答しており、2)プライマリを使用できないことを認識し、3)最後の通信の時点で同期されていれば、オブザーバによって自動フェイルオーバーが開始されます。

ベスト・プラクティスとして、オブザーバは、プライマリ、オブザーバおよびスタンバイの電力、サーバー、ストレージおよびネットワーク・インフラストラクチャが分離されるように、第3のサイトまたは第3のデータ・センターに配置することが理想的です。2つのサイトを使用して同様のレベルの分離を実現できますが、Data Guardを障害時リカバリに使用する場合は、オブザーバをプライマリ・データベース・サーバーまたはクラスタ、あるいはスタンバイ・データベース・サーバーまたはクラスタにデプロイしないでください。

その他のベスト・プラクティスは、オブザーバで、アプリケーション層で使用されているのと同じパスを使用して本番データベースに接続することです。これを実行する理由は、オブザーバでアプリケーション接続と同じアクセス・パスを使用することで、アプリケーション接続でプライマリを認識できない場合にオブザーバで同じ問題が発生し迅速に対応できるようにするためです。このベスト・プラクティスには、アプリケーション層が本番データベースに対してローカルにありスタンバイが障害時リカバリのためにリモート・データ・センターにある場合は注意事項があります。この場合は、オブザーバにデータベースと同じ問題が発生する可能性があるため、オブザーバをアプリケーション層にデプロイすることはお薦めしません。かわりに、オブザーバをスタンバイ・ロケーションまたは第3のデータ・センターにデプロイする必要があります。

最近のどのOracle Databaseリリースにおいても、Data Guard Brokerでは、プライマリとの新しい接続を定期的に確立してどのような新しい接続が発生するかをシミュレートする機能が含まれており、プライマリ・データベースのヘルスをさらに監視できるようになっています。

自動データ整合性およびスプリット・ブレインの回避

Oracle Data Guard構成では、本番データベースの複数の同期コピーが保持されます。Data Guardでは、単純な一方向レプリケーションが使用されるため、プライマリ・データベースは、読取り/書込みでオープンされている唯一のデータベースです。他のすべてのレプリカ(スタンバイ・データベース)は、マウント・モードまたは読取り専用オープン(Oracle Active Data Guardを使用している場合)である必要があります。'スプリット・ブレイン'という用語は、読取り/書込みでオープンされている同じデータベースのコピーが2つあり、それぞれが他方から独立して機能するというシナリオを表しています。これは、データの整合性が失われる、非常に望ましくない状況です。次のアルゴリズムにより、Data Guardの同期構成でのデータの整合性が確保され、スプリット・ブレインを回避できます。

  • プライマリ・データベースのログ・ライター(LGWR)のREDO書込みと、スタンバイ・データベースに送信される同期REDO転送書込みは、REDOの内容とサイズが同一です。
  • スタンバイ・データベースでのData Guard Managed Recovery Process (MRP)では、REDOがプライマリのオンラインREDOログに書き込まれている場合を除き、REDOを適用できません。ただし、唯一の例外は、Data Guardフェイルオーバー(recover managed standby database finishを使用)の操作の間です。同期転送プロセスとLGWRでは、REDOの同期的な送信のみでなく、スタンバイ・リカバリでそのスタンバイREDOログから適用できる安全なREDOブロック境界に関して、情報交換も実行されます。この境界により、スタンバイで受信された可能性があるがプライマリではまだそれ固有のオンラインREDOログにコミットされたという確認応答が送信されていないREDOが、スタンバイに適用されることがなくなります。

Data Guard SYNCにより、次の3つの一般的な停止カテゴリすべてで、データの整合性が維持されます:

  • プライマリの障害と再起動(たとえば、LGWR I/O障害、LGWRクラッシュ、インスタンス障害またはデータベース障害): たとえば、プライマリ・データベースのLGWRでオンラインREDOログに書き込めない場合は、インスタンスのLGWRおよびインスタンスがクラッシュします。Oracle RACノードまたは単一インスタンス・データベースのクラッシュのリカバリでは、オンラインREDOログ内の最後にコミットされたトランザクションにリカバリされ、コミットされていないトランザクションがすべてロールバックされます。現在のログは完了し、Data Guard宛先にある有効になっているログ・アーカイブ先にアーカイブされます。
  • スタンバイでのREDOの欠落をもたらす障害: スタンバイ・データベースでREDOを受信する同期転送プロセスおよびリモート・ファイル・サーバー(RFS)プロセスで、スタンバイでのREDOの現在または最後のビットの欠落が検出された場合は、停止の原因に関係なく、RFSにより、欠落しているREDOの再送信がリクエストされ、それがスタンバイREDOログ(SRL)に直接書き込まれます。
  • データ損失ゼロ・フェイルオーバーの操作をもたらす停止: プライマリ・データベースがクラッシュして、自動または手動によるデータ損失ゼロ・フェイルオーバーが発生した場合は、Data Guardのフェイルオーバー操作によって"ターミナル・リカバリ"が実行され(recover managed standby finish操作を使用)、現在のSRLが読み取られリカバリされます。リカバリでSRL内のすべてのREDOの適用が完了すると、新しいプライマリ・データベースが起動され、それによって、新しく完了したオンライン・ログ・グループがアーカイブされます。新規および既存のスタンバイ・データベースすべてで、同じログ・グループ順序およびスレッドのREDOが破棄され、一貫性のあるSCNにフラッシュバックされ、新しいプライマリ・データベースからのアーカイブのみが適用されます。再度、Data Guard環境がプライマリ・データベース(新規)と同期された状態になります。逸脱やデータ損失はありません。

ネットワーク・タイムアウトの原因となる停止後の自動再接続

ハートビートARCHがネットワーク上でハングし、内部タイマーに基づいて強制終了されることがあるため、ネットワークまたはクラスタの障害による停止のケースのほうが複雑です。ハングしている転送プロセスを検出するための内部タイマーは、短いディスク/ネットワーク・コール用のアンダースコア・パラメータ_redo_transport_stall_timeと、ディスク/ネットワーク・コールの長いバージョン用のアンダースコア・パラメータ_redo_transport_stall_time_longで制御します。

ハートビートARCHが強制終了されると、別のARCHがハートビートARCHになり、'REOPEN + 1分 + <強制終了前のハング時間>'くらいが経過した後に、それによってネットワークへの接続が試みられます。そのハートビートARCHでスタンバイに再接続できる場合のみ、LGWRによってスタンバイ・データベースへの接続が試みられます。これにより、不要な影響がアプリケーションにもたらされることがなくなり、正常でないネットワークでLGWRがNetTimeoutによってハングすることがなくなります。

スタンバイ停止の解決後の自動再接続

ハートビートARCHは、スタンバイにpingを実行するように設計されている、プライマリ・データベースのARCHプロセスの1つです。ハートビートARCHでは、ネットワークが正常でありスタンバイに到達可能であるときは、1分ごとにスタンバイに'ping'が実行されます。これは、スタンバイで受信されたアーカイブ・ログ内の、ギャップを検出するために実行されます。ネットワーク障害が発生した場合は、最長でもREOPEN時間の間、ハートビートARCHによって接続が試みられません。ただし、スタンバイ通知と呼ばれる機能を使用してOracle Data Guardによって'REOPEN + 1分'より早く'リモート'の宛先がリセットされるという状態があります。スタンバイでのバウンスのケースでは(ネットワーク・ハングではない)、マウントされたスタンバイRFSまたはフェッチ・アーカイブ・ログ(FAL)によって、プライマリ・データベースと通信し、スタンバイが使用可能になったことが'通知'されます。このような場合、プライマリはREOPENを待たず、ポストされた直後にスタンバイに接続されます。

最大可用性とLGWR SYNC REDO転送を使用している場合、ネットワーク障害の発生後にスタンバイへの再接続を試行するのはハートビートARCHのみであることに注意してください。スタンバイにアクセス可能であることがハートビートARCHによってすでに確認されている場合を除き、障害発生後にLGWRによってスタンバイへの接続が試みられることはありません。

スタンバイ停止後の再接続のためのギャップ解決は、自動的に実行されます。たとえば、プライマリがログ順序100の途中であるときに、スタンバイ・データベースがクラッシュした後、プライマリがログ101、102および103を通って進むとします。スタンバイが使用可能になると、プライマリによってログが104に切り替えられ、その時点でASYNCまたはSYNC転送が開始されます。その後、ログ順序100の残りの部分が送信され、複数のアーカイブ・プロセスを使用して101、102および103が並行して送信されます。

停止の修復時間に影響するData Guard Brokerプロパティ

次のData Guard Brokerプロパティを構成すると、停止の修復時間を短縮できます。推奨値は、それらが使用されている環境によって異なり、アプリケーションへの影響を評価するためにテストする必要があります。

Data Guard Brokerプロパティ: NetTimeout

デフォルト値: 30秒

推奨値: ネットワークの応答性と信頼性が高い場合は5から10秒

同期REDO転送の宛先でそこに対して送信されたREDOデータの確認応答が送信されるまで待つ間、LGWRバックグラウンド・プロセスによって最長で何秒間ブロックされるかを指定します。NetTimeoutの秒数以内に確認応答が受信されない場合は、エラーがログに記録され、その宛先へのREDO転送セッションが終了します。

このプロパティは、ネットワーク障害、スタンバイ・ホスト障害、スタンバイ・クラスタ障害など、スタンバイ・プロセスとの同期転送プロセスがTCPタイムアウトになる停止すべてに対して有効です。NetTimeoutを5秒未満に設定しないでください。

Data Guard Brokerプロパティ: ReopenSecs

デフォルト値: 300秒

推奨値: 30秒

REDO転送サービスが失敗した宛先の再オープンを試行するまでの最小秒数を指定します。再オープンが期限切れになり、宛先がオープンされた後、次のログ・スイッチでそれが試みられます。

このプロパティは、スタンバイ・インスタンス/データベース/ノード/クラスタの停止、ネットワーク停止、同期転送プロセスの停止など、同期転送がエラー状態になり宛先がクローズされることになる停止すべてに対して有効です。

Data Guard Brokerプロパティ: MaxFailure

デフォルト値: なし

推奨値: アプリケーションの可用性とビジネスの要件によって異なります。

プライマリ・データベースが失敗した宛先を放棄する前に、REDO転送サービスが通信を再確立してその宛先へのREDOデータを転送する連続試行回数を制御します。

このプロパティは、スタンバイ・インスタンス/データベース/ノード/クラスタの停止、ネットワーク停止、同期転送プロセスの停止など、同期転送がエラー状態になり宛先がクローズされることになる停止すべてに対して有効です。

Data Guard Brokerプロパティ: FastStartFailoverThreshold

デフォルト値: 30秒

推奨値: ネットワークの応答性と信頼性が高い場合は6から15秒プライマリOracle RACインスタンスの場合は、最大クラスタウェア・ハートビート・タイムアウト(LinuxのCSSミスカウントのデフォルトは30秒です。Exadataの場合は、2秒を使用できます)をFastStartFailoverThresholdに追加します。

FastStartFailoverThreshold構成プロパティは、ターゲット・スタンバイ・データベースへのファスト・スタート・フェイルオーバーを開始するまでに、オブザーバーがプライマリ・データベースとの再接続を試行する時間(秒数)を指定します。この時間間隔は、オブザーバのプライマリ・データベースとの接続が最初に失われたときに開始されます。オブザーバが指定時間内にプライマリ・データベースへの接続を回復できない場合、オブザーバによりファスト・スタート・フェイルオーバーが開始されます。

このプロパティは、プライマリ・データベースの完全な停止が原因でスタンバイ・データベースへのフェイルオーバーが必要になる停止すべてに対して有効です。

データベース初期化パラメータ: FAST_START_MTTR_TARGET

デフォルト値: 0

推奨値: 想定されているリカバリ時間目標(RTO)のための必要な値

FAST_START_MTTR_TARGETでは、データベースで単一インスタンスのクラッシュ・リカバリが実行されるまでにかかる秒数を指定します。指定した場合、FAST_START_MTTR_TARGETはLOG_CHECKPOINT_INTERVALでオーバーライドされます。

このプロパティは、インスタンス障害など、データベースでインスタンス・リカバリを実行する必要がある停止すべてに対して有効です。このデータベース初期化パラメータを設定すると、データベースによって、その目標を達成するための試みにおいて、増分チェックポイント書込みが管理されます。増分チェックポイントがより頻繁に発生するようになる場合があり、それによってデータベース・ライター(DBWR)からのI/Oの量が増えます。このパラメータを小さくする前にテストを実行することをお薦めします。

Data Guardのスタンバイ・データベースの停止の修復

適用インスタンスの強制終了

テストの実行方法

  1. プライマリ・データベースでワークロードを開始します。
  2. プライマリ・データベースが最大可用性モードであることを確認します。
    select protection_mode,protection_level from v$database;
  3. 管理対象リカバリ・プロセス(MRP)を実行しているインスタンスを中断します。
    shutdown abort

確認対象

  • プライマリが非同期になるという通知
    LGWR: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (3135)
LGWR: Error 1041 disconnecting from destination LOG_ARCHIVE_DEST_2 standby host
  • プライマリが同期されるという通知
    Destination LOG_ARCHIVE_DEST_2 is SYNCHRONIZED

最初のログ・スイッチの後、PROTECTION_LEVELがRESYNCHRONIZATIONに下がります。 

SQL> select inst_id,protection_mode,protection_level from gv$database;

   INST_ID PROTECTION_MODE      PROTECTION_LEVEL
  -------- -------------------- --------------------
         1 MAXIMUM AVAILABILITY RESYNCHRONIZATION
         2 MAXIMUM AVAILABILITY RESYNCHRONIZATION

PROTECTION_LEVELは、2回目のログ・スイッチの後にMAXIMUM AVAILABILITYに戻ります。 

SQL> select inst_id,protection_mode,protection_level from gv$database;

   INST_ID PROTECTION_MODE      PROTECTION_LEVEL
    ------ -------------------- --------------------
         1 MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY
         2 MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY

プライマリでの想定されている影響

適用インスタンスが失われると、プライマリ・データベースによってただちにログが切り替えられて、宛先がRESYCHRONIZATION MODEに下げられます。プライマリがスタンバイに再接続できるようになり、欠落しているREDOを送信できるようになると、2回目のログ・スイッチが発生して、宛先がSYNCHRONOUSに昇格され、MAXIMUM AVAILABILITYが復元されます。

図18-1 適用インスタンスがクラッシュしたプライマリ・データベース・ワークロード


適用インスタンスがクラッシュしたプライマリ・データベース・ワークロード

スタンバイ・インスタンスが読取り専用でオープンされ、適用インスタンスが強制終了された場合は、すべてのスタンバイ・インスタンスがマウント状態になる必要があります。これは、alter database close normalを使用して実行されます。読取り専用の接続が多数あるためにこのクローズ操作に長い時間がかかる場合は、_ABORT_ON_MRP_CRASH=TRUEを設定します。データベース初期化パラメータABORT_ON_MRP_CRASH=TRUEを使用すると、スタンバイによって他のすべてのインスタンスが中断され再起動され、それらがマウント状態になります。

スタンバイ・データベースの強制終了(すべてのインスタンス)

テストの実行方法

  1. プライマリ・データベースでワークロードを開始します。
  2. プライマリ・データベースが最大可用性モードであることを確認します。
    select protection_mode,protection_level from v$database;
  3. shutdown abortを実行して、すべてのスタンバイ・データベース・インスタンスを同時に中断します。
    srvctl stop database -d <standby> -o abort

確認対象

  • プライマリが非同期になるという通知
    Destination LOG_ARCHIVE_DEST_2 is UNSYNCHRONIZED
  • プライマリが同期されるという通知
    Destination LOG_ARCHIVE_DEST_2 is SYNCHRONIZED

    ノート:

    この通知は、スタンバイが再起動された後にのみ発生します。

ログ・スイッチの後、PROTECTION_LEVELがRESYNCHRONIZATIONに下がります。 

SQL> select inst_id,protection_mode,protection_level from gv$database;

   INST_ID PROTECTION_MODE      PROTECTION_LEVEL
---------- -------------------- --------------------
         1 MAXIMUM AVAILABILITY RESYNCHRONIZATION
         2 MAXIMUM AVAILABILITY RESYNCHRONIZATION

プライマリでの想定されている影響

同期転送によって、インスタンスのクラッシュがすぐに検出されます。アプリケーションにさらにブラウンアウトが発生することはありません。スタンバイ・インスタンス全体が失われると、宛先をRESYCHRONIZATION MODEに下げるために、プライマリ・データベースによってただちにログが切り替えられます。プライマリは、スタンバイが少なくとも1つマウント状態に戻るまでMAXIMUM AVAILABILITYに戻りません。その時点で、REDOのギャップが解決され、ログ送信が再開される可能性があります。2回目の短いブラウンアウトは、スタンバイがプライマリで再度使用可能になったときに、構成をMAXIMUM AVAILABILITYに戻すための必要なログ・スイッチが原因で発生します。

図18-2 スタンバイ・データベースがクラッシュしたプライマリ・データベース・ワークロード


スタンバイ・データベースがクラッシュしたプライマリ・データベース・ワークロード

Oracle Active Data Guard遠隔同期 - 例と停止シナリオ

Oracle Active Data Guard遠隔同期は、2つ目のスタンバイ・データベースまたは複雑な操作を必要とせずに、リモート・スタンバイ・データベースへのデータ損失ゼロのフェイルオーバーを実行する機能です。遠隔同期では、これは、SYNC転送のプライマリの許容範囲内の距離に遠隔同期インスタンス(制御ファイル、サーバー・パラメータ・ファイル(SPFILE)、パスワード・ファイルおよびスタンバイ・ログ・ファイルのみを含む軽量Oracleインスタンス。データベース・ファイルやオンラインREDOログはない)をデプロイすることで可能になります。遠隔同期インスタンスは、SYNC転送によってプライマリからREDOを受け取り、ASYNC転送によってただちにそのREDOを最大29個のリモート・スタンバイ・データベースに転送します。遠隔同期インスタンスは、REDOをOracle Zero Data Loss Recovery Applianceに転送することもできます。

最大可用性モードで実行されている遠隔同期インスタンスの停止は、プライマリ・データベースがエラー通知を受信する間の一時的なブラウンアウト以外、プライマリ・データベースの可用性に影響しません。プライマリは、通知の受信後にデータベース・トランザクションの処理を再開します。ほとんどの場合、通知は即時ですが、net_timeoutのしきい値を満たすまでフォルト通知を一時停止するという特定のフォルト条件があります(デフォルトが30秒である、ユーザーが構成可能なData Guard Brokerプロパティ)。これは、最大可用性モードを使用するすべてのData Guard構成での標準操作です。Data Guardの自己修復メカニズムでは、切断の原因となった問題が解決されると、スタンバイ・データベースが自動的に再接続され再同期されます。このような同じ自動メカニズムが遠隔同期にも適用されます。

遠隔同期のコンテキストでの高可用性(HA)では、二重障害のシナリオの場合(たとえば、遠隔同期の停止の直後にプライマリ・データベースが停止した場合や、その逆の場合)にデータ損失の可能性をなくすか最小限にできるように取り組みます。このコンテキストでのHAは、複数の方法で実現できます。それぞれの方法にはそれ固有のトレードオフと考慮事項があります。それらを次の各項で説明します。リストされているオプションの組合せも実現可能です。

ターミナル・スタンバイを代替宛先として使用した高可用性

遠隔同期の停止中にデータ保護を維持する最も簡単な方法は、ターミナル・スタンバイを直接指す代替ログ・アーカイブ宛先(最終フェイルオーバー・ターゲット)を作成することです。WANネットワーク待機時間が原因でパフォーマンスに影響が及ばないようにするための最も有力な選択肢は、リモート宛先への非同期転送(ASYNC)です。ASYNCでは、データ損失ゼロに近い保護(1秒未満の保護なし状態)を実現できますが、スタンバイの確認応答を待たないため、データ損失ゼロを保証することはできません。REDO転送では、遠隔同期の停止中に、代替宛先を使用して自動的にフェイルオーバーされます。遠隔同期インスタンスが修復され、それによって操作が再開されると、転送が自動的にその遠隔同期インスタンスにスイッチバックされ、データ損失ゼロの保護が取り戻されます。

なお、ターミナル・スタンバイへのスイッチオーバー(計画されたロール・トランジション)の間に、構成の保護モードを最大パフォーマンスに下げて、ロール・トランジション・ターゲットでそのモードを適用できるようにする必要があります。保護モードと転送方法の変更は、停止時間なしの動的な操作です。

この方法の特徴は次のとおりです。

  • 管理対象の遠隔同期ハードウェアまたはインスタンスは増えません。
  • 遠隔同期インスタンスの停止中、データ損失ゼロの適用範囲が失われます。データ保護レベルは、遠隔同期インスタンスで操作を再開できるようになり、同期通信が再確立され、スタンバイ・データベースが完全に同期されるまで、ASYNC転送でのUNSYNCHRONIZEDに下がります。

この例に関連するData Guard Brokerプロパティは次のとおりです:

  • プライマリ(primary):

    RedoRoutes='(LOCAL : farsyncA FASTSYNC ALT=(standby ASYNC FALLBACK))';

    MaxFailure=1

    NetTimeout=15

    reopensecs=10

  • プライマリ遠隔同期"A" (farsyncA)

    RedoRoutes='(primary:standby ASYNC)';

    MaxFailure=1

    NetTimeout=15

    reopensecs=10

  • スタンバイ(standby):

    RedoRoutes='(LOCAL : primary ASYNC)';

    MaxFailure=1

    NetTimeout=15

    reopensecs=10

代替の遠隔同期インスタンスを使用した高可用性

遠隔同期が停止した場合にデータ保護を維持するためのより堅牢な方法は、2つ目の遠隔同期インスタンスを代替宛先としてデプロイすることです。前の例とは異なり、代替の遠隔同期インスタンスによって、1つ目の遠隔同期インスタンスが修復されている間にデータ保護レベルが最大パフォーマンス(ASYNC)に下がることがなくなります。

次の図は、この例でのアクティブな遠隔同期インスタンスに障害が発生したが、それが実行されていたサーバーがまだ動作している場合に、停止中に起こることを示しています。

  • プライマリ・データベースが代替遠隔同期インスタンスに接続している間、3秒から4秒の短いアプリケーション・ブラウンアウトがあります。
    • この障害状態では、NetTimeoutを待つことなく、エラーがただちにプライマリ・データベースに返されます。このブラウンアウトは、プロパティ設定((MaxFailure-1)*ReopenSecs) + 4秒に基づいて計算できます。
  • 構成が再同期される前に、プライマリ・データベースに影響する2回目の停止が発生した場合にもたらされる可能性がある最大データ損失は、プライマリが代替遠隔同期インスタンスに再接続し構成が再同期される間に生成されるREDOの量によって異なります。

図18-3 代替遠隔同期インスタンスにフェイルオーバーしたプライマリ・データベース・ワークロード


代替遠隔同期インスタンスにフェイルオーバーしたプライマリ・データベース・ワークロード

遠隔同期インスタンスが実行されているサーバーがクラッシュした障害状態の場合は、動作が若干異なります。アプリケーションのブラウンアウトはさらにNetTimeout秒長くなります。また、再同期が完了するまでに必要な処理が増えるため、2回目の停止がプライマリに影響した場合のデータ損失の潜在的な危険性が高まります。

この方法の特徴は次のとおりです。

  • 遠隔同期インスタンスが修復されてサービスに戻る前に、プライマリ・データベースに影響する2回目の停止が発生した場合の、データ損失の危険性の低下。
  • スタンバイ・データベースをプライマリ・ロールに昇格させるロール・トランジション(計画スイッチオーバー)の後にデータ損失ゼロの保護を維持できる対称構成(元のプライマリがデータ損失ゼロ・フェイルオーバー・ターゲットになる)。代替宛先があるSQL*Plus構成では最初のログ・アーカイブ先が使用可能になったときに自動的にそちらにフォールバックされることに注意してください。Data Guard Broker構成内の、RedoRoutesプロパティでのFALLBACKキーワードを使用して、この動作を有効にします。

この例に関連する構成Data Guard Brokerプロパティは次のとおりです:

  • プライマリ(primary):

    RedoRoutes='(LOCAL : farsyncA FASTSYNC ALT=(farsyncB ASYNC FALLBACK))';

    MaxFailure=1

    NetTimeout=15

    reopensecs=10

  • プライマリ遠隔同期"A" (farsyncA)

    RedoRoutes='(primary:standby ASYNC)';

    MaxFailure=1

    NetTimeout=15

    reopensecs=10

  • 遠隔同期"B" (farsyncB)

    RedoRoutes='(primary:standby ASYNC)';

    MaxFailure=1

    NetTimeout=15

    reopensecs=10

  • スタンバイ(standby):

    RedoRoutes='(LOCAL : SBfarsyncA FASTSYNC ALT=(SBfarsyncB ASYNC FALLBACK))';

    MaxFailure=1

    NetTimeout=15

    reopensecs=10

  • スタンバイ遠隔同期"A" (SBfarsyncA)

    RedoRoutes='(standby:primary ASYNC)';

    MaxFailure=1

    NetTimeout=15

    reopensecs=10

  • スタンバイ遠隔同期"B" (SBfarsyncB)

    RedoRoutes='(standby:primary ASYNC)';

    MaxFailure=1

    NetTimeout=15

    reopensecs=10

Oracle Real Application Clustersを使用した遠隔同期

遠隔同期インスタンスをOracle RACに配置することもできます。この構成では、遠隔同期は一度に1つのサーバーでのみアクティブになり、他のサーバーではHAのための自動フェイルオーバーが提供されます。

この方法の特徴は次のとおりです。

  • 遠隔同期インスタンスに障害が発生した場合のアプリケーション・ブラウンアウトが最短です。
  • 遠隔同期インスタンスに障害が発生した後にデータ損失ゼロの保護が最も早く再開されます。
  • このソリューションはそれ自体でクラスタ障害に対処するわけではありません。クラスタが使用不可になった場合にデータ保護を維持するには、代替宛先を構成する必要があります。

Oracle RACクラスタでの遠隔同期インスタンスの障害

次の図は、すべてのOracle RACノードがまだ機能しているときに、REDOを受信する遠隔同期インスタンスに障害が発生した場合の、アプリケーション・スループットとデータ保護への影響を示しています。

図18-4 RACの遠隔同期インスタンスに障害が発生したプライマリ・データベース・ワークロード


RACの遠隔同期インスタンスに障害が発生したプライマリ・データベース・ワークロード

このユースケースでは、アクティブな遠隔同期インスタンスに障害が発生すると、Oracle RACによって停止がただちに検出され、REDO転送が、障害が発生していないOracle RACノードの1つにあるすでに実行中の遠隔同期インスタンスに自動的にフェイルオーバーされます(これを発生させるために代替宛先を定義する必要はありません)。インスタンスのフェイルオーバーの間に、エラー通知の確認応答と処理のために、1秒未満の非常に短いアプリケーション・ブラウンアウトが発生します(net_timeoutはこのエラー状態には適用されません)。構成は最大可用性保護レベルのままであり、クラスタ内の1つのノードから次のノードへのトランジションの間、データ損失ゼロの保護が維持されます。新しい遠隔同期インスタンスでそのクラスタの共有ストレージにある既存のSRLにアクセスできるため、再転送は必要ありません。高速な検出と、データ損失ゼロの保護が中断されないことは、Oracle RACを使用して遠隔同期インスタンスをホストする大きな利点です。

Oracle RACクラスタでのノード(サーバー)障害

次の図は、Oracle RACのノード障害(アクティブな遠隔同期インスタンスが実行されているサーバーの停止)の影響を示しています。ノード障害によって、Data GuardのNetTimeoutプロパティと同等の短いブラウンアウトが発生して、アプリケーション・スループットの最初の低下が起こります。その後、Data GuardのREDO転送によって、障害が発生していないノードとの接続が再確立されている間に、2回目のブラウンアウトが発生します。この場合は、ノード障害によってData Guardが再同期状態になるため、データ損失の可能性が高くなります。Data Guardによって、プライマリとスタンバイが迅速に再同期され、新しい接続の確立後に構成がデータ損失ゼロの保護レベルに戻されます。構成の再同期に必要な時間は、障害が発生していないインスタンスに送信する必要があるREDOの量によって異なります。

図18-5 RACの遠隔同期ノードに障害が発生したプライマリ・データベース・ワークロード


RACの遠隔同期ノードに障害が発生したプライマリ・データベース・ワークロード

プライマリ・データベースの停止の修復

次のトピックでは、Oracle Data Guard構成のプライマリ側で発生する可能性がある様々な停止について、停止修復を説明します。

同期転送プロセスの停止

テストの実行方法

  1. プライマリ・データベースでワークロードを開始します。
  2. プライマリ・データベースが最大可用性モードであることを確認します。
    select protection_mode,protection_level from v$database;
  3. 1つのインスタンスについてNSSプロセスを見つけます。
    ps -aef | grep ora_nss
  4. そのNSSプロセスを強制終了します。
    kill -9 <pid>

確認対象

  • プライマリが非同期になるという通知
    Destination LOG_ARCHIVE_DEST_2 is UNSYNCHRONIZED
  • プライマリが同期されるという通知
    Destination LOG_ARCHIVE_DEST_2 is SYNCHRONIZED

最初のログ・スイッチの後、PROTECTION_LEVELがRESYNCHRONIZATIONに下がります。 

SQL> select inst_id,protection_mode,protection_level from gv$database;

   INST_ID PROTECTION_MODE      PROTECTION_LEVEL
   ------- -------------------- --------------------
         1 MAXIMUM AVAILABILITY RESYNCHRONIZATION
         2 MAXIMUM AVAILABILITY RESYNCHRONIZATION

PROTECTION_LEVELは、2回目のログ・スイッチの後にMAXIMUM AVAILABILITYに戻ります。 

SQL> select inst_id,protection_mode,protection_level from gv$database;

INST_ID PROTECTION_MODE      PROTECTION_LEVEL
------- -------------------- --------------------
      1 MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY
      2 MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY

プライマリでの想定されている影響

プライマリで同期転送プロセスが失われた場合は、LGWRによって、約10秒で同期転送の停止が検出され、その後、宛先をRESYCHRONIZATIONモードに下げるためにログ・スイッチが発生します。最長で60秒後に、ハートビートARCHによって同期転送プロセスの再起動が開始され、その後に、宛先をMAXIMUM AVAILABILITYに昇格するためのログ・スイッチが発生します。

プライマリ・データベースとスタンバイ・データベースの間のネットワークの損失

テストの実行方法

  1. スタンバイのプロパティNetTimeoutを30または5に、MaxFailureを1に設定します。
  2. プライマリ・データベースでワークロードを開始します。
  3. プライマリ・データベースが最大可用性モードであることを確認します。
    select protection_mode,protection_level from v$database;

    図18-6 同期転送プロセスが失われたプライマリ・データベース・ワークロード


    同期転送プロセスが失われたプライマリ・データベース・ワークロード

  4. プライマリによってrootとして使用されているスタンバイ・インタフェースを停止します。
    ifdown eth0

確認対象

  • プライマリが非同期になるという通知
    Destination LOG_ARCHIVE_DEST_2 is UNSYNCHRONIZED

ノート:

ネットワークが回復し、宛先のFAILURE_COUNTがリセットされ、プライマリがスタンバイに再接続されるまで、宛先は再同期されません。

ノート:

宛先の失敗数が、指定されているMaxFailureプロパティ値に達した場合に、その宛先を再使用するための方法は、MaxFailureプロパティ値を変更するか(それを適格な現在の値に設定する)、任意のプロパティを変更することのみです。この結果、障害件数がゼロ(0)にリセットされます。

プライマリへの想定されている影響

ネットワークが失われると、プライマリにより、そのネットワークを待機しているNetTimeout秒の間、すべての処理が凍結されます。MaxFailure=1が指定されている場合は、NetTimeoutが期限切れになると、宛先がRESYNCHRONIZATIONに下がり、保護されていない状態で処理が続行されます。NetTimeoutは、5未満に設定せず、5に設定するのは、待機時間が短い信頼性の高いネットワークに対してのみにしてください。

図18-7 スタンバイ・ネットワークが失われたプライマリ・データベース・ワークロード


スタンバイ・ネットワークが失われたプライマリ・データベース・ワークロード

プライマリ・インスタンスの停止

テストの実行方法

  1. プライマリ・データベースでワークロードを開始します。
  2. プライマリ・データベースが最大可用性モードであることを確認します。
    select protection_mode,protection_level from v$database;
  3. プライマリのインスタンス1つを中断します。
    shutdown abort

確認対象

  • 再同期のための低下のアラート・ログに明示的な警告は含まれませんが、インスタンスが失われたことが原因でありインスタンスのリカバリが必要であることが、暗黙的に示されています。
  • 再構成とインスタンス・リカバリの通知
    Reconfiguration started (old inc 3, new inc 5)
<...>
Instance recovery: looking for dead threads
<...>
Completed instance recovery at
  • プライマリが同期されるという通知
    Client pid [#####] attached to RFS pid [#####] at remote instance number [#] at dest '<standby>'

プライマリでの想定されている影響

インスタンスが失われた後、障害が発生していないインスタンスの1つでインスタンス・リカバリが実行されます。また、リモートの宛先を再初期化した後にログ・スイッチを実行して、構成をMAXIMUM AVAILABILITY保護に戻す必要があります。

図18-8 プライマリ・インスタンスに障害が発生したRACのプライマリ・データベース・ワークロード


プライマリ・インスタンスに障害が発生したRACのプライマリ・データベース・ワークロード

プライマリ・データベースの停止とフェイルオーバー

テストの実行方法

  1. プライマリ・データベースでワークロードを開始します。
  2. プライマリ・データベースが最大可用性モードであることを確認します。
    select protection_mode, protection_level from v$database;
  3. プライマリ・データベースを中断します。
    shutdown abort
  4. 手動またはファスト・スタート・フェイルオーバー(FSFO)を使用して、スタンバイへのフェイルオーバーを開始します。

確認対象

  • 初期スタンバイのアラート・ログ内のフェイルオーバーの開始
    Data Guard Broker: Beginning failover
  • 初期スタンバイのアラート・ログ内のフェイルオーバーの完了
    Failover succeeded. The primary database is now ‘<standby>’

プライマリでの想定されている影響

フェイルオーバー後に、プライマリ・データベースがオープンされて、アプリケーションにデータベースの可用性が提供されます。MAXIMUM AVAILABILITY保護は、古いプライマリ・データベースが回復し再同期されるまで復元されません。

図18-9 プライマリ・データベースがクラッシュしフェイルオーバーされたプライマリ・データベース・ワークロード


プライマリ・データベースがクラッシュしフェイルオーバーされたプライマリ・データベース・ワークロード