ミラー停止の手順

計画的メンテナンスまたは不測の問題により、ミラー内の一方または両方のフェイルオーバー・メンバ上で InterSystems IRIS インスタンスが使用できなくなる場合があります。フェイルオーバー・メンバの InterSystems IRIS インスタンスが使用できないときに、その ISCAgent は引き続き使用できることも (ホスト・システムが引き続き動作している場合)、使用できなくなることも (ホスト・システムがダウンしている場合) あります。このセクションでは、インスタンスの停止や一方または両方のフェイルオーバー・メンバの全体的な停止を含め、さまざまな計画的および計画外停止シナリオの対処手順について説明します。

"自動フェイルオーバーのメカニズム" に記載されているように、プライマリ・フェイルオーバー・メンバからバックアップ・フェイルオーバー・メンバへの安全で正常なフェイルオーバーには、以下の 2 つの要件があります。

プライマリのインスタンスが実際にダウンしており、一時的なネットワークの問題によって遮断されているのではないことの確認。
プライマリの障害発生時に、バックアップがアクティブであったか ("ミラー同期" を参照)、または手動でキャッチアップされていた ("自動フェイルオーバーなしのプライマリ計画外停止" を参照) ため、バックアップにはプライマリからの直近のジャーナル・データがあることの確認。

このドキュメントを使用するにあたって、"自動フェイルオーバーのルール" を参照しながら、自動フェイルオーバーを制御するルールを確認することもできます。

バックアップ・フェイルオーバー・メンバがアクティブであるかどうかや DR 非同期がキャッチアップされているかどうかを確認するためのミラー・モニタ使用についての詳細は、"ミラー・メンバのジャーナル転送およびデジャーナリングのステータス" および "ミラーの監視" を参照してください。

この章では、以下の手順について説明します。

計画的停止の手順

計画的メンテナンスを実施するには、フェイルオーバー・メンバのいずれかで InterSystems IRIS インスタンスをシャットダウンするか、もしくはそのインスタンスをホストしているシステム全体をシャットダウンする必要がある場合があります。これを実行する状況としては、以下のようなものがあります。

このセクションでは、適切なシャットダウンとは、iris stop コマンドの使用を表します。iris コマンドの詳細は、"システム管理ガイド" の “InterSystems IRIS 複数インスタンスの使用法” の章の "InterSystems IRIS インスタンスの制御" を参照してください。

Note:

iris stop コマンドのほかに、SYS.MirrorOpens in a new tab API および ^MIRROR ルーチンも手動でのフェイルオーバーのトリガに使用できます。

自動フェイルオーバーをトリガせずにプライマリをシャットダウンする操作に関する詳細は、"フェイルオーバー・メンバのメンテナンス時の不要なフェイルオーバーの回避" を参照してください。

計画的または計画外のフェイルオーバー・メンバの停止により、どのバックアップ・フェイルオーバー・メンバも使用できない場合、必要に応じて、DR 非同期メンバをフェイルオーバー・メンバに昇格させて、プライマリ障害時に発生するデータベース・アクセスの中断やデータ損失の可能性から保護できます。DR 非同期メンバのバックアップ・フェイルオーバー・メンバへの一時的昇格に関する詳細は、"昇格した DR 非同期によるフェイルオーバー・メンバの一時的置き換え" を参照してください。

バックアップ・フェイルオーバー・メンバのメンテナンス

バックアップ・フェイルオーバー・メンバの InterSystems IRIS インスタンスを停止する必要がある場合、バックアップのインスタンスで適切なシャットダウンを実行できます。これによって、プライマリの機能が影響を受けることはありません。バックアップ・インスタンスが再起動すると、このインスタンスは自動的にバックアップとして再びミラーに加わります。

ただし、バックアップのホストがシャットダウンされていて、そのためにバックアップの ISCAgent に通信できないときに、プライマリの InterSystems IRIS インスタンスが (何らかの理由で) 再起動された場合、そのプライマリは、再起動後にプライマリになることはできません。自身が最新プライマリだったかどうかを判断できないからです。バックアップのホスト・システムをシャットダウンする必要がある場合は、以下の手順を使用して、このリスクをなくすことができます。

"DR 非同期へのバックアップの降格" で説明しているように、バックアップ上で、バックアップを DR 非同期に降格します。
前のバックアップ・インスタンスとそのホスト・システムをシャットダウンし、メンテナンス作業を完了して、そのメンバを DR 非同期として再起動します。
"DR 非同期メンバのフェイルオーバー・メンバへの昇格" の説明に従って、以前のバックアップを DR 非同期からフェイルオーバー・メンバに昇格し、元のロールにリストアします。

バックアップが降格された後でプライマリを再起動すると、それは自動的にプライマリになります (プライマリの状態を維持します)。

バックアップをシャットダウン前に降格せず、バックアップのエージェントが利用できない間にプライマリの InterSystems IRIS インスタンスを再起動する必要が生じた場合、"両方のフェイルオーバー・メンバの計画外停止" の手順に従います。

プライマリ・フェイルオーバー・メンバのメンテナンス

プライマリ・フェイルオーバー・メンバの InterSystems IRIS インスタンス、またはホスト・システムを停止する必要がある場合、最初にバックアップへの適切なフェイルオーバーを行うことができます。バックアップがアクティブなときに ("ミラー同期" を参照してください)、プライマリの InterSystems IRIS インスタンスで適切なシャットダウンを実行します。自動フェイルオーバーがトリガされ、バックアップはプライマリとして引き継ぎをします。

メンテナンスが完了したら、旧プライマリの InterSystems IRIS インスタンス、またはホスト・システムを再起動します。InterSystems IRIS インスタンスが再起動すると、このインスタンスは自動的にバックアップとしてミラーに加わります。旧プライマリを元のロールに戻す場合、この手順 (バックアップの InterSystems IRIS インスタンスでの適切なシャットダウン実行によりフェイルオーバーをトリガした後、このインスタンスを再起動する) を繰り返すことができます。

フェイルオーバー・メンバのメンテナンス時の不要なフェイルオーバーの回避

バックアップ・メンバによるプライマリとしての引き継ぎが生じることなしに、プライマリ・フェイルオーバー・メンバを適切にシャットダウンする必要がある場合があります。例えば、プライマリがきわめて短時間停止する場合や、プライマリに障害が発生したときにバックアップが引き継がないようにする場合などです。これは、以下の 3 つの方法のいずれかで行うことができます。

"バックアップ・フェイルオーバー・メンバのメンテナンス" の説明に従って、バックアップ・フェイルオーバー・メンバを降格します。
iris stop /nofailover コマンドを使用して、プライマリの InterSystems IRIS インスタンスを適切にシャットダウンします。/nofailover 引数は、フェイルオーバーのトリガを避けるための予防措置として使用します。
プライマリまたはバックアップの [ミラー・モニタ] ページの上部で、[フェイルオーバーなしの設定] をクリックして、フェイルオーバーなしを設定します。フェイルオーバーなしを設定すると、ボタンの表示が [フェイルオーバーなしのクリア] になり、^MIRROR ルーチンの [ミラー・ステータス] メニューの [ステータス・モニタ] オプションに、この設定状態が示されます([ステータス・モニタ] オプションに関する詳細は、"ミラーの監視" を参照してください)。
どちらかのフェイルオーバー・メンバで [フェイルオーバーなしのクリア] をクリックして、フェイルオーバーなしの状態をクリアし、フェイルオーバーを有効にします。フェイルオーバーなしの状態は、プライマリを再起動すると自動的にクリアされます。

ミラー内 InterSystems IRIS インスタンスのアップグレード

ミラー全体で InterSystems IRIS をアップグレードするには、"インストール・ガイド" の “InterSystems IRIS のアップグレード” の章にある "ミラーリングを使用した最小ダウンタイムのアップグレード" を参照してください。

計画外停止の手順

フェイルオーバー・メンバに予期せず障害が発生した場合、適切な手順は、障害が発生した InterSystems IRIS インスタンス、ミラーが入っていたフェイルオーバー・モード ("自動フェイルオーバーのメカニズムの詳細" を参照してください)、他方のフェイルオーバー・メンバのインスタンスのステータス、両方のフェイルオーバー・メンバの ISCAgent の可用性、およびミラーの設定によって異なります。

このセクションを使用するにあたって、プライマリが使用不可になった場合のバックアップの動作の詳細を説明している "さまざまな停止シナリオに対するミラーの対応" を参照することができます。

バックアップ・フェイルオーバー・メンバの計画外停止

バックアップ・フェイルオーバー・メンバの InterSystems IRIS インスタンスまたはそのホスト・システムに障害が発生したとき、プライマリは通常の動作を続けますが、アプリケーションによっては、短い間一時停止するものがあります (詳細は、"バックアップ停止の影響" を参照してください)。

バックアップの計画外停止が発生した場合は、障害の原因となった状態を修復した後に、バックアップの InterSystems IRIS インスタンスまたはホスト・システムを再起動します。バックアップの InterSystems IRIS インスタンスが再起動すると、このインスタンスは自動的にバックアップとしてミラーに加わります。

Note:

バックアップがエージェント制御モードに入り ("自動フェイルオーバーのルール" を参照してください)、バックアップの ISCAgent に通信できない場合、プライマリの InterSystems IRIS インスタンスは再起動後にプライマリになることはできません。自身が最新プライマリだったかどうかを判断できないからです。したがって、バックアップ・ホスト・システムがダウンしているときに、何らかの理由でプライマリの InterSystems IRIS インスタンスを再起動する必要がある場合は、"バックアップ・フェイルオーバー・メンバのメンテナンス" で説明されている手順を実行してそれを行う必要があります。

自動フェイルオーバーによるプライマリ・フェイルオーバー・メンバの計画外停止

"自動フェイルオーバーのルール" で説明しているように、プライマリの InterSystems IRIS インスタンスが使用不可になると、バックアップは以下の場合にプライマリとして自動的に引き継ぐことができます。

バックアップがアクティブで、さらに以下の場合。
- 引き継ぎを要求するプライマリから通信を受信した。
- プライマリとの通信を失ったという情報をアービターから受信した。
- アービターが使用不可になっているか、アービターが構成されていない場合、プライマリの ISCAgent に通信して、プライマリのインスタンスがダウンまたはハングしていることを確認した。
バックアップがアクティブではないが、プライマリの ISCAgent に通信して、プライマリのインスタンスがダウンまたはハングしていることを確認し、プライマリの最新ジャーナル・データを ISCAgent から取得することができる場合。

自動フェイルオーバーを実行することができる状況の詳細は、"プライマリ停止シナリオに対応した自動フェイルオーバー" を参照してください。

計画外のプライマリ停止後にバックアップが自動的に引き継いだ場合は、停止の原因となった状態を修復してから、旧プライマリの InterSystems IRIS インスタンスまたはホスト・システムを再起動します。InterSystems IRIS インスタンスが再起動すると、このインスタンスは自動的にバックアップとしてミラーに加わります。旧プライマリをその元のロールに戻すには、"プライマリ・フェイルオーバー・メンバのメンテナンス" の説明に従って、バックアップの InterSystems IRIS インスタンスで適切なシャットダウンを実行してフェイルオーバーをトリガし、それから再起動します。

自動フェイルオーバーが発生しない場合のプライマリ・フェイルオーバー・メンバの計画外停止

"自動フェイルオーバーのルール" で説明しているように、プライマリのホスト・システムが、その ISCAgent も含めて使用不可になり、以下のいずれかが当てはまる場合、バックアップの InterSystems IRIS インスタンスは、応答しないプライマリのインスタンスから自動的に引き継ぐことはできません。

バックアップはアクティブではなかった。
バックアップは、エラーにより引き継ぐことができない。
アービターが構成されていないことにより、またはプライマリの InterSystems IRIS インスタンスおよびその ISCAgent との通信を失う前かそれと同時にアービターとの通信も失ったことにより、バックアップはプライマリがダウンしていることを確認できない。

このシナリオでは、3 つの状況が考えられます。それぞれの状況を可能なソリューションと共に以下に示します。

プライマリのホスト・システムに障害が発生しましたが、再起動できます。以下のいずれかを実行できます。
- プライマリの InterSystems IRIS インスタンスを再起動せずに、プライマリのホスト・システムを再起動します。プライマリの ISCAgent が使用できるようになると、バックアップは必要に応じてそのエージェントから最新のジャーナル・データを取得し、プライマリになります。
- プライマリの InterSystems IRIS インスタンスを含めて、プライマリのホスト・システムを再起動します。フェイルオーバー・メンバは、一方がプライマリになり、他方がバックアップになるまで、ネゴシエートします。
プライマリのホスト・システムに障害が発生し、再起動できません。バックアップによる引き継ぎを手動で強制することができます。このための手順は、バックアップがプライマリとの通信を失ったときにアクティブだったかどうかによって異なります。以下のセクションで説明しているように、何らかのデータ損失のリスクがあります。
プライマリのホスト・システムは稼働していますが、そのネットワークはアービターからもバックアップからも切り離されています。"プライマリ・フェイルオーバー・メンバの計画外分離" を参照してください。

フェイルオーバー・メンバを手動で強制的にプライマリにする処理

フェイルオーバー・メンバがプライマリになることができない場合はそれを強制することができますが、直前のプライマリのジャーナル・データが、強制の対象メンバのものより最新の可能性がある状況では、この強制を実行した場合にデータ損失のリスクがあります。以下の手順は、このリスクを見極めて、それに対処する方法を示しています。直近ジャーナル・データを有していることを確認できていないときに、メンバを強制的にプライマリにすると、他のミラー・メンバがミラーに再参加できなくなるため、再構築が必要になる場合があります ("ミラー・メンバの再構築" に記載のとおり)。

Caution:

処理を進める前に、プライマリがダウンしており、この手順の間もダウンしたままであることを確認してください。これを確認できない場合は、元のプライマリが再度使用可能になって、両方のメンバが同時にプライマリとして動作することになるというリスクを回避するために、この手順は中止することをお勧めします。この手順が適切であるかどうかについて不明な点がある場合は、インターシステムズのサポート窓口Opens in a new tabまでご相談ください。

手動フェイルオーバーの前にバックアップがアクティブであったかどうかを判別する処理

InterSystems IRIS A と InterSystems IRIS B の 2 つのフェイルオーバー・メンバがあるとします。プライマリ (InterSystems IRIS A) との通信が失われた時点でバックアップ (InterSystems IRIS B) がアクティブだったこと、またそれにより InterSystems IRIS B が InterSystems IRIS A からの最新ジャーナル・データを有していることが、^MIRROR ルーチンによって確認できると、1 つの手順のみを使用してフェイルオーバーを手動で実行できます。プライマリ上の障害によって接続が失われた場合、これによってデータ損失のリスクがもたらされることはありません。ただし、複数の障害が発生した場合、接続が途切れた後しばらくの間プライマリが動作を続けていたために、アクティブなバックアップがプライマリからの最新ジャーナル・データをすべて有しているとは限らない可能性があります。

以下の手順を使用して、バックアップがアクティブであったかどうかを判別します。

InterSystems IRIS A 上の InterSystems IRIS インスタンスとその ISCAgent の両方が実際にダウンしていることを確認します (そしてこの手動フェイルオーバーの手順全体を通して、ダウンしたままであることを確認します)。
InterSystems IRIS B 上で、ターミナルの %SYS ネームスペースにある ^MIRROR ルーチン ("^MIRROR ルーチンの使用法" を参照してください) を実行します。

メイン・メニューから [ミラー管理] を選択して、次のサブメニューを表示します。

 1) Add mirrored database(s)
 2) Remove mirrored database(s)
 3) Activate or Catchup mirrored database(s)
 4) Change No Failover State
 5) Try to make this the primary
 6) Connect to Mirror
 7) Stop mirroring on this member
 8) Modify Database Size Field(s)
 9) Force this node to become the primary
10) Promote Async DR member to Failover member
11) Demote Backup member to Async DR member
12) Mark an inactive database as caught up
13) Manage mirror dejournaling on async member (disabled)
14) Pause dejournaling for database(s)

[このノードを強制的にプライマリにする] オプションを選択します。通信が途絶えた時点でバックアップがアクティブであった場合は、以下のようなメッセージが表示されます。

This instance was an active backup member the last time it was
connected so if the primary has not done any work since that time,
this instance can take over without having to rebuild the mirror
when the primary reconnects. If the primary has done any work
beyond this point (file #98),
     C:\InterSystems\MyIRIS\mgr\journal\MIRROR-GFS-20180815.009
then the consequence of forcing this instance to become the primary is
that some operations may be lost and the other mirror member may need
to be rebuilt from a backup of this node before it can join as
a backup node again.
Do you want to continue? <No>

プライマリのジャーナル・ファイルにアクセスできる場合、続行前に、示されているファイルが最新のものであることを確認できます。

プライマリとの通信が途絶えた時点でバックアップがアクティブでなかった場合は、以下のようなメッセージが表示されます。

Warning, this action can result in forcing this node to become
the primary when it does not have all of the journal data which
has been generated in the mirror. The consequence of this is that
some operations may be lost and the other mirror member may need
to be rebuilt from a backup of this node before it can join as
a backup node again.
Do you want to continue? <No>

アクティブなバックアップに対する手動フェイルオーバー

^MIRROR ルーチンの [このノードを強制的にプライマリにする] オプションによって、バックアップからプライマリへの接続が失われたときにバックアップがアクティブであったことが確認された場合は、以下のように手動フェイルオーバーの手順を実行します。

手順を続行するには、Do you want to continue? プロンプトで、y と入力します。[このノードを強制的にプライマリにする] オプションは、ミラー・メンバがプライマリ化するために 60 秒間待ちます。60 秒以内に処理が正常完了しない場合、^MIRROR は、処理が成功しなかった可能性があることを報告して、かつメッセージ・ログの確認により、処理に失敗したのか、まだ処理中であるのかを判断するよう指示します。
^MIRROR ルーチンによって、バックアップがプライマリになったことが確認されたら、InterSystems IRIS A を再起動できるときにそのようにします。InterSystems IRIS A は、InterSystems IRIS インスタンス再起動時にバックアップとしてミラーに参加します。

バックアップがアクティブでない場合の手動フェイルオーバー

^MIRROR ルーチンにより、プライマリ (InterSystems IRIS A) との通信を失った時点でバックアップ (InterSystems IRIS B) がアクティブであったことを確認できなかった場合でも、以下の手順を使用して手動フェイルオーバー・プロセスを続行できますが、続行すると、何らかのデータ損失のリスクがあります。InterSystems IRIS A の最新ミラー・ジャーナル・ファイルへアクセスできる場合、この手順で説明しているように、手動フェイルオーバー前に、それらのファイルを InterSystems IRIS A から InterSystems IRIS B にコピーすることによって、このリスクを最小限に抑えることができます。

プライマリのミラー・ジャーナル・ファイルにアクセスできる場合は、最新のファイルを InterSystems IRIS B にコピーします。このとき、InterSystems IRIS B での最新のジャーナル・ファイルから始め、InterSystems IRIS A にあるそれ以降のファイルを含めます。例えば、MIRROR-MIRRORA-20180220.001 が InterSystems IRIS B での最新のファイルである場合、MIRROR-MIRRORA-20180220.001 とそれ以降のファイルを InterSystems IRIS A からコピーします。ファイルの権限と所有権を確認し、必要に応じて、それらを既存のジャーナルファイルと一致するよう変更します。
データ損失のリスクを受け入れる場合は、プロンプトで y と入力し、続行することを確定します。これでバックアップがプライマリになります。[このノードを強制的にプライマリにする] オプションは、ミラー・メンバがプライマリ化するために 60 秒間待ちます。60 秒以内に処理が正常完了しない場合、^MIRROR は、処理が成功しなかった可能性があることを報告して、かつメッセージ・ログの確認により、処理に失敗したのか、まだ処理中であるのかを判断するよう指示します。
^MIRROR ルーチンによって、バックアップがプライマリになったことが確認されたら、InterSystems IRIS A を再起動できるときにそのようにします。
- InterSystems IRIS インスタンスが再起動して、InterSystems IRIS A がバックアップとしてミラーに加わった場合、これ以上のステップは不要となります。障害メンバ上にはあるが、現在のプライマリ上にはないジャーナル・データは破棄されています。
- InterSystems IRIS のインスタンスが再起動したとき、InterSystems IRIS A がミラーに参加できない場合、"ミラー・メンバの再構築" で説明しているデータ不一致を表すメッセージ・ログ・メッセージが示すように、InterSystems IRIS A 上の最新データベース変更は、InterSystems IRIS B が強制的にプライマリになったときに InterSystems IRIS B に存在する最新ジャーナル・データよりも新しいものになります。これを解決するには、そのセクションの説明に従って、InterSystems IRIS A を再構築します。

プライマリ・フェイルオーバー・メンバの計画外分離

自動フェイルオーバーのメカニズムで説明しているように、バックアップとの通信とアービターとの通信を両方とも同時に失った場合、プライマリは無限の障害状態に入り、プライマリとしては動作できなくなります。通常、このような状態が生じた場合は、バックアップが引き継いで、プライマリになります。プライマリからバックアップへの接続がリストアされると、バックアップはプライマリを強制的にダウンさせます。または、接続をリストアする前に、ユーザ自身がプライマリを強制的にダウンさせることができます。

ただし、1 つのネットワーク・イベント (または一連のネットワーク・イベント) が原因で、フェイルオーバー・メンバとアービターがすべて同時に (またはほとんど同時に) お互いとの通信を失った場合、プライマリがなくなる可能性があります。これは、バックアップは引き継ぐことができず、プライマリはプライマリとしては動作できなくなるからです。この状況は、"自動フェイルオーバーのメカニズムの詳細" セクションの "アービター・モードで失われた接続に対するミラーの対応" テーブルで最後のシナリオとして示されています。プライマリが切り離されて、エラーによりバックアップが引き継ぐことができない場合、同様の状況が生じる可能性があります。

このような状況が生じた場合、以下のオプションがあります。

フェイルオーバー・メンバ間の接続をリストアします。前のバックアップが前のプライマリに通信すると、これらのメンバはネゴシエートして、一方がプライマリになり、他方がバックアップになります。
接続をリストアせずに、プライマリでターミナル・ウィンドウを開くことができる場合は、このウィンドウを開いて、プライマリで ^MIRROR ルーチン ("^MIRROR ルーチンの使用法" を参照してください) を実行します。このルーチンによって、プライマリのインスタンスが無限の障害状態にあることが確認され、以下の 2 つのオプションが提供されます。
- もう一方のフェイルオーバー・メンバがダウンしており (ユーザがシャットダウンした場合がある)、そのメンバがプライマリになることはなく、プライマリ上の最新ミラー・ジャーナル・ファイルより新しいミラー・ジャーナル・ファイルがそのメンバで作成されていないことが確認できたら、そのメンバに強制的にプライマリとして動作を再開させることができます。そのように実行して、プライマリとバックアップの間の接続をリストアすると、そのバックアップはバックアップとして動作を再開します。
- これらの状態を確認できない場合は、プライマリをシャットダウンできます。その後に、"自動フェイルオーバーが発生しない場合のプライマリ・フェイルオーバー・メンバの計画外停止" で説明しているいずれかの手順を使用して、バックアップへのフェイルオーバーを手動で実行できます。
プライマリでターミナル・ウィンドウを開くことができないが、もう一方のフェイルオーバー・メンバがダウンしており、そのメンバがプライマリになることはなく、プライマリ上の最新ミラー・ジャーナル・ファイルより新しいミラー・ジャーナル・ファイルがそのメンバで作成されていないことを確認できる場合は、プライマリの InterSystems IRIS インスタンスを再起動し、^MIRROR ルーチンの [このノードを強制的にプライマリにする] オプションを使用して、それを強制的にプライマリにすることができます。または、これらの状態を確認できない場合、プライマリの InterSystems IRIS インスタンスがダウンしていて、このままダウンし続けることを確認してから、"自動フェイルオーバーが発生しない場合のプライマリ・フェイルオーバー・メンバの計画外停止" で説明しているいずれかの手順を使用して、バックアップへのフェイルオーバーを手動で実行できます。

Caution:

ここに挙げた状態を確認することなく、プライマリにプライマリとして強制的に動作を再開させる場合は、データ損失や、両方のフェイルオーバー・メンバが同時にプライマリとして動作するリスクがあります。この手順が適切であるかどうかについて不明な点がある場合は、インターシステムズのサポート窓口Opens in a new tabまでご相談ください。

両方のフェイルオーバー・メンバの計画外停止

同じイベントまたは異なるイベントが原因で、両方のフェイルオーバー・メンバに予期せず障害が発生した場合、適切な手順は、可用性の要件の制限内でフェイルオーバー・メンバのいずれかまたは両方を再起動できるかどうかによって異なります。ミラーの機能不全の状態での許容時間が長くなればなるほど、選択できるオプションの数は多くなる傾向があります。

両方のエージェントと少なくとも 1 つの InterSystems IRIS インスタンスを再起動できる場合、フェイルオーバー・メンバはお互いにネゴシエートして、プライマリとして動作する方のフェイルオーバー・メンバを自動的に選択し、データ損失のリスクなしにミラーを稼働状態に戻します。
どちらのフェイルオーバー・メンバが直前のプライマリだったのかを確信しており、それを再起動できる場合に、それがもう一方のフェイルオーバー・メンバの InterSystems IRIS インスタンスまたはエージェントと通信できない (ダウンしているため) ときは、それは自動的にプライマリになりませんが、^MIRROR ルーチンの [このノードを強制的にプライマリにする] オプションを使用して、データ損失のリスクなく、それを手動で強制的にプライマリにすることができます ("自動フェイルオーバーを使用しないプライマリ・フェイルオーバー・メンバの計画外停止" に記載のとおり)。
どちらか 1 つのフェイルオーバー・メンバのみを再起動できるが、それが直前のプライマリだったかどうかわからない場合は、^MIRROR ルーチンの [このノードを強制的にプライマリにする] オプションを使用して、データ損失のリスクなく、それを手動で強制的にプライマリにすることができます。

Caution:

アクティブでなかったバックアップを強制的にプライマリにすると、グローバル更新処理の一部が失われる可能性があり、他のミラー・メンバの再構築が必要になる場合があります ("ミラー・メンバの再構築" に記載のとおり)。この手順が適切であるかどうかについて不明な点がある場合は、インターシステムズのサポート窓口Opens in a new tabまでご相談ください。
いずれのフェイルオーバー・メンバも再起動できない場合は、"災害復旧の手順" に進んでください。

災害復旧の手順

"非同期ミラー・メンバ" の説明のとおり、災害復旧 (DR) 非同期メンバはミラーリングされるデータベースの読み取り専用コピーを維持して、必要に応じて DR 非同期メンバをフェイルオーバー・メンバへ昇格できるようにします。DR 非同期メンバの昇格手順については、"DR 非同期メンバのフェイルオーバー・メンバへの昇格" で説明しています。このセクションでは、DR 非同期の昇格が使用できる 3 つのシナリオについて説明します。

この手順では、InterSystems IRIS A は元のプライマリ・フェイルオーバー・メンバ、InterSystems IRIS B は元のバックアップ・フェイルオーバー・メンバ、InterSystems IRIS C は昇格する DR 非同期メンバとします。

災害復旧時の昇格した DR 非同期への手動フェイルオーバー

ミラーから機能しているフェイルオーバー・メンバがなくなった場合、昇格した DR 非同期メンバに手動でフェイルオーバーすることができます。以下の手順では、これをオプションとするシナリオを扱います。

Caution:

プライマリ・フェイルオーバー・メンバの InterSystems IRIS インスタンスが実際にダウンしていることを確認できない、かつインスタンスが使用できるようになる可能性がある場合、他のミラー・メンバへの手動フェイルオーバーは避けてください。手動フェイルオーバーを行った後に元のプライマリが使用できるようになると、両方のフェイルオーバー・メンバは同時にプライマリとして動作します。

Note:

プライマリの InterSystems IRIS インスタンスが、アービター制御モードでバックアップとアービターの両方から遮断されたことにより無限の障害状態にある場合、"自動フェイルオーバーのメカニズムの詳細" で説明しているように、DR 非同期をフェイルオーバー・メンバに昇格できません。

追加ジャーナル・データなしの DR 昇格および手動フェイルオーバー

実際の災害復旧のシナリオで、両方のフェイルオーバー・メンバのホスト・システムがダウンして、それらのジャーナル・ファイルへのアクセスができなくなった場合は、旧プライマリから直近のジャーナル・データを取得せずに、DR 非同期メンバをプライマリに昇格させることができます。このとき、一部のデータが損失する可能性があります。フェイルオーバー・メンバのホスト・システムにアクセス可能な場合、"プライマリの ISCAgent のジャーナル・データありの DR 昇格および手動フェイルオーバー" または "DR" で示したいずれかの手順を代用します。これらにより、昇格された DR 非同期は、プライマリになる前に最新ジャーナル・データを取得できるため、データ損失のリスクを最小限に抑えることができます。

ミラー VIP に参加していない DR 非同期をプライマリに昇格させた場合、このセクションで示している手順を実行する前に、ユーザとアプリケーションを新しいプライマリにリダイレクトするために必要なあらゆる変更を加える必要があります ("フェイルオーバーまたは災害復旧後のアプリケーション接続のリダイレクト" を参照)。

Note:

[開始時にマウントが必要] とマークされているすべてのミラーリングされたデータベース ("システム管理ガイド" の “InterSystems IRIS の管理” の章の "ローカル・データベースのプロパティの編集" を参照してください) がマウント、アクティブ化、およびキャッチアップされており、プライマリ化時にすぐに使用できるようになっていない限り、昇格した DR 非同期はプライマリ化を試行しません。

Caution:

前のプライマリの直近ジャーナル・データなしの DR 非同期のプライマリ昇格では、グローバル更新処理の一部が失われる可能性があり、他のミラー・メンバの再構築が必要になる場合があります ("ミラー・メンバの再構築" に記載のとおり)。この手順が適切であるかどうかについて不明な点がある場合は、インターシステムズのサポート窓口Opens in a new tabまでご相談ください。

直近ジャーナル・データの取得なしで、DR 非同期メンバ (InterSystems IRIS C) をプライマリに昇格させるには、以下のことを実行します。

フェイルオーバー・パートナーを選択せずに、InterSystems IRIS C をフェイルオーバー・メンバに昇格させます。InterSystems IRIS C は、追加ジャーナル・データなしでプライマリになります。
旧フェイルオーバー・メンバ (InterSystems IRIS A および InterSystems IRIS B) のホスト・システムが動作状態になったら、InterSystems IRIS 再起動前のできるだけ早い段階において、各メンバ上で InterSystems IRIS インスタンスの構成パラメータ・ファイルの [MirrorMember] セクションで ValidatedMember=0 を設定します ("構成パラメータ・ファイル・リファレンス" の "[MirrorMember]" を参照してください)。これにより、InterSystems IRIS インスタンスに対して、以前のロールでの再接続ではなく、昇格した DR 非同期からのミラー内での新規ロール取得が指示されます。昇格指示では、この変更は必須であることが示されます。

Caution:

ValidatedMember=0 を設定しなければ、2 つのミラー・メンバが同時にプライマリとして動作してしまうおそれがあります。
各旧フェイルオーバー・メンバ上で InterSystems IRIS を再起動します。
1. InterSystems IRIS が再起動して、そのメンバが DR 非同期としてミラーに加わった場合、これ以上のステップは不要となります。障害メンバ上にはあるが、現在のプライマリ上にはないジャーナル・データは破棄されています。
2. InterSystems IRIS の再起動時にメンバがミラーに参加できない場合、"ミラー・メンバの再構築" で説明しているデータ不一致を表すメッセージ・ログ・メッセージが示すように、メンバの最新データベース変更は、InterSystems IRIS C がプライマリになったときに InterSystems IRIS C に存在する最新ジャーナル・データよりも新しいものになります。これを解決するには、そのセクションの説明に従って、InterSystems IRIS A を再構築します。
InterSystems IRIS A および InterSystems IRIS B が再びミラーに加わったら、"昇格した DR 非同期によるフェイルオーバー・メンバの一時的置き換え" に記載されている手順を使用して、メンバすべてを元のロールに戻すことができます。InterSystems IRIS A または InterSystems IRIS B のいずれかがバックアップとして再起動した場合、バックアップにフェイルオーバーするためにバックアップがアクティブになっているときに、InterSystems IRIS C の適切なシャットダウンから開始します。InterSystems IRIS A および InterSystems IRIS B の両方が DR 非同期として再起動した場合、いずれかをバックアップに昇格させた後に、InterSystems IRIS C で適切なシャットダウンを実行します。他方の旧フェイルオーバー・メンバをバックアップに昇格させてから、InterSystems IRIS C を DR 非同期として再起動します。

プライマリの ISCAgent のジャーナル・データありの DR 昇格および手動フェイルオーバー

InterSystems IRIS A のホスト・システムは動作しているが、InterSystems IRIS インスタンスは動作しておらず、かつ再起動不可能である場合、以下の手順を使用して、InterSystems IRIS A の ISCAgent を通じて昇格した InterSystems IRIS C を InterSystems IRIS A の直近ジャーナル・データで更新できます。

InterSystems IRIS C を昇格させて、InterSystems IRIS A をフェイルオーバー・パートナーとして選択します。InterSystems IRIS C がフェイルオーバー・メンバに昇格され、InterSystems IRIS A のエージェントから直近ジャーナル・データを取得した後、プライマリとなります。
InterSystems IRIS A の InterSystems IRIS インスタンスを再起動すると、バックアップとして再びミラーに再び参加します。
InterSystems IRIS A がミラーに再び参加し、アクティブになった後に、"昇格した DR 非同期によるフェイルオーバー・メンバの一時的置き換え" に記載されている手順を使用して、メンバすべてを元のロールに戻すことができます。その際、InterSystems IRIS C の適切なシャットダウンから始めて、InterSystems IRIS B の構成パラメータ・ファイルの [MirrorMember] セクションで ValidatedMember=0 を設定して ("構成パラメータ・ファイル・リファレンス" の "[MirrorMember]" を参照)、InterSystems IRIS B を DR 非同期として再起動してバックアップに昇格させた後、InterSystems IRIS C を DR 非同期として再起動します。

Note:

InterSystems IRIS A のホスト・システムはダウンしているが、InterSystems IRIS B のホスト・システムはその InterSystems IRIS インスタンスが実行されていないにもかかわらず稼働している場合、"アクティブなバックアップに対する手動フェイルオーバー" の説明に従って、InterSystems IRIS B で ^MIRROR ルーチンを実行し、InterSystems IRIS B が障害発生時にアクティブなバックアップであったかどうかを判別します。その場合、前述の手順を使用しますが、昇格の際に InterSystems IRIS B をフェイルオーバー・パートナーとして選択して、InterSystems IRIS C が InterSystems IRIS B の ISCAgent から最新ジャーナル・データを取得できるようにします。

ジャーナル・ファイルのジャーナル・データありの DR 昇格および手動フェイルオーバー

InterSystems IRIS A と InterSystems IRIS B の両方のホスト・システムがダウンしているが、InterSystems IRIS A のジャーナル・ファイルにはアクセスできる場合、または InterSystems IRIS B のジャーナル・ファイルおよびメッセージ・ログが使用可能な場合、以下の手順を使用して、昇格前にプライマリからの最新ジャーナル・データで InterSystems IRIS C を更新できます。

以下のように、InterSystems IRIS A または InterSystems IRIS B からの最新ジャーナル・ファイルで InterSystems IRIS C を更新します。
- InterSystems IRIS A のジャーナル・ファイルが使用可能な場合、InterSystems IRIS A から最新ミラー・ジャーナル・ファイルを InterSystems IRIS C にコピーします。このとき、InterSystems IRIS C の最新ジャーナル・ファイルから始め、InterSystems IRIS A にあるそれ以降のファイルを含めます。例えば、MIRROR-MIRRORA-20180220.001 が InterSystems IRIS C で最新ファイルである場合、MIRROR-MIRRORA-20180220.001 とそれ以降のファイルを InterSystems IRIS A からコピーします。
- InterSystems IRIS A のジャーナル・ファイルは使用できないが、InterSystems IRIS B のジャーナル・ファイルおよびメッセージ・ログは使用可能な場合は、以下の操作を行います。
  1. 以下のように、InterSystems IRIS B がキャッチアップされている可能性が高いことを確認します。
    1. InterSystems IRIS A およびそのエージェントが使用不可になったと同時に InterSystems IRIS B が InterSystems IRIS A から切断されたことを確認します。InterSystems IRIS B が切断された時間は、その messages.log ファイルで、以下に類似したメッセージを検索することによって確認できます ("監視ガイド" の “管理ポータルを使用した InterSystems IRIS の監視” の章を参照してください)。
      MirrorClient: Primary AckDaemon failed to answer status request
    2. 切断時に InterSystems IRIS B がアクティブなバックアップであったことを、その messages.log ファイルで以下に類似したメッセージを検索することによって確認します。
      Failed to contact agent on former primary, can't take over
      Caution:
      
      messages.log ファイル内の以下のようなメッセージは、InterSystems IRIS B が切断時にアクティブではなかったことを示しています。
      
      nonactive Backup is down
      
      昇格された DR 非同期がキャッチアップされていることを確認できないときに、その DR 非同期を強制的にプライマリにすると、ミラーによって生成されたジャーナル・データがすべてない状態でプライマリになるおそれがあります。その結果、グローバル更新処理の一部が失われる可能性があり、他のミラー・メンバのバックアップからの再構築が必要になる場合があります。この手順が適切であるかどうかについて不明な点がある場合は、インターシステムズのサポート窓口Opens in a new tabまでご相談ください。
  2. InterSystems IRIS B がアクティブであったことを確認できた場合、InterSystems IRIS B から最新ミラー・ジャーナル・ファイルを InterSystems IRIS C にコピーします。このとき、InterSystems IRIS C の最新ジャーナル・ファイルから始め、InterSystems IRIS B にあるそれ以降のファイルを含めます。例えば、MIRROR-MIRRORA-20180220.001 が InterSystems IRIS C で最新ファイルである場合、MIRROR-MIRRORA-20180220.001 とそれ以降のファイルを InterSystems IRIS C からコピーします。ファイルの権限と所有権を確認し、必要に応じて、それらを既存のジャーナル・ファイルと一致するよう変更します。
フェイルオーバー・パートナーを選択せずに、InterSystems IRIS C をフェイルオーバー・メンバに昇格させます。InterSystems IRIS C がプライマリになります。
InterSystems IRIS A および InterSystems IRIS B の問題が修正されたら、InterSystems IRIS の再起動前のできるだけ早い段階において、各メンバ上で InterSystems IRIS インスタンスの構成パラメータ・ファイルの [MirrorMember] セクションで ValidatedMember=0 を設定します ("構成パラメータ・ファイル・リファレンス" の "[MirrorMember]" を参照してください)。昇格指示では、この変更は必須であることが示されます。これを実行したら、InterSystems IRIS A (直前にプライマリであったメンバ) から始めて、各メンバ上の InterSystems IRIS を再起動します。
1. InterSystems IRIS が再起動して、メンバがバックアップまたは DR 非同期としてミラーに参加した場合、これ以上のステップは不要となります。障害メンバ上にはあるが、現在のプライマリ上にはないジャーナル・データは破棄されています。
2. InterSystems IRIS インスタンスの再起動時にそのメンバがミラーに参加できない場合、"ミラー・メンバの再構築" で説明している、データの不一致を表すメッセージ・ログ・メッセージが示すように、そのメンバ上の最新データベース変更は、InterSystems IRIS C がプライマリになったときに InterSystems IRIS C に存在する最新ジャーナル・データよりも新しいものになります。これを解決するには、そのセクションの説明に従って、そのメンバを再構築します。
ほとんどの場合、DR 非同期システムは、プライマリ・フェイルオーバー・メンバにとって、適切な永続的ホストではありません。InterSystems IRIS A および InterSystems IRIS B が再びミラーに参加した後に、"昇格した DR 非同期によるフェイルオーバー・メンバの一時的置き換え" に記載されている手順を使用して、メンバすべてを元のロールに戻します。InterSystems IRIS A または InterSystems IRIS B のいずれかがバックアップとして再起動した場合、バックアップにフェイルオーバーするためにバックアップがアクティブになっているときに、InterSystems IRIS C の適切なシャットダウンから開始します。InterSystems IRIS A および InterSystems IRIS B の両方が DR 非同期として再起動した場合、いずれかをバックアップに昇格させた後に、InterSystems IRIS C で適切なシャットダウンを実行します。他方の旧フェイルオーバー・メンバをバックアップに昇格させてから、InterSystems IRIS C を DR 非同期として再起動します。

昇格した DR 非同期への計画的フェイルオーバー

DR 非同期を 1 つ以上ミラーに追加して、災害復旧機能を装備させている場合、各 DR 非同期への計画的フェイルオーバーによって、この機能を定期的にテストすることをお勧めします。このテストを実行するか、または他の何らかの理由で DR 非同期にフェイルオーバーを実行する場合 (フェイルオーバー・メンバを含むデータ・センタ内の計画的な停電など)、以下の手順を使用します。

InterSystems IRIS C をフェイルオーバー・メンバに昇格させます。InterSystems IRIS A が使用できるため、フェイルオーバー・パートナーの選択を要求されることはありません。InterSystems IRIS C はバックアップとなり、InterSystems IRIS B (存在する場合) は DR 非同期に降格されます。

Note:

ミラーに開始するフェイルオーバー・メンバが 1 つだけしかない場合でも、手順は同じです。フェイルオーバー・パートナーの選択を要求されることはなく、InterSystems IRIS C がバックアップとなるので、すぐにミラーは 2 つのフェイルオーバー・メンバを持つことになります。
InterSystems IRIS C がアクティブになったら ("バックアップ・ステータスと自動フェイルオーバー" を参照してください)、InterSystems IRIS A 上で適切なシャットダウンを実行します。自動フェイルオーバーがトリガされ、InterSystems IRIS C はプライマリとして引き継ぐことができます。
InterSystems IRIS C で適宜テストをした後、InterSystems IRIS A を再起動すると、自動的にバックアップとしてミラーへ参加します。
または、実際の災害時にはプライマリは利用できない可能性が高いため、プライマリを自動的にバックアップにせずに再起動して同期状態を維持したい場合は、再起動前に (その ISCAgent を使用して) DR 非同期に降格してから、後で準備が整った時点でプライマリをフェイルオーバー・メンバに昇格することができます。この方法の詳細は、"DR 非同期へのバックアップの降格" を参照してください。
InterSystems IRIS A がバックアップとしてアクティブになったら、InterSystems IRIS C で適切なシャットダウンを実行して、InterSystems IRIS A へのフェイルオーバーを行います。
InterSystems IRIS B (存在する場合) をフェイルオーバー・メンバに昇格させます。これはバックアップとなります。
InterSystems IRIS C の InterSystems IRIS インスタンスを再起動すると、自動的に DR 非同期として元のロールでミラーに参加します。

"ミラーリング・アーキテクチャとネットワーク構成のサンプル" で説明しているように、フェイルオーバー・メンバのミラー・プライベート・アドレスへのネットワーク・アクセス権がない DR 非同期の昇格は、プライマリとして機能することを目的とし、ほかに動作中のフェイルオーバー・メンバがない場合にのみ実行する必要があります。従って、この場合、前述の手順は当てはまりません。代わりに、次の手順を実行します。

InterSystems IRIS B (存在する場合) で、適切なシャットダウンを実行し、InterSystems IRIS A のみがフェイルオーバー・メンバ (プライマリ) として機能している状況にします。
InterSystems IRIS C がキャッチアップされたら ("ミラー・メンバのジャーナル転送およびデジャーナリングのステータス" を参照してください)、InterSystems IRIS A で適切なシャットダウンを実行します。
"プライマリの ISCAgent のジャーナル・データありの DR 昇格および手動フェイルオーバー" の説明に従って、InterSystems IRIS C をプライマリに昇格します。新しいプライマリが前のプライマリの ISCAgent と通信して、この手順の間に最新ジャーナル・データを有していることを確認します。
InterSystems IRIS C で適宜テストを実行した後、シャットダウンします。
InterSystems IRIS A を再起動します。これは、自動的にプライマリになります。
InterSystems IRIS B を再起動します (存在する場合)。InterSystems IRIS C の昇格によって、DR 非同期として参加します。
InterSystems IRIS B をバックアップに昇格します。
InterSystems IRIS C を再起動すると、自動的に元のロールである DR 非同期としてミラーに参加します。

Note:

このセクションの両方の手順で、InterSystems IRIS B が存在しない場合、つまりミラーがプライマリと非同期のみによって構成されている場合、再起動時に InterSystems IRIS C がバックアップになります。"バックアップ・フェイルオーバー・メンバのメンテナンス" の説明に従って、これを DR 非同期に降格します。

昇格した DR 非同期によるフェイルオーバー・メンバの一時的置き換え

"計画的停止の手順" および "計画外停止の手順" で説明した手順の一部は、単一フェイルオーバー・メンバでのミラーの一時操作に関係します。常に動作中のバックアップ・フェイルオーバー・メンバを維持する必要はありませんが、これにより、プライマリの障害発生時におけるデータベース・アクセスの中断やデータ損失の可能性からの防御が確実になります。そのため、計画的または計画外のフェイルオーバー・メンバ停止により、プライマリしか使用できない場合、DR 非同期メンバをバックアップ・フェイルオーバー・メンバへ一時的昇格することを検討するのが妥当です。ただし、これを実行する前に、以下の点を考慮します。

DR 非同期がフェイルオーバー・メンバから遠く離れた別のデータ・センタにある場合、それらの間には相当なネットワーク遅延が存在することがあります。DR メンバが昇格して、アクティブなフェイルオーバー・メンバになると、この往復遅延はプライマリとバックアップ間の同期データ・レプリケーションの重要な要素となり ("ミラー同期" を参照)、ミラーにアクセスするアプリケーションのパフォーマンスに悪影響を与える可能性があります ("ネットワーク遅延に関する考慮事項" を参照)。
"ミラーリング・アーキテクチャとネットワーク構成のサンプル" で説明しているように、DR 非同期にフェイルオーバー・メンバのミラー・プライベート・アドレスへのネットワーク・アクセス権がない場合、その DR 非同期は、ここで示した手順では使用できません。その DR 非同期の昇格は、プライマリとして機能することを目的とし、ほかに動作中のフェイルオーバー・メンバがない場合にのみ実行する必要があるためです。
ミラーでユーザおよびアプリケーションの自動リダイレクトに VIP が使用されており ("フェイルオーバーまたは災害復旧後のアプリケーション接続のリダイレクト" を参照)、別のサブネット上にあるため DR 非同期がミラー VIP を取得できない場合、通常、これらの手順を使用できません。

Note:

このオプションを使用する前に、"DR 非同期メンバのフェイルオーバー・メンバへの昇格" において、フェイルオーバー・パートナー選択の情報と、昇格時にエージェントに通信できないフェイルオーバー・メンバ上で ValidatedMember=0 を設定する要件について確認します。

現在のバックアップ・フェイルオーバー・メンバである InterSystems IRIS B で、計画的メンテナンスを実施する必要がある場合 ("バックアップ・フェイルオーバー・メンバのメンテナンス" を参照してください)、次の操作を実行できます。

キャッチアップされる DR 非同期である InterSystems IRIS C を昇格させます ("ミラー・メンバのジャーナル転送およびデジャーナリングのステータス" を参照してください)。InterSystems IRIS C は自動的にバックアップとなり、InterSystems IRIS B は DR 非同期に降格されます。
InterSystems IRIS B の InterSystems IRIS インスタンスまたはホスト・システムをシャットダウンして、計画的メンテナンスを完了します。
InterSystems IRIS B を再起動すると、これが DR 非同期としてミラーに加わります。
InterSystems IRIS B がキャッチアップされたら、これをフェイルオーバー・メンバに昇格させ、バックアップとして元のロールに戻します。InterSystems IRIS C は、自動的に元のロールである DR 非同期に降格されます。

現在のプライマリ・フェイルオーバー・メンバである InterSystems IRIS A で、計画的メンテナンスを実施する必要がある場合 ("プライマリ・フェイルオーバー・メンバのメンテナンス" を参照してください)、次の操作を実行できます。

InterSystems IRIS B がアクティブになったら ("ミラー同期" を参照してください)、InterSystems IRIS A 上で適切なシャットダウンを実行します。自動フェイルオーバーがトリガされ、InterSystems IRIS B はプライマリとして引き継ぐことができます。
キャッチアップされる DR 非同期メンバである InterSystems IRIS C を昇格させます。InterSystems IRIS C は自動的にバックアップとなります。
InterSystems IRIS A の計画的メンテナンスを完了し、必要に応じて、ホスト・システムのシャットダウンおよび再起動を行います。
InterSystems IRIS A の InterSystems IRIS インスタンスを再起動すると、DR 非同期としてミラーに参加します。
InterSystems IRIS A がキャッチアップされたら、これをフェイルオーバー・メンバに昇格させます。これがバックアップになり、InterSystems IRIS C は自動的に降格され、元のロールに戻ります。
InterSystems IRIS A がアクティブになったら、InterSystems IRIS B 上で適切なシャットダウンを実行します。自動フェイルオーバーがトリガされ、InterSystems IRIS A は元のロールに戻されます。
InterSystems IRIS B の InterSystems IRIS インスタンスを再起動すると、元のロールでミラーに参加します。

InterSystems IRIS B の計画外停止があった場合、または InterSystems IRIS A の計画外停止による InterSystems IRIS B への自動/手動フェイルオーバーを行った場合 ("計画外停止の手順" を参照してください)、次の操作を実行できます。

キャッチアップされる DR 非同期メンバである InterSystems IRIS C を昇格させます。InterSystems IRIS C は自動的にバックアップとなります。
障害が発生したフェイルオーバー・メンバを再起動します。DR 非同期の昇格時に障害の発生したメンバの ISCAgent が通信不可能であった場合、InterSystems IRIS インスタンス再起動前のできるだけ早い段階において、InterSystems IRIS インスタンスの構成パラメータ・ファイルの [MirrorMember] セクションで ValidatedMember=0 を設定する必要があります ("構成パラメータ・ファイル・リファレンス" の " [MirrorMember]" を参照してください)。昇格指示では、この変更は必須であることが示されます。旧フェイルオーバー・メンバの InterSystems IRIS インスタンスを再起動すると、DR 非同期としてミラーに加わります。
再起動したフェイルオーバー・メンバがキャッチアップされたら、これをフェイルオーバー・メンバに昇格させます。このメンバはバックアップとなり、InterSystems IRIS C は自動的に元のロールである DR 非同期に降格されます。
フェイルオーバー・メンバ間で現在のロールを交換する場合、バックアップがアクティブになるとき、現在のプライマリで適切なシャットダウンを実行し、自動フェイルオーバーをトリガします。別のフェイルオーバー・メンバを再起動します。これはバックアップとしてミラーに加わります。

ミラーリングの管理