テイクオーバーが正常に完了すると、スタンバイクラスタ 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 の構成がローカルに複製されます。 パートナーシップ構成と保護グループ構成の両方を再同期させます。
cluster-paris 上で、ローカルクラスタ上の保護グループを無効にします。
phys-paris-1# geopg stop -e local protectiongroupname |
コマンドの範囲を指定します。
範囲を local と指定すると、ローカルクラスタだけがコマンドの対象となります。
global や local などのプロパティー値では、大文字と小文字は区別されません。
保護グループの名前を指定します。
保護グループがすでに無効化されている場合、アプリケーションリソースグループが管理されてオフラインになっているため、保護グループ内のリソースグループの状態は Error になっている可能性があります。
保護グループが無効化されている場合、アプリケーションリソースグループはすでに管理されていない状態であるため、Error 状態はクリアされます。
cluster-paris で、パートナーシップを再同期させます。
phys-paris-1# geops update partnershipname |
複数の保護グループを再同期させている場合でも、この手順は 1 回実行するだけで済みます。
パートナーシップの同期については、『Sun Cluster Geographic Edition のシステム管理』の「パートナーシップの再同期」を参照してください。
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 |
コマンドの範囲を指定します。
global スコープを指定すると、保護グループが配置されている両方のクラスタがコマンドの対象となります。
global や local などのプロパティー値では、大文字と小文字は区別されません。
保護グループの名前を指定します。
現在の主クラスタ -cluster-newyork から現在のスタンバイクラスタ cluster-paris にデータを再同期させる必要があるため、n オプションを使用しないでください。
保護グループの役割が secondary であるため、データの同期化は現在の主クラスタ cluster-newyork から現在のスタンバイクラスタ cluster-paris へと行われます。
geopg start コマンドの詳細は、「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 の構成がローカルに複製されます。 パートナーシップ構成と保護グループ構成の両方を再同期させます。
cluster-paris で、パートナーシップを再同期させます。
phys-paris-1# geops update partnershipname |
パートナーシップ内の複数の保護グループに対してフェイルバックスイッチオーバーを実行している場合でも、この手順はパートナーシップごとに 1 回実行するだけで済みます。
パートナーシップの同期については、『Sun Cluster Geographic Edition のシステム管理』の「パートナーシップの再同期」を参照してください。
元の主クラスタである cluster-paris 上の保護グループが有効であるかどうかを判定します。
phys-paris-1# geoadm status |
元の主クラスタ上の保護グループが有効である場合は、その保護グループを停止します。
phys-paris-1# geopg stop -e local protectiongroupname |
コマンドの範囲を指定します。
範囲を local と指定すると、ローカルクラスタだけがコマンドの対象となります。
global や local などのプロパティー値では、大文字と小文字は区別されません。
保護グループの名前を指定します。
保護グループがすでに無効化されている場合、アプリケーションリソースグループが管理されてオフラインになっているため、保護グループ内のリソースグループの状態は Error になっている可能性があります。
保護グループが無効化されている場合、アプリケーションリソースグループはすでに管理されていない状態であるため、Error 状態はクリアされます。
保護グループが停止したことを確認します。
phys-paris-1# geoadm status |
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 |
コマンドの範囲を指定します。
global スコープを指定すると、保護グループが配置されている両方のクラスタがコマンドの対象となります。
global や local などのプロパティー値では、大文字と小文字は区別されません。
保護グループの名前を指定します。
データが完全に同期したことを確認します。
両方のパートナークラスタ上で、保護グループが有効になったことを確認します。
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 データ複製の実行時状態の検査」を参照してください。
元の主クラスタ cluster-paris 上でアプリケーションを再起動し、元の主クラスタ上の現在のデータを使用するには、次の手順を実行します。
この場合、現在主クラスタとして機能しているスタンバイクラスタ cluster-newyork の更新データはすべて破棄されます。
フェイルバックの手順はパートナーシップ内のクラスタにのみ適用されます。ここでの手順はパートナーシップごとに 1 回実行するだけで済みます。
条件付きですが、元の主クラスタ 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 をセカンダリに更新します。
新しい主クラスタになる元のスタンドバイクラスタの上で、保護グループを停止します。
phys-newyork-1# geopg stop -e local protectiongroupname |
新しい主クラスタになる元のスタンドバイクラスタの上で、保護グループを更新します。
phys-newyork-1# geopg update protectiongroupname |
役割が正しいですが、両方のクラスタが非アクティブとしてマークされます。
保護グループの同期については、「Oracle Data Guard 保護グループを再同期する方法」を参照してください。
cluster-paris と cluster-newyork 上で、各保護グループに構成をロカールに検証します。
保護グループが Error 状態でないことを確認します。保護グループが Error 状態の場合、保護グループを起動できません。
phys-paris-1# geopg validate protectiongroupname phys-newyork-1# geopg validate protectiongroupname |
詳細は、「Oracle Data Guard 保護グループを検証する方法」を参照してください。
いずれかのクラスタの任意のノードから、両方のクラスタで保護グループをグローバルに有効にします。
# geopg start -e global protectiongroupname |
保護グループが両方のクラスタで有効になると、フェイルバックテイクオーバーを正常に実行しました。
元の主クラスタ、cluster-paris が障害発生時に起動した場合、セカンダリ (つまり、元の主クラスタ) 構成の状態を決定します。
phys-newyork-1# geoadm status |
Configuration の状態を OK に設定した場合、構成を同期します。
元の主 cluster-paris で各保護グループにテイクオーバーを開始します。
phys-paris-1# geopg takeover [-f] protectiongroupname |
元のスタンドバイクラスタ、cluster-newyork の構成は、Error としてマークされたら、各保護グループに構成を検証します。
cluster-newyork# geopg validate protectiongroupname |
詳細は、「Oracle Data Guard 保護グループを検証する方法」を参照してください。
両方のクラスタで保護グループをグローバルに有効にします。
cluster-newyork# geopg start -e global protectiongroupname |
保護グループが両方のクラスタで有効になると、フェイルバックテイクオーバーを正常に実行しました。
Configuration の状態を Error に設定した場合、この問題を解決します。
Error 状態であるセカンダリ (つまり、元の主クラスタ) 構成を無効化します。
phys-newyork-1# geopg stop -e local protectiongroupname |
テイクオーバーを強制的に実行して、セカンダリ構成をふたたび主な構成にして、ベースとなる Oracle dgmgrl 構成に一致するようになります。
phys-newyork-1# geopg takeover -f protectiongroupname |
cluster-paris と cluster-newyork の両方のクラスタ上で、各保護グループに構成をローカルに検証します。
phys-paris-1# geopg validate protectiongroupname phys-newyork-1# geopg validate protectiongroupname |
詳細は、「Oracle Data Guard 保護グループを検証する方法」を参照してください。
いずれかのクラスタの任意のノードから、両方のクラスタで保護グループをグローバルに有効にします。
# geopg start -e global protectiongroupname |
保護グループが両方のクラスタで有効になると、フェイルバックテイクオーバーを正常に実行しました。