Sun Cluster Geographic Edition Oracle Data Guard 向けデータ複製ガイド

第 3 章 Oracle Data Guard データ複製を使用するサービスの移行

この章では、保守管理を行う場合やクラスタ障害が発生した場合のサービスの移行について説明します。

この章の内容は次のとおりです。

Oracle Data Guard データ複製を使用するシステム上でのクラスタの障害の検出

この節では、主クラスタまたはスタンバイクラスタで障害が検出される際に発生する内部プロセスについて説明します。

主クラスタの障害の検出

ある保護グループの主クラスタに障害が発生すると、パートナーシップのスタンバイクラスタがその障害を検出します。障害が発生するクラスタが複数のパートナーシップのメンバーである場合、障害の検出が複数発生する可能性があります。

保護グループ全体の状態が Unknown 状態に変化すると、次の動作が発生します。

ハートビート異常がパートナークラスタによって検出されます。
ハートビート喪失が一時的なものではないことと、主クラスタに障害が発生していることを確認するため、緊急モードでハートビートが有効になります。このデフォルトのタイムアウト間隔の間、つまり、ハートビート機構が主クラスタの状態を確認 (照会) しようと再試行している間、ハートビートは OK 状態のままです。Error 状態ではハートビートのプラグインだけが現れます。

ハートビートの Query_interval プロパティーを設定することにより、この照会間隔を設定します。設定した Query_interval が 4 回 (再試行 3 回と緊急モード検証 1 回) 経過してもハートビート異常が続く場合は、heartbeat-lost イベントが生成され、システムログに記録されます。デフォルトの照会間隔を指定する場合、緊急モードの再試行動作によって、ハートビート喪失通知は約 9 分間遅れる可能性があります。メッセージは、GUI と geoadm status コマンドの出力に表示されます。

ログについては、『Sun Cluster Geographic Edition のシステム管理』の「Sun Cluster Geographic Edition のログメッセージの表示」を参照してください。

スタンバイクラスタの障害の検出

ある保護グループのスタンバイクラスタに障害が発生すると、同じパートナーシップのクラスタがその障害を検出します。障害が発生したクラスタが複数のパートナーシップのメンバーである場合、障害の検出が複数発生する可能性があります。

障害の検出中、次のアクションが発生します。

ハートビート異常がパートナークラスタによって検出されます。
二次クラスタに障害が発生したことを確認するため、ハートビートが緊急モードでアクティブ化されます。
クラスタはメッセージを発行して管理者に通知します。障害が発生したクラスタがスタンバイクラスタとして動作しているすべての保護グループが検出されます。これらの保護グループは Unknown 状態に設定されています。

Oracle Data Guard を使用するサービスをスイッチオーバーで移行する

パートナークラスタにサービスを順番に移行する場合は、Oracle Data Guard 保護グループのスイッチオーバーを実行します。スイッチオーバーでは、次の処理が実行されます。

元の主クラスタ cluster-paris 上で、アプリケーションサービスがアンマネージ状態になります。

どのクラスタが cluster-paris かを確認するために、『Sun Cluster Geographic Edition のシステム管理』の「Sun Cluster Geographic Edition クラスタ構成の例」を参照してください。
データ複製の役割が逆になり、今度は、新しい主クラスタ cluster-newyork から元の主クラスタ cluster-paris に対して継続して複製が行われます。
アプリケーションサービスおよび Oracle シャドウ RAC サーバープロキシリソースグループは、新しい主クラスタ cluster-newyork 上でオンラインになります。

この節では、次の内容について説明します。

Oracle Data Guard 保護グループを主クラスタからスタンバイクラスタにスイッチオーバーする方法

始める前に

スイッチオーバーを行うには、主クラスタとスタンバイクラスタ間のデータ複製が有効になっている必要があります。つまり、Oracle Data Guard Broker 構成が有効な状態です。さらに Oracle Data Guard Broker show configuration コマンドによって、SUCCESS 状態が示される必要があります。この状態は、Oracle Data Guard Broker 構成の Sun Cluster Geographic Edition 複製リソースの状態に反映され、構成によって online 状態が示されるはずです。

主クラスタからスタンバイクラスタへ保護グループのスイッチオーバーを行うには、次の条件が満たされている必要があります。

両方のクラスタで Sun Cluster Geographic Edition ソフトウェアが動作している。
スタンバイクラスタがパートナーシップのメンバーである。
両方のクラスタパートナーが互いに到達可能である。
保護グループの全体的な状態が OK に設定されている。

クラスタノードの 1 つにログインします。

この手順を完了するには、ユーザーに Geo Management RBAC 権利プロファイルが割り当てられている必要があります。 RBAC の詳細は、『Sun Cluster Geographic Edition のシステム管理』の「Sun Cluster Geographic Edition ソフトウェアと RBAC」を参照してください。

スイッチオーバーを開始します。

スイッチオーバーでは、保護グループに属するアプリケーションリソースグループの停止と起動が行われます。
phys-node-n# geopg switchover [-f] -m newprimarycluster protectiongroupname
-f

ユーザーに確認することなく、強制的にコマンドを実行します。

-m newprimarycluster

保護グループの主クラスタにするクラスタの名前を指定します。

protectiongroupname

保護グループの名前を指定します。

例 3–1 主クラスタからスタンバイクラスタへの強制的なスイッチオーバー

この例では、スタンバイクラスタへのスイッチオーバーを行う方法について説明します。

phys-paris-1# geopg switchover -f -m cluster-newyork sales-pg

スイッチオーバー中に Sun Cluster Geographic Edition ソフトウェアが実行する処理

geopg switchover コマンドを実行すると、ソフトウェアにより、主クラスタがプライマリデータベースを保持していることが確認されます。このコマンドによって、リモートデータベースが Oracle Data Guard Broker 構成内で enabled 状態であることが確認されます。また、このコマンドによって構成が健全であることも確認されます。このコマンドでは、Oracle Data Guard コマンド行インタフェース (dgmgrl) show configuration コマンドを実行して、SUCCESS 状態が返されることを確認します。このコマンドからの出力に、Oracle Data Guard Broker が自身の健全性検査のためビジー状態であることが示される場合、Oracle Data Guard コマンド行インタフェースは、SUCCESS 応答を受信するまで、または 2 分経過するまでこのコマンドを再試行します。このコマンド行インタフェースが SUCCESS 応答を受け取れない場合、コマンドの実行は失敗します。構成が健全な場合、ソフトウェアにより、元の主クラスタに対して次の処理が実行されます。

アプリケーションリソースグループをオフラインにし、unmanaged 状態にします
保護グループ内の各 Oracle Data Guard Broker 構成に対して switchover to standby-database-name コマンドを実行します。

元のスタンバイクラスタでは、同じコマンドによって次の処理が行われます。

RoleChange_ActionCmd プロパティーに定義されているスクリプトを実行します
すべての Oracle シャドウ RAC サーバープロキシリソースグループとその他すべてのアプリケーションリソースグループをオンラインにします。

コマンドが正常に実行された場合、スタンバイクラスタ cluster-newyork が保護グループの新しい主クラスタになります。元の主クラスタ cluster-paris は新しいスタンバイクラスタになります。ローカルクラスタ上の保護グループの役割に従って、保護グループの Oracle Data Guard Broker 構成と関連付けられているデータベースの役割が逆転します。Oracle シャドウ RAC サーバープロキシリソースグループとその他すべてのアプリケーションリソースグループは、新しい主クラスタ上でオンラインになります。新しい主クラスタから新しいスタンバイクラスタへのデータ複製が開始されます。

このコマンドは、それまでの操作のうち 1 つでも失敗したものがあると、エラーを返します。個々のコンポーネントの状態を表示するには、geoadm status コマンドを実行します。失敗の原因によっては、保護グループの Configuration の状態が Error に設定されることがあります。保護グループは、有効になっている場合と無効になっている場合があります。

保護グループの Configuration の状態が Error に設定されている場合は、「Oracle Data Guard 保護グループを検証する方法」の手順に従って、保護グループを再検証します。

個々のパートナークラスタ上で保護グループの構成が一致していない場合は、「Oracle Data Guard 保護グループを再同期する方法」の手順に従って、構成を再同期させる必要があります。

Oracle Data Guard を使用するシステム上での強制テイクオーバー

プライマリデータベースとスタンバイデータベースのデータが完全に整合しているかどうかにかかわらずスタンバイクラスタ上でアプリケーションをオンラインにする必要がある場合は、テイクオーバーを実行します。この節では、保護グループが起動されていることを前提とします。

テイクオーバーを開始したあとで、次の処理が行われます。

以前の主クラスタ cluster-paris が到達可能であり、保護グループが通知処理またはそれ以外の理由でロックされていない場合は、保護グループが無効になります。

どのクラスタが cluster-paris かを確認するために、『Sun Cluster Geographic Edition のシステム管理』の「Sun Cluster Geographic Edition クラスタ構成の例」を参照してください。
以前の主クラスタ cluster-paris からテイクオーバー中の保護グループに存在する Oracle Data Guard Broker 構成に複製されたデータベースは、新しい主クラスタ cluster-newyork によってテイクオーバーされます。

注 –
このデータは、元の主クラスタのデータベースとは一致していないことがあります。新しい主クラスタ cluster-newyork から元の主クラスタ cluster-paris へのデータ複製が停止します。
データ複製を有効にすることなく、保護グループが有効になります。テイクオーバーされる各 Oracle Data Guard Broker 構成の元のプライマリデータベースは無効になり、recovery required 状態になります。

テイクオーバーの前後で考えられる主クラスタとスタンバイクラスタの条件については、『Sun Cluster Geographic Edition のシステム管理』の付録 C「テイクオーバー後の状態」を参照してください。

この節では、次の内容について説明します。

Oracle Data Guard サービスをスタンバイクラスタへ即時にテイクオーバーを強制する方法

始める前に

スタンバイクラスタに主クラスタの処理を引き受けさせるためには、次の条件が満たされている必要があります。

クラスタ上で Sun Cluster Geographic Edition ソフトウェアが稼働中である。
クラスタがパートナーシップのメンバーである。
スタンバイクラスタ上で保護グループの Configuration の状態が OK に設定されている。

スタンバイクラスタ内のノードの 1 つにログインします。

この手順を完了するには、ユーザーに Geo Management RBAC 権利プロファイルが割り当てられている必要があります。 RBAC の詳細は、『Sun Cluster Geographic Edition のシステム管理』の「Sun Cluster Geographic Edition ソフトウェアと RBAC」を参照してください。

テイクオーバーを開始します。
phys-node-n# geopg takeover [-f] protectiongroupname
-f

ユーザーに確認することなく、強制的にコマンドを実行します。

protectiongroupname

保護グループの名前を指定します。

例 3–2 スタンバイクラスタによる強制テイクオーバー

この例では、sales-pg を、スタンバイクラスタ cluster-newyork によって強制的にテイクオーバーする方法を示します。

ノード phys-newyork-1 はスタンバイクラスタの 1 番目のノードです。どのノードが phys-newyork-1 かを確認する場合は、『Sun Cluster Geographic Edition のシステム管理』の「Sun Cluster Geographic Edition クラスタ構成の例」を参照してください。

phys-newyork-1# geopg takeover -f sales-pg

次の手順

テイクオーバー後の主クラスタとスタンバイクラスタの状態については、『Sun Cluster Geographic Edition のシステム管理』の付録 C「テイクオーバー後の状態」を参照してください。

テイクオーバー中に Sun Cluster Geographic Edition ソフトウェアが実行する処理

geopg takeover コマンドを実行すると、ソフトウェアにより、スタンバイクラスタ上の Oracle Data Guard Broker 構成内のデータベースが有効であることが確認されます。このデータベースはテイクオーバー後にプライマリデータベースになります (無効なデータベースへのテイクオーバーは実行できません）。また、ソフトウェアにより、Oracle Data Guard コマンド行インタフェース show configuration コマンドが SUCCESS 状態を示すか、または健全性検査のためビジー状態であるかが確認されます (ORA-16610)。show configuration コマンドによってその他の Oracle エラーコードが返される場合は、テイクオーバーは失敗します。

元の主クラスタ cluster-paris に到達できる場合は、ソフトウェアにより、アプリケーションリソースグループはオフライン状態となり、Unmanaged 状態になります。

元のスタンバイクラスタ cluster-newyork 上で、ソフトウェアにより、次の処理が実行されます。

Oracle Data Guard コマンド行インタフェース failover to standby-database-name immediate コマンドを実行します。
RoleChange_ActionCmd プロパティーによって指定されているスクリプトを実行します。
テイクオーバー前に元のスタンバイクラスタで保護グループが有効だった場合、すべての Oracle シャドウ RAC サーバープロキシリソースグループおよびアプリケーションリソースグループをオンラインにします。

コマンドが正常に実行された場合、スタンバイクラスタ cluster-newyork が保護グループの新しい主クラスタになります。ローカルクラスタ上の保護グループの役割に従って、保護グループの Oracle Data Guard Broker 構成と関連付けられているデータベースの役割が逆転します。Oracle シャドウ RAC サーバープロキシリソースグループとその他のアプリケーションリソースグループは、新しい主クラスタ上でオンラインになります。元の主クラスタにアクセスできる場合、このクラスタが保護グループの新しいスタンバイクラスタになります。保護グループの Oracle Data Guard Broker 構成に関連付けられているすべてのデータベースの複製は停止されます。

注意 –

テイクオーバーが正常に完了すると、データ複製は停止します。複製を引き続き中断したままにする場合は、geopg start コマンドを -n オプション付きで実行します。このオプションを指定すると、新しい主クラスタから新しいスタンバイクラスタへのデータ複製が行われません。

以前の操作に失敗する場合、コマンドによって、エラーが返されます。個々のコンポーネントの状態を表示するには、geoadm status コマンドを実行します。たとえば、失敗の原因によっては、保護グループの Configuration の状態が Error 状態に設定されることがあります。保護グループは、有効になっている場合と無効になっている場合があります。

保護グループの Configuration の状態が Error 状態に設定されている場合は、「Oracle Data Guard 保護グループを検証する方法」の手順に従って、保護グループを再検証します。

テイクオーバー後の Oracle Data Guard データの回復

テイクオーバーが正常に完了すると、スタンバイクラスタ cluster-newyork が保護グループの主クラスタになり、このスタンバイクラスタ上でサービスがオンラインになります。元の主クラスタが回復したところで、フェイルバックと呼ばれる処理を行って元の主クラスタ上でふたたびサービスをオンラインにすることができます。

Sun Cluster Geographic Edition ソフトウェアでは、次の 2 種類のフェイルバックがサポートされています。

フェイルバックスイッチオーバー。フェイルバックスイッチオーバーの場合、アプリケーションは、元の主クラスタ cluster-paris のデータがスタンバイクラスタ cluster-newyork のデータと再同期されたあとで、元の主クラスタでオンラインに戻ります。

どのクラスタが cluster-paris と cluster-newyork かを確認するために、『Sun Cluster Geographic Edition のシステム管理』の「Sun Cluster Geographic Edition クラスタ構成の例」を参照してください。
フェイルバックテイクオーバー。フェイルバックテイクオーバーの場合、アプリケーションは元の主クラスタ上で再度オンラインに戻って、主クラスタ上の現在のデータを使用します。スタンバイクラスタ上で更新が行われていたとしても、その内容は破棄されます。

元の主クラスタが再起動したあとで、新しい主クラスタ cluster-newyork を主クラスタのままにして、元の主クラスタ cluster-paris をスタンバイクラスタとして使う場合は、保護グループ構成を再同期し、再検証できます。スイッチオーバーやテイクオーバーを実行することなく、保護グループを再同期し、再検証できます。

この節では、次の手順の実行方法について説明します。

保護グループの構成を再同期させて再検証する

次の手順を実行して、元の主クラスタ cluster-paris 上のデータと現在の主クラスタ cluster-newyork との間でデータの再同期と再検証を行います。

始める前に

保護グループ構成の再同期と再検証を行う前、cluster-newyork ではすでにテイクオーバーが発生しています現在のクラスタの役割は次のとおりです。

cluster-newyork 上の保護グループには primary の役割が割り当てられています。
cluster-paris 上の保護グループの役割は、cluster-newyork からのテイクオーバー中に cluster-paris に到達できたかどうかによって、primary の役割または secondary の役割のいずれかになります。

元の主クラスタ cluster-paris が停止していた場合は、そのクラスタが起動していることと、そのクラスタで Sun Cluster Geographic Edition インフラストラクチャーが有効であることを確認します。

クラスタの起動については、『Sun Cluster Geographic Edition のシステム管理』の「クラスタの起動」を参照してください。

元の主クラスタ cluster-paris を現在の主クラスタ cluster-newyork と再同期させます。

この操作により、クラスタ cluster-paris の独自の構成は削除され cluster-newyork の構成がローカルに複製されます。パートナーシップ構成と保護グループ構成の両方を再同期させます。
1. cluster-paris 上で、ローカルクラスタ上の保護グループを無効にします。
  phys-paris-1# geopg stop -e local protectiongroupname
  -e local
  
  コマンドの範囲を指定します。
  
  範囲を local と指定すると、ローカルクラスタだけがコマンドの対象となります。
  
  注 –
  global や local などのプロパティー値では、大文字と小文字は区別されません。
  
  protectiongroupname
  
  保護グループの名前を指定します。
  
  保護グループがすでに無効化されている場合、アプリケーションリソースグループが管理されてオフラインになっているため、保護グループ内のリソースグループの状態は Error になっている可能性があります。
  
  保護グループが無効化されている場合、アプリケーションリソースグループはすでに管理されていない状態であるため、Error 状態はクリアされます。
2. cluster-paris で、パートナーシップを再同期させます。
  phys-paris-1# geops update partnershipname
  注 –
  複数の保護グループを再同期させている場合でも、この手順は 1 回実行するだけで済みます。
  
  パートナーシップの同期については、『Sun Cluster Geographic Edition のシステム管理』の「パートナーシップの再同期」を参照してください。
3. cluster-paris で、各保護グループを再同期させます。
  
  cluster-newyork 上の保護グループの役割は primary であるため、この手順により cluster-paris 上の保護グループの役割が secondary であることが確認されます。
  phys-paris-1# geopg update protectiongroupname
  保護グループの同期については、「Oracle Data Guard 保護グループを再同期する」を参照してください。

cluster-paris 上で、個々の保護グループのクラスタ構成を検証します。
phys-paris-1# geopg validate protectiongroupname
詳細は、「Oracle Data Guard 保護グループを検証する方法」を参照してください。

cluster-paris で、各保護グループを有効にします。

保護グループを有効にすると、その保護グループのアプリケーションリソースグループもオンラインになります。
phys-paris-1# geopg start -e global protectiongroupname
-e Global

コマンドの範囲を指定します。

global スコープを指定すると、保護グループが配置されている両方のクラスタがコマンドの対象となります。

注 –
global や local などのプロパティー値では、大文字と小文字は区別されません。

protectiongroupname

保護グループの名前を指定します。

注意 –
現在の主クラスタ -cluster-newyork から現在のスタンバイクラスタ cluster-paris にデータを再同期させる必要があるため、n オプションを使用しないでください。

保護グループの役割が secondary であるため、データの同期化は現在の主クラスタ cluster-newyork から現在のスタンバイクラスタ cluster-paris へと行われます。

geopg start コマンドの詳細は、「Oracle Data Guard 保護グループを有効にする方法」を参照してください。

すべてのデータが同期化されたことを確認します。
1. cluster-newyork 上の保護グループの状態が OK であることを確認します。
  phys-newyork-1# geoadm status
  出力の保護グループセクションを参照してください。
2. 複製リソースグループ ODGprotectiongroupname-odg-rep-rg 内のすべてのリソースの状態が OK であることを確認します。
  phys-newyork-1# clresource status -v ODGprotectiongroupname-odg-rep-rs

Oracle Data Guard 複製を使用するシステム上でフェイルバックスイッチオーバーを実行する方法

この手順は、元の主クラスタ cluster-paris のデータが現在の主クラスタ cluster-newyork のデータと再同期されたあとで、アプリケーションを元の主クラスタで再起動するときに実行します。

フェイルバックの手順はパートナーシップ内のクラスタにのみ適用されます。ここでの手順はパートナーシップごとに 1 回実行するだけで済みます。

始める前に

フェイルバックスイッチオーバーを実行する前に cluster-newyork でテイクオーバーが発生していたことがあります。現在のクラスタの役割は次のとおりです。

cluster-newyork 上の保護グループには primary の役割が割り当てられています。
cluster-paris 上の保護グループの役割は、cluster-newyork クラスタからのテイクオーバー中に cluster-paris クラスタに到達できたかどうかによって、primary の役割または secondary の役割のいずれかになります。

元の主クラスタ cluster-paris に障害が発生した場合は、そのクラスタが再起動していることと、そのクラスタで Sun Cluster Geographic Edition インフラストラクチャーが有効であることを確認します。

クラスタの再起動については、『Sun Cluster Geographic Edition のシステム管理』の「クラスタの起動」を参照してください。

障害が発生した Oracle Data Guard 主データベースを新しいスタンバイとして回復および復元します。

この手順の実行方法についての詳細は、 Oracle のマニュアルを参照してください。

元の主クラスタ、cluster-paris が Oracle Data Guard 構成の一部分として正常に動作していることを確認します。
oracle (phys-paris-1)$ dgmgrl sys/sysdba_password@sales-svc DGMGRL> show configuration;
元の主クラスタ、cluster-paris が正常に動作していた場合、show configuration コマンドが、SUCCESS 状態を表示します。

元の主クラスタが障害発生時に停止した場合、非アクティブな主クラスタとしてマークされます。元の主クラスタが障害時点時に起動した場合、非アクティブなセカンダリとしてマークされます。

元の主クラスタ cluster-paris を現在の主クラスタ cluster-newyork と再同期させます。

この操作により、クラスタ cluster-paris の独自の構成は削除され cluster-newyork の構成がローカルに複製されます。パートナーシップ構成と保護グループ構成の両方を再同期させます。
1. cluster-paris で、パートナーシップを再同期させます。
  phys-paris-1# geops update partnershipname
  注 –
  パートナーシップ内の複数の保護グループに対してフェイルバックスイッチオーバーを実行している場合でも、この手順はパートナーシップごとに 1 回実行するだけで済みます。
  
  パートナーシップの同期については、『Sun Cluster Geographic Edition のシステム管理』の「パートナーシップの再同期」を参照してください。
2. 元の主クラスタである cluster-paris 上の保護グループが有効であるかどうかを判定します。
  phys-paris-1# geoadm status
3. 元の主クラスタ上の保護グループが有効である場合は、その保護グループを停止します。
  phys-paris-1# geopg stop -e local protectiongroupname
  -e local
  
  コマンドの範囲を指定します。
  
  範囲を local と指定すると、ローカルクラスタだけがコマンドの対象となります。
  
  注 –
  global や local などのプロパティー値では、大文字と小文字は区別されません。
  
  protectiongroupname
  
  保護グループの名前を指定します。
  
  保護グループがすでに無効化されている場合、アプリケーションリソースグループが管理されてオフラインになっているため、保護グループ内のリソースグループの状態は Error になっている可能性があります。
  
  保護グループが無効化されている場合、アプリケーションリソースグループはすでに管理されていない状態であるため、Error 状態はクリアされます。
4. 保護グループが停止したことを確認します。
  phys-paris-1# geoadm status
5. cluster-paris で、各保護グループを再同期させます。
  
  cluster-newyork 上の保護グループのローカルの役割は、現在 primary であるため、この手順により cluster-paris クラスタ上の保護グループの役割は secondary になることが確認されます。
  phys-paris-1# geopg update protectiongroupname
  保護グループの同期については、「Oracle Data Guard 保護グループを再同期する」を参照してください。

cluster-paris 上で、個々の保護グループのクラスタ構成を検証します。

Error 状態の保護グループを起動することはできません。保護グループが Error 状態でないことを確認します。
phys-paris-1# geopg validate protectiongroupname
詳細は、「Oracle Data Guard 保護グループを検証する方法」を参照してください。

cluster-paris で、各保護グループを有効にします。

保護グループを有効にすると、そのアプリケーションリソースグループもオンラインになります。
phys-paris-1# geopg start -e global protectiongroupname
-e global

コマンドの範囲を指定します。

global スコープを指定すると、保護グループが配置されている両方のクラスタがコマンドの対象となります。

注 –
global や local などのプロパティー値では、大文字と小文字は区別されません。

protectiongroupname

保護グループの名前を指定します。

データが完全に同期したことを確認します。
1. cluster-newyork 上の保護グループの状態が OK であることを確認します。
  phys-newyork-1# geoadm status
  出力の保護グループセクションを参照してください。
2. 複製リソースグループ ODGprotectiongroupname-odg-rep-rg 内のすべてのリソースの状態が OK であることを確認します。
  phys-newyork-1# clresource status -v ODGprotectiongroupname-odg-rep-rs

両方のパートナークラスタ上で、保護グループが有効になったことを確認します。
phys-paris-1# geoadm status … phys-newyork-1# geoadm status …

どちらかのクラスタで、各保護グループについて cluster-newyork から cluster-paris へのスイッチオーバーを実行します。
phys-node-n# geopg switchover [-f] -m cluster-paris protectiongroupname
詳細は、「Oracle Data Guard 保護グループを主クラスタからスタンバイクラスタにスイッチオーバーする方法」を参照してください。

cluster-paris クラスタは元の役割である、保護グループの主クラスタに戻ります。

スイッチオーバーが正常に実行されたことを確認します。
phys-node-n# geoadm status
保護グループが現在 cluster-paris で primary に、cluster-newyork で secondary になっており、Data replication および Resource groups プロパティーの状態が、両方のクラスタで OK と示されていることを確認します。

各 Oracle Data Guard 保護グループについて、アプリケーションリソースグループとデータ複製の実行時状態を検査します。
phys-node-n# clresourcegroup status -v resourcegroupname # clresource status -v ODGConfigurationName-odg-rep-rs
検査する Oracle Data Guard Broker 構成の Status フィールドと StatusMessage フィールドを参照してください。これらのフィールドの詳細は、表 2–1を参照してください。

データ複製の実行時ステータスについては、「Oracle Data Guard データ複製の実行時状態の検査」を参照してください。

Oracle Data Guard 複製を使用するシステム上でフェイルバックテイクオーバーを実行する方法

元の主クラスタ cluster-paris 上でアプリケーションを再起動し、元の主クラスタ上の現在のデータを使用するには、次の手順を実行します。

注 –

この場合、現在主クラスタとして機能しているスタンバイクラスタ cluster-newyork の更新データはすべて破棄されます。

注 –

条件付きですが、元の主クラスタ cluster-paris のデータの使用は再開できます。ただし、cluster-newyork でのテイクオーバー操作のあとは、どのような時点でも、新しい主クラスタ cluster-newyork から元の主クラスタ cluster-paris にデータを決して複製しないでください。

始める前に

フェイルバックテイクオーバーの手順を開始する前に、クラスタは次の役割になっている必要があります。

cluster-newyork 上の保護グループには primary の役割が割り当てられています。
cluster-paris の保護グループの役割は、テイクオーバー中にその保護グループに到達できたかどうかによって、primary の役割または secondary の役割のいずれかになります。

元の主クラスタ cluster-paris に障害が発生した場合は、そのクラスタが起動していることと、そのクラスタで Sun Cluster Geographic Edition インフラストラクチャーが有効であることを確認します。

クラスタの再起動については、『Sun Cluster Geographic Edition のシステム管理』の「クラスタの起動」を参照してください。

元の主クラスタに失敗した前に、元の主クラスタの新しい Oracle Data Guard 主なデータベースを復元してスタンドバイに戻します。

この手順の実行方法についての詳細は、 Oracle のマニュアルを参照してください。

注 –
dgmgrl コマンドを利用して、Oracle Data Guard Broker 構成を削除および再作成する可能性があります。

元の主クラスタ、cluster-paris がふたたび Oracle Data Guard 構成の一部分として主なクラスタとして正常に動作していることを確認します。
oracle (phys-paris-1)$ dgmgrl sys/sysdba_password@sales-svc DGMGRL> show configuration;
元の主クラスタ、cluster-paris が正常に動作していた場合、show configuration コマンドが SUCCESS 状態を表示します。

元の主クラスタが障害発生時に起動した場合、非アクティブなセカンダリクラスタとしてマークされます。また、元のスタンドバイクラスタはアクティブな主クラスタとしてマークされます。

元の主クラスタが障害発生時に停止した場合、非アクティブな主クラスタとしてマークされます。また、元のスタンドバイクラスタはアクティブな主クラスタとしてマークされます。

元の主クラスタ、cluster-paris が障害発生時に起動または停止しましたか
- 元の主クラスタ、cluster-paris が障害発生時に停止した場合、元のスタンドバイクラスタ、cluster-newyork をセカンダリに更新します。
  1. 新しい主クラスタになる元のスタンドバイクラスタの上で、保護グループを停止します。
    phys-newyork-1# geopg stop -e local protectiongroupname
  2. 新しい主クラスタになる元のスタンドバイクラスタの上で、保護グループを更新します。
    phys-newyork-1# geopg update protectiongroupname
    役割が正しいですが、両方のクラスタが非アクティブとしてマークされます。
    
    保護グループの同期については、「Oracle Data Guard 保護グループを再同期する方法」を参照してください。
  3. cluster-paris と cluster-newyork 上で、各保護グループに構成をロカールに検証します。
    
    保護グループが Error 状態でないことを確認します。保護グループが Error 状態の場合、保護グループを起動できません。
    phys-paris-1# geopg validate protectiongroupname phys-newyork-1# geopg validate protectiongroupname
    詳細は、「Oracle Data Guard 保護グループを検証する方法」を参照してください。
  4. いずれかのクラスタの任意のノードから、両方のクラスタで保護グループをグローバルに有効にします。
    # geopg start -e global protectiongroupname
    保護グループが両方のクラスタで有効になると、フェイルバックテイクオーバーを正常に実行しました。
- 元の主クラスタ、cluster-paris が障害発生時に起動した場合、セカンダリ (つまり、元の主クラスタ) 構成の状態を決定します。
  phys-newyork-1# geoadm status
  - Configuration の状態を OK に設定した場合、構成を同期します。
    1. 元の主 cluster-paris で各保護グループにテイクオーバーを開始します。
      phys-paris-1# geopg takeover [-f] protectiongroupname
    2. 元のスタンドバイクラスタ、cluster-newyork の構成は、Error としてマークされたら、各保護グループに構成を検証します。
      cluster-newyork# geopg validate protectiongroupname
      詳細は、「Oracle Data Guard 保護グループを検証する方法」を参照してください。
    3. 両方のクラスタで保護グループをグローバルに有効にします。
      cluster-newyork# geopg start -e global protectiongroupname
      保護グループが両方のクラスタで有効になると、フェイルバックテイクオーバーを正常に実行しました。
  - Configuration の状態を Error に設定した場合、この問題を解決します。
    1. Error 状態であるセカンダリ (つまり、元の主クラスタ) 構成を無効化します。
      phys-newyork-1# geopg stop -e local protectiongroupname
    2. テイクオーバーを強制的に実行して、セカンダリ構成をふたたび主な構成にして、ベースとなる Oracle dgmgrl 構成に一致するようになります。
      phys-newyork-1# geopg takeover -f protectiongroupname
    3. cluster-paris と cluster-newyork の両方のクラスタ上で、各保護グループに構成をローカルに検証します。
      phys-paris-1# geopg validate protectiongroupname phys-newyork-1# geopg validate protectiongroupname
      詳細は、「Oracle Data Guard 保護グループを検証する方法」を参照してください。
    4. いずれかのクラスタの任意のノードから、両方のクラスタで保護グループをグローバルに有効にします。
      # geopg start -e global protectiongroupname
      保護グループが両方のクラスタで有効になると、フェイルバックテイクオーバーを正常に実行しました。

Oracle Data Guard データ複製エラーからの回復

データ複製レベルでエラーが発生した場合、関連する Oracle Data Guard Broker 構成の複製リソースグループ内のリソースの状態に、そのエラーが反映されます。

たとえば、複製されたデータベース sales を含んだ sales-pgという Oracle Data Guard Broker 構成の保護モードが MaxAvailability から MaxPerformance に変更されたとします。FAULTED に状態が変更されたことが、次のリソースの状態に反映されます。

Resource Status = "FAULTED"
Resource status message = "FAULTED - Protection mode "MaxAvailability" given 
for local database sales does not match configured value "MaxPerformance""

注 –

検証はまだ正常に実行されているので、Resource State は Online のままです。

リソースの状態が変化したため、保護グループの状態も変化します。この例の場合、ローカルの Data Replication の状態、ローカルクラスタ上の Protection Group の状態、および全体の Protection Group の状態がすべて Error に変わります。

エラー状態から回復するには、次の手順を実行します。

データ複製エラーから回復する方法

Oracle Data Guard のマニュアルに記載されている手順に従って、FAULTED 状態になった原因を調べます。

Oracle Data Guard の所定の手順に従って、障害状態から回復します。

回復手順によって Oracle Data Guard Broker 構成の状態が変化した場合、この状態は自動的にリソースによって検出され、新しい保護グループの状態として報告されます。複製モードが Sun Cluster Geographic Edition の設定と一致しない場合、次のコマンドを入力します。
phys-paris-1# geopg modify-replication-component -p replication_mode=New-protection-mode \ ODGConfigurationName protectiongroupname

保護グループ構成を検証し直します。
phys-paris-1# geopg validate protectiongroupname
protectiongroupname には Oracle Data Guard 保護グループの名前を指定します。

保護グループ構成の状態を確認します。
phys-paris-1# geopg list protectiongroupname
protectiongroupname には Oracle Data Guard 保護グループの名前を指定します。