ミラーリング

従来の高可用性ソリューションおよびデータ・レプリケーション・ソリューションは、しばしばインフラストラクチャ、配置、構成、ソフトウェアのライセンス、および計画に多額の資本投資を必要とします。Caché のデータベース・ミラーリングは、2 つの Caché インスタンス間における、迅速で、信頼性の高い、強固な自動フェイルオーバーを可能にする経済的なソリューションを提供するように設計されており、企業のための効果的な高可用性ソリューションを実現します。

共有リソース (共有ディスクなど) に依存した従来の可用性ソリューションは、その共有リソースの単一点障害の影響を受けることがしばしばあります。ミラーリングでは、プライマリ・ミラー・メンバとバックアップ・ミラー・メンバで独立したリソースを保持することによって、このリスクが低減されます。さらにミラーリングでは、論理データ・レプリケーションを利用することにより、SAN ベースのレプリケーションなどの物理的レプリケーション・テクノロジに関連するリスク (不適切な更新、破損の繰り越しなど) が回避されます。

InterSystems エンタープライズ・キャッシュ・プロトコル (ECP) とミラーリングの組み合わせにより、さらに高レベルの可用性が実現します。つまり、ECP アプリケーション・サーバはミラー・フェイルオーバーを ECP データ・サーバの再起動として処理し、新しいプライマリで処理が遮られずに続行され、ワークフローおよびユーザの作業の中断が大幅に軽減されます。別々のデータ・センタで 2 つのフェイルオーバー・ミラー・メンバを構成すると、冗長性が向上し、致命的なイベントからも保護されるようになります。

ミラーリングは、計画外のダウンタイムに対する可用性ソリューションを提供するほかに、特定の Caché システムでの計画されたダウンタイム (例えば、Caché の構成変更、ハードウェアまたはオペレーティング・システムのアップグレードなど) を、組織のサービス水準合意 (SLA) 全体に影響を与えずに組み込める柔軟性も備えています。

最後に、ミラーにはフェイルオーバー・メンバのほかに、企業全体で複数のミラーから更新を受信するように構成できる特別な非同期メンバを使用できます。このことにより、単一のシステムが包括的なデータ・ウェアハウスとして動作できるようになり、InterSystems の DeepSee™ を使用した企業全体のデータ・マイニングおよびビジネス・インテリジェンスが実現されます。また、非同期メンバは単一ミラーの災害復旧 (DR) に対しても構成できます。これにより、必要に応じて非同期メンバをシームレスにいずれかのフェイルオーバー・メンバの代わりとすることができます。1 つのミラーには、最大 16 のメンバを含めることができます。そのため、地理的に分散した多数の DR 非同期メンバを構成できます。このモデルは分散データ・レプリケーションのための強固なフレームワークを提供し、それによって組織にはビジネス継続性というメリットがもたらされるようになります。詳細は、この章の "ミラー停止の手順" を参照してください。

以下の項目について説明します。

ミラーリングのアーキテクチャおよび計画

ミラーとは、物理的に独立した複数の Caché インスタンスの論理グループで、プロダクション・データベースの同一コピーを同時に保持します。これによって、データベースへのアクセスを提供しているインスタンスが使用不可になった場合でも、別のインスタンスが引き継ぐことができます。ミラーでは、データベース (またはそのホスト・システム) へのアクセスを提供している Caché インスタンスに障害が発生した場合、別のインスタンスが自動的にかつ迅速に引き継ぐ処理である自動フェイルオーバーを通じた高可用性を実現できます。

このセクションでは、以下のトピックについて説明します。

ミラー・コンポーネント

ミラーの一部として構成されている Caché インスタンスをホストするシステムをミラー・メンバと呼びます。 (Caché インスタンス自体をミラー・メンバと呼ぶ場合もあります。) ミラー・メンバには、次の 2 つのタイプがあります。

ほかに次の 2 つのコンポーネントが、1つのフェイルオーバー・メンバから別のフェイルオーバー・メンバへの自動フェイルオーバーをサポートします。

フェイルオーバー・ミラー・メンバ

自動フェイルオーバーを有効にするには、2 つのフェイルオーバーメンバ (物理的に独立したシステムで、それぞれが Caché インスタンスをホストしています) がミラーに含まれている必要があります。いつでも、一方のフェイルオーバー・インスタンスがプライマリとして動作して、ミラー内のデータベースへのアクセスをアプリケーションに提供し、他のインスタンスがバックアップとして動作して、これらのデータベースの同期コピーを保持し、プライマリとして引き継ぐことができるように準備しておきます。プライマリの Caché インスタンスが使用不可になった場合、バックアップが引き継いで、データの損失なしにデータベースへのアクセスを中断なく提供します。自動フェイルオーバー・プロセスに関する詳細は、"自動フェイルオーバーのメカニズム" を参照してください。

フェイルオーバー・メンバは、複数のミラー・メンバ・ネットワーク・アドレスを使用して、複数の通信チャンネル経由でお互いに通信します。外部クライアントは通常、現在のプライマリ上のインタフェースに常にバインドされる仮想 IP アドレス (VIP) 経由でミラーに接続します。ECP アプリケーション・サーバ接続は、フェイルオーバー後の新しいプライマリに自動的にリダイレクトされるため、ECP 接続に VIP は必要ありません。

ミラーのフェイルオーバー・メンバ

ミラーのフェイルオーバー・メンバの構成に関する詳細は、"ミラーの作成" を参照してください。

Important:

ミラー内の 2 つのフェイルオーバー・メンバは同等と見なされ、いずれもプライマリとして優先されることはありません。このため、プライマリとバックアップは単なる一時的な指定であると考える必要があります。プライマリで問題が検出されてバックアップが引き継ぎ可能な場合、その引き継ぎはきわめて迅速に行われます。これは、プライマリ上の問題が、プライマリに十分な時間があれば自然に解決すると思われる場合であっても当てはまります。

フェイルオーバー･メンバ間のネットワーク遅延は、アプリケーションのパフォーマンスにおいて重要な要素であるため、接続における遅延が最小限に抑えられるように、フェイルオーバー・メンバの相対的な物理位置およびそれらのメンバ間のネットワーク接続を選択する必要があります。詳細は、"ネットワーク遅延に関する考慮事項" を参照してください。

非同期ミラー・メンバ

非同期メンバでは、ミラーリングされるデータベースの非同期コピーが保持されます。非同期メンバとしては、災害復旧とレポートの 2 つのタイプがあります。単一のミラーに、最大 16 のメンバを含めることができます。そのため、1 つのミラーに、1 つのフェイルオーバー・ペアと、上記の 2 つのタイプを任意に組み合わせた最大 14 の非同期メンバを構成できます。自動フェイルオーバーなしで非同期メンバを利用するように、ミラーを単一のフェイルオーバー・メンバで構成することもできます。

Important:

非同期メンバのデータは、接続先のミラーで発生する変更に応じて継続的に非同期で更新されるため、非同期メンバ上での更新の同期およびクエリの結果の同期は保証されません。変化するデータに対するクエリの結果の整合性が保証されるかどうかは、非同期メンバに対して実行されるアプリケーション次第です。

ミラーへの非同期メンバの追加に関する詳細は、この章の "非同期ミラー・メンバを構成する" を参照してください。

災害復旧非同期

ミラーは、災害復旧 (DR) 非同期メンバを通して災害復旧機能を提供できます。DR 非同期メンバを手動でフェイルオーバー・メンバに昇格することができ、両方のフェイルオーバー・メンバが災害のために使用できない場合は DR 非同期メンバをプライマリに設定することさえできます。昇格した DR は、計画的メンテナンスの実施やフェイルオーバー・メンバの一時的置き換えにおいても有用です。1 つの DR 非同期メンバは 1 つのミラーにしか属することができませんが、ミラー・メンバの制限数である 16 までなら、必要な数だけ 1 つのミラー内にメンバを構成することができます。

単一のミラーに接続された複数の DR 非同期メンバ

generated description: mirror async multiple

Note:

DR 非同期メンバは絶対に自動フェイルオーバーの候補とはなりません。自動フェイルオーバーは 1 つのフェイルオーバー・ミラー・メンバから別のフェイルオーバー・ミラー・メンバに対してのみ行われます。

レポート非同期

レポート非同期ミラー・メンバでは、データ・マイニングやビジネス・インテリジェンスなどを目的として、選択されたデータベースの読み取り専用または読み取り/書込みのコピーが保持されます。レポート非同期メンバをフェイルオーバー・メンバに昇格することはできません。1 つのレポート非同期は最大 10 個のミラーに所属でき、別々の場所から一連の関連データベースをまとめる包括的エンタープライズ・データ・ウェアハウスとして機能できます。

複数のミラーに接続された単一レポート非同期メンバ

generated description: mirror async single

シングル・フェイルオーバー・ミラーの構成

1 つのミラーを、単一のフェイルオーバー・メンバと 1 つ以上の非同期メンバで構成することができます。この構成では高可用性は実現されませんが、他のニーズに対処できます。例えば、単一のフェイルオーバー・メンバ、1 つ以上の DR 非同期メンバ、および複数のレポート非同期メンバで構成されるミラーでは、データの収集と保存をサポートする一方で、データ・セキュリティおよび災害復旧を実現できます。高可用性を実現するには、フェイルオーバー・メンバを OS レベルのフェイルオーバー・クラスタまたはその他の高可用性構成に配置できます (このドキュメントの “システム・フェイルオーバーの方法” の章を参照してください)。

単一のフェイルオーバー・メンバと複数の非同期メンバ

generated description: mirror single failover multiple asyncs

ISCAgent

ISCAgent と呼ばれるプロセスは各ミラー・メンバのホスト・システム上で実行され、ミラー・メンバ間の通信に追加の手段を提供します。最も重要なのは、ISCAgent では、一方のフェイルオーバー・メンバが、もう一方のメンバに関する情報を、これら 2 つのメンバ間の通常の通信が中断された場合でも取得できるようにする方法が提供されていることです。ISCAgent は、ダウンしていたり切断しているミラー・メンバにデータを送信できます。このエージェントは、フェイルオーバーの決定にも関係しています。例えば、プライマリのインスタンスともアービターとも通信が途絶えたバックアップは、プライマリのインスタンスが本当にダウンしていることを引き継ぎの前に確認するために、プライマリの ISCAgent と通信できます (プライマリのホスト・システムがまだ動作していることが前提)。

ISCAgent がまだインストールされていない場合には、Caché と共に自動的にインストールされます。1 つ以上のミラーに属する複数の Caché インスタンスが、1 つのシステムでホストされている場合、それらのインスタンスは、1 つの ISCAgent を共有します。

ISCAgent のロールおよび構成の詳細は、この章の "自動フェイルオーバーのメカニズム" および "ISCAgent の構成" を参照してください。

アービター

アービターは、ミラーのフェイルオーバー・メンバとの継続的な通信が維持される ISCAgent をホストする独立システムで、直接通信できない場合にフェイルオーバーの決定を安全に下すために必要なコンテキストで提供します。1 つのアービターで複数のミラーに対処できますが、1 つのミラーでは一度に 1 つのアービターしか使用できません。アービターの使用は必須ではありませんが、自動フェイルオーバーが可能となる障害シナリオの範囲が大幅に広がるため、使用することを強くお勧めします。

ミラーのフェイルオーバー・メンバとアービター

generated description: mirror failovers plus arbiter

アービターとしてシステムを構成するには、最小限のソフトウェア・インストールが必要ですが、Caché をインストールする必要はありません (ただし、2015.1 以降のバージョンの Caché インスタンスをホストする任意のシステムを使用することは可能です)。アービターは、最小限のシステム・リソースを使用するため、他のサービスをホストしているシステムに配置でき、ワークステーションにさえ配置できます。アービターに関する第一の要件は、アービターと単一のフェイルオーバー・メンバに同時に計画外の障害が発生するリスクを最小限に抑えるようにアービターを配置して、構成する必要があるということです。詳細は、"ミラーの可用性を最適化するためのアービターの配置" を参照してください。

ミラー同期

"Caché データ整合性ガイド" の “ジャーナリング” の章で述べているように、ジャーナル・ファイルには、最後のバックアップ以後、Caché インスタンスのデータベースで行われた変更の記録が時間順に含まれています。ミラー内では、プライマリ上のデータベースに加えられた変更を記録するジャーナル・データが、バックアップおよび非同期上のデータベースのコピーに同じ変更を加える際の基礎となります。このため、ミラーリングされたデータベースは常にプライマリ上でジャーナリングされる一方で、バックアップおよび DR 非同期上では、他のソースから更新されないように常に読み取り専用となります。通常、レポート非同期上でも読み取り専用です。

ミラーリングされたデータベースでグローバル更新処理 (主に Set 処理と Kill 処理) を記録するデータがプライマリでジャーナルに書き込まれると、ジャーナル・レコードは他のミラー・メンバに送信されます。バックアップまたは非同期メンバでジャーナル・レコードが受信されると、それらのレコードに記録されている処理がそのメンバ上のデータベースで実行されます。このプロセスはデジャーナリングと呼ばれます (非同期メンバでのデジャーナリングの管理に関する重要な情報は、"データベース・デジャーナリングの管理" を参照してください)。

プライマリからバックアップへのジャーナル・レコードの転送は同期的に実行され、プライマリはバックアップからの応答を重要なポイントで待機します。これによって、"バックアップ・ステータスと自動フェイルオーバー" で詳細に説明されているように、フェイルオーバー・メンバは緊密に同期され、バックアップはアクティブである状態が保持されます。一方、非同期はプライマリから非同期的にジャーナル・データを受信します。このため、非同期ミラー・メンバはプライマリよりジャーナル・レコードが数個分遅れている場合があります。

Note:

Caché インスタンスがミラーのメンバとなった場合、以下のミラーリング・サポート用のジャーナル変更が発生します。

Caché インスタンスがミラー内でプライマリ・フェイルオーバー・メンバとなった場合、以下の変更が生じます。
- MIRROR-mirror_name が先頭に付く新規ジャーナル・ファイル (MIRROR-MIR21-20120921.001 など) に対してのジャーナル切り替えが発動します。その時点より、すべてのジャーナル・ファイルはミラー・ジャーナル・ファイルとして書き込まれ、mirrorjrn-mirror_name.log (mirrorjrn-MIR21-20120921.log や journal.log など) にログが記録されます。
- [エラー発生時に凍結する] ジャーナリング構成は、ジャーナル入出力エラーが発生したときに自動的にオーバーライドされ、現在の設定に関係なく、ジャーナルされているグローバルの更新をすべて凍結します。現在の設定が [いいえ] の場合、インスタンスがプライマリ・フェイルオーバー・メンバでなくなったときに動作がこの設定に戻ります。この影響を把握するには、"Caché データ整合性ガイド" の “ジャーナリング” の章の "ジャーナルの設定" および "ジャーナル入出力エラー" を参照してください。
インスタンスがバックアップまたは非同期のミラー・メンバになるとき、プライマリから受信したミラー・ジャーナル・ファイルは、ローカル・インスタンスの標準ジャーナル・ファイルと共に、構成済みのジャーナル・ディレクトリに書き込まれ、プライマリのミラー・ジャーナル・ログ (mirrorjrn-mirror_name.log) のコピーが install-dir\Mgr に作成され、継続的に更新されます。

(ジャーナリング一般についての詳細は、"Caché データ整合性ガイド" の “ジャーナリング” の章を参照してください。)

自動フェイルオーバーのメカニズム

プライマリに障害が発生したり使用できなくなった場合にバックアップへの安全な自動フェイルオーバーを提供するようにミラーリングは設計されています。このセクションでは、この処理を可能にするメカニズムについて説明します。内容は以下のとおりです。

安全な自動フェイルオーバーの要件

バックアップの Caché インスタンスは、次の 2 つの条件が満たされることを確認できた場合にのみ、プライマリから自動的に引き継ぐことができます。

バックアップのインスタンスがプライマリから最新のジャーナル・データを受信した。
この要件によって、停止前にプライマリ上のミラーリング・データベースで行われた永続的な更新はすべて、バックアップ上の同じデータベースに対しても行われているか、またはこれから行われることが保証され、データが損失されることはなくなります。
プライマリのインスタンスは、もはやプライマリとしては動作しておらず、手動操作なしではプライマリとして動作できない。
この要件によって、両方のフェイルオーバー・メンバが同時にプライマリとして動作する可能性が除去されます。そのような状況が発生すると、論理データベースの性能低下と整合性の損失をまねくおそれがあります。

自動フェイルオーバーのルール

このセクションでは、自動フェイルオーバー・プロセスを制御し、双方の自動フェイルオーバー要件が確実に満たされようにするルールについて説明します。

Note:

以下の条件が当てはまらない場合、いかなる状況でもバックアップはプライマリ化を試行しません。

[開始時にマウントが必要] とマークされているすべてのデータベース (ミラーリングされるデータベースとミラーリングされないデータベースの両方) がマウントされている ("Caché システム管理ガイド" の “Caché の管理” の章の "ローカル・データベースのプロパティの編集" を参照)。
ミラーリングされるすべてのデータベースが有効化され、キャッチアップされている ("ミラーリングされるデータベースの有効化とキャッチアップ" を参照)。

バックアップ・ステータスと自動フェイルオーバー

通常のミラー処理中は、バックアップ・フェイルオーバー・メンバのジャーナル転送ステータスはアクティブになっており、プライマリからすべてのジャーナル・データを受信してプライマリと同期していることを意味します (フェイルオーバー・メンバのデータベースがジャーナル・データおよび関連する詳細を使用して同期される方法については、"ミラー同期" を参照してください。また、ミラー・メンバのステータスの監視については、"ミラーの監視" を参照してください)。アクティブなバックアップは、現在のジャーナル・データをプライマリで書き込まれたままの状態で受信し、アクティブなバックアップがジャーナル・データの受信を確認しそのデータを永続的と見なすのをプライマリは待機します。これによって、アクティブなバックアップは、フェイルオーバーの 1 つ目の条件を満たします。

アクティブなバックアップがサービス品質 (QoS) タイムアウト内にプライマリからの新しいデータの受信を確認しなかった場合、プライマリはバックアップのアクティブ・ステータスを取り消し、そのバックアップの接続を解除して、一時的に障害状態に入ります。障害状態の間、プライマリは新しいジャーナル・データをコミットしないので (おそらくアプリケーションでの一時停止を引き起こす)、2 つのメンバが非同期にはならずに通信をリストアする時間か適切で安全なフェイルオーバーの決定を下す時間を確保できます。

バックアップがプライマリに再接続すると、まずプライマリから最新のジャーナル・データをすべて取得することによってキャッチアップした後で、アクティブになります。バックアップが最新ジャーナル・データをプライマリから取得してその受信を確認することでキャッチアップすると、そのアクティブ・ステータスがリストアされます。

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

バックアップがアクティブな際、プライマリがプライマリとしては動作しておらずに操作員の操作なしでプライマリとして動作できないという 2 つ目のフェイルオーバー条件を確認できる場合、プライマリとして引き継ぐことができます。バックアップは次の 3 つの方法のいずれかで引き継ぎができます。

引き継ぎを要求するプライマリから通信を受信する方法。
これは、プライマリ・インスタンスの通常シャットダウン時またはハング状態をプライマリが検出した際に発生します。プライマリがこのメッセージを送信すると、プライマリとして動作できなくなり、アクティブなバックアップが安全に引き継ぐことができます。旧プライマリがハングした場合、新しいプライマリが旧プライマリを強制終了し、再起動したら新しいバックアップになることができるようにします。
プライマリとの通信を失ったという情報をアービターから受信する方法。
プライマリとバックアップの Caché インスタンスでは、アービターとの継続的な通信が維持されており、これによって、他方のフェイルオーバー・メンバとの通信が切断されたかリストアされだ場合は必ず、それぞれが更新されます。ネットワーク・イベントによってバックアップとアービターの両方から同時にプライマリが切り離された場合、無限に障害状態に入ります。このように、アクティブなバックアップがプライマリとの通信を失い、アービターもプライマリとの通信が途絶えていることをアービターから確認すると、バックアップは安全に引き継ぐことができます。プライマリは障害が発生しているか切り離されていて、障害状態に入っているため、プライマリとして動作できないことがわかるからです。接続が回復すると、前のプライマリがまだ障害状態で動作している場合、新しいプライマリはそれを強制終了します。
プライマリ・システムの ISCAgent から、プライマリのインスタンスがダウンまたはハングしているという情報を受信する方法。
アービターが利用できない場合や、アービターが構成されていない場合、プライマリ・インスタンスとの通信が途絶えたアクティブなバックアップは、プライマリの ISCAgent への通信を試行します (これは、プライマリのホスト・システムが動作を維持している場合のみ可能です)。これにより、プライマリ・インスタンスがダウンしているかどうかを確認し、ハング状態であった場合は強制終了させます。プライマリがプライマリとしての役割を果たせなくなっていて、そのためにフェイルオーバーが安全であることをエージェントが確認すると、バックアップがプライマリの役割を引き継ぎます。

ネットワーク・イベントによってプライマリがアクティブなバックアップから切り離されているが、バックアップでこれら 3 つの方法のいずれでも安全なフェイルオーバー状態を確保できない場合、バックアップはアクティブではなくなり、次のセクションで説明しているフェイルオーバー・メカニズムに従います。

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

アクティブでないバックアップは、プライマリの ISCAgent との通信を試行して、プライマリ・インスタンスがダウンしているかどうかを確認するか、ハング状態の場合は強制終了させて、エージェントからプライマリの直近のジャーナル・データを取得するよう試行できます。旧プライマリの終了を確認し、ジャーナルを取得したら、バックアップはプライマリとして安全に引き継ぐことができます。フェイルオーバーの後、旧プライマリは再起動されて新しいバックアップになります。

アクティブでないバックアップがプライマリの ISCAgent と通信できない場合、そのバックアップは、プライマリがプライマリとしての役割を果たせなくなっていることを確認する手段も、プライマリから最新のジャーナル更新を入手する手段もないため、プライマリの役割を引き継ぐことはできません。

バックアップがアクティブでない場合、フェイルオーバー・メカニズムでアービターが果たす役割は何もありません。

さまざまな停止シナリオに対するミラーの対応

このセクションでは、フェイルオーバー・メンバとアービターがさまざまな組み合わせで停止した場合のミラーの対応の概要を示します。

Note:

オペレータはフェイルオーバーを発動させずにプライマリ・システムを一時的にダウン状態にできます ("フェイルオーバー・メンバのメンテナンス時の不要なフェイルオーバーの回避" を参照)。これは、例えばメンテナンスのためにプライマリ・システムを非常に短時間ダウン状態にする必要がある場合に便利です。プライマリ・システムを稼働状態に戻した後、自動フェイルオーバーの既定の動作が復元されます。

ここで示すシナリオのいくつかでは、バックアップを手動で強制的にプライマリにするオプションに言及しています。この手順についての詳細は、"自動フェイルオーバーを使用しないプライマリ・フェイルオーバー・メンバの計画外停止" を参照してください。

プライマリ停止シナリオに対応した自動フェイルオーバー

状況も詳細も異なる中で、アクティブなバックアップ・フェイルオーバー・メンバによる自動引き継ぎが実行される主要なプライマリ停止シナリオがいくつかあり、それらを以下に示します。

例えばメンテナンスのためなど、プライマリの計画停止が、プライマリの Caché インスタンスをシャットダウンすることによって開始しました。
プライマリがアクティブなバックアップに引き継ぎを指示したために自動フェイルオーバーが発生します。
プライマリの Caché インスタンスが、予期しない状態によりハングしました。
プライマリがハングを検出し、アクティブなバックアップに引き継ぎを指示したため、自動フェイルオーバーが発生します。
予期しない状態により、プライマリの Caché インスタンスが強制的にダウン状態になり、完全に無応答になりました。
このシナリオでは、プライマリはバックアップに引き継ぎを指示できません。ただし、プライマリとの通信を失っていることをアービターから確認できた後か、プライマリの ISCAgent と通信してプライマリがダウンしていることを確認した場合、アクティブなバックアップが引き継ぎます。
プライマリのストレージ・サブシステムに障害が発生しました。
ストレージに障害が発生すると通常はその結果として、入出力エラーによりプライマリのインスタンスがハングします。この場合、プライマリはハングを検出して、アクティブなバックアップに引き継ぎを指示します (シナリオ 2 と同様)。ただし、場合によっては、シナリオ 3 またはシナリオ 5 で示した動作が当てはまることがあります。
プライマリのホスト・システムに障害が発生したか応答しなくなりました。
アクティブなバックアップがアービターから、プライマリとの通信が途絶えていることを確認できると、自動フェイルオーバーが発生します。
アービターが構成されていないか、またはプライマリのホストに障害が発生する前にアービターが使用不可になっていた場合、自動フェイルオーバーは発生しません。このような場合、1 つのオプションとして、バックアップを手動で強制的にプライマリにできます。
ネットワーク上の問題によってプライマリが切り離されました。
アービターが構成されていて、ネットワーク障害発生時に両方のフェイルオーバー・メンバがアービターに接続されていた場合、プライマリは無限に障害状態に入ります。
- プライマリとの通信が途絶えていることをアクティブなバックアップがアービターから確認すると、自動フェイルオーバーが発生します。
- バックアップがプライマリとの通信を失ったと同時にアービターとの通信も失った場合、自動フェイルオーバーはできません。両方のフェイルオーバー・メンバが稼働していれば、ネットワークのリストア時にバックアップはプライマリと通信します。これによってプライマリとして処理を再開します。または、プライマリを手動で指定できます。
アービターが構成されていないか、ネットワークに障害が発生する前にいずれかのフェイルオーバー・メンバが切断されていた場合、自動フェイルオーバーはできず、プライマリはプライマリとして動作し続けます。

アクティブではないバックアップ (起動中であるか、遅れを取ってしまっているため) は、前述のシナリオ 1 から 4 までの場合、プライマリの ISCAgent と通信して、最新ジャーナル・データを取得することで引き継ぐことができます。シナリオ 5 および 6 の場合、アクティブではないバックアップは、ISCAgent と通信できないため、引き継ぐことができません。このような場合、1 つのオプションとして、バックアップを手動で強制的にプライマリにできます。

Important:

2015.1 より前のバージョンの Caché では、シナリオ 5 および 6 の場合、バックアップの Caché インスタンスは、プライマリがプライマリとしては動作できなくなっていることを確認する方法がなかったため、これらのシナリオの場合は既定で、自動的に引き継ぐことはできませんでした。これらの古いバージョンでは、特別な条件の下、ユーザ指定の IsOtherNodeDown() エントリ・ポイントをユーザ定義の ^ZMIRROR ルーチンに追加して、[フェイルオーバーにエージェントの通信が必要] の設定をクリアすることにより、これらのシナリオの場合に自動フェイルオーバーを有効にすることができました。2015.1 以降は、このメカニズムは排除され、ここで説明しているアービターベースのフェイルオーバー・メカニズムに置き換えられています。この変更の詳細は、"Caché リリース・ノートおよびアップグレード・チェックリスト・アーカイブ" の “Caché 2015.1” を参照してください。

アービター停止の影響

アービターの停止がミラーの機能に直接的な影響を及ぼすことはありません。ただし、アービターがリストアされる前に、"プライマリ停止シナリオに対応した自動フェイルオーバー" に示したプライマリ停止シナリオの 5 または 6 が発生すると、バックアップによる自動的な引き継ぎができなくなります。

バックアップ停止の影響

アプリケーションによっては、プライマリが処理を再開する前に、短い間 (サービス品質タイムアウト程度の時間) 一時停止するものがあります。アービターが構成されていないか、バックアップの停止前にアービターが使用不可になっていた場合、発生する一時停止の時間はわずかに長くなることがあります (サービス品質タイムアウトの 3 倍程度の時間)。バックアップがリストアされる前にプライマリの停止が発生すると、ミラー全体の停止になります。

プライマリの停止とアービターの停止が組み合わさった場合の影響

このシナリオの結果は、"プライマリ停止シナリオに対応した自動フェイルオーバー" で説明しています。簡単に言うと、バックアップがプライマリの ISCAgent と通信できる場合は引き継ぎ、通信できない場合はミラー全体の停止となりますが、適切なオプションとして、手動操作によりバックアップを強制的にプライマリにできます。

バックアップの停止とアービターの停止が組み合わさった場合の影響

バックアップとアービターが同時に (またはほとんど同時に) 使用不可になった場合、プライマリは無限に障害状態のままです。これは、切り離されているからバックアップがプライマリになることができると見なされるためです。この結果、ミラー全体の停止となります。バックアップが再度使用可能になると、プライマリと通信します。これによってプライマリとして処理を再開します。または、プライマリを手動操作で強制的に再開することもできます。バックアップとアービターに順に障害が発生した場合、"バックアップ停止の影響" で説明した短い一時停止の後、プライマリはプライマリとして動作を続けます。これは、バックアップはプライマリになることができないと認識されるためです。

プライマリの停止とバックアップの停止が組み合わさった場合の影響

この組み合わせでは常に、ミラー全体の停止となります。この場合に使用可能なオプションについては、"両方のフェイルオーバー・メンバの計画外停止" を参照してください。

ミラーの可用性を最適化するためのアービターの配置

フェイルオーバー・メンバとアービターは共同でミラーリング高可用性ソリューションを提供します (アービターは最小限の役割を果たします)。アービターはクォーラム・メカニズムではなく、フェイルオーバー・メンバ間の通信が途絶えた場合にそれぞれにコンテキストを提供することにより、自動フェイルオーバーの処理で各フェイルオーバー・メンバをサポートします。どのような種類のプライマリ停止であってもその直前に両方のフェイルオーバー・メンバがアービターと通信しており、バックアップもアービターと通信している限り、自動フェイルオーバーができます。アービターに障害が発生すると、場合によっては自動フェイルオーバーが発生する可能性がなくなりますが、置換が構成されている際にミラーの動作を妨げることも、多くのプライマリ停止シナリオ (例えば、"プライマリ停止シナリオに対応した自動フェイルオーバー" のシナリオ 1 から 4) でのミラーによる自動フェイルオーバーの実行を妨げることもありません。

これらの理由により、それぞれが独立して高い可用性を持つフェイルオーバー・メンバよりもすぐれた高可用性をアービターが持つ必要はなく、アービターと単一フェイルオーバー・メンバに計画外の停止が同時に発生するリスクが最小限に抑えられるようにアービターを配置および構成することのみが必要です。(両方のフェイルオーバー・メンバに障害が発生するとミラーも失敗し、アービターのステータスは関係ないため、3 つすべてが同時に停止するリスクを考慮する必要はありません。)

この要件に基づいて、一般的に、フェイルオーバー・メンバが互いに分離されているのと同じだけ、アービターをフェイルオーバー・メンバから分離することをお勧めします。具体的には以下の処理を行います。

フェイルオーバー・メンバが 1 つのデータ・センタ内に配置されている場合、アービターを同じデータ・センタ内に配置できます。データ・センタ内で、フェイルオーバー・メンバが互いに物理的に分離されているのと同じだけ、アービターをフェイルオーバー・メンバから物理的に分離する必要があります。例えば、フェイルオーバー・メンバを別々のサーバ・ラックに配置して、1 つのラックに電力またはネットワークの問題が発生した際に両方のメンバに影響が及ばないようにしている場合、アービターをそれら 2 つのラックとは別に配置する必要があります。
データ・センタでミラー内の通信に内部ネットワークが使用されている場合、アービターをネットワークのパブリック側に配置して、内部ネットワーク内の障害によって、フェイルオーバー・メンバが互いに切り離されることも、アービターから切り離されることもないようにする必要があります。
フェイルオーバー・メンバが別々のデータ・センタ内に配置されている場合、アービターを 3 つ目の場所に配置する必要があります。その場所としては、別のデータ・センタ、別の関係者によってホストされている場所、パブリックまたはプライベートのクラウド・サービスのほか、システム管理者の自宅 (信頼できるネットワーキングを管理者が使用していることが前提) も考えられます。ユーザ・コミュニティを代表する場所にアービターを配置すると、ネットワーク停止時の最適なミラー対応を支援できます。

1 つのシステムを複数のミラーに対応するアービターとして構成できます (そのシステムが、各ミラーにとって適切なネットワークの場所にある場合)。

新しく配置されたシステムまたは専用のシステムでアービターをホストする必要はありません。実際、信頼性が適切に確立されている既存ホストが望ましい場合があります。レポート非同期ミラー・メンバ ("レポート非同期" を参照) が適切なホストとして機能できます。ただし、DR 非同期でのホストは避ける必要があります。メンテナンスまたは障害発生のシナリオでの DR 非同期の昇格 ("DR 非同期メンバのフェイルオーバー・メンバへの昇格" を参照) によって、アービターがフェイルオーバー・ミラー・メンバ上でホストされる可能性があり、これは間違った構成です。

Note:

"アービターのインストール" で説明するように、バージョン 2015.1 以降の ISCAgent を実行しているシステムは、そのシステムが 1 つ以上の Caché インスタンスをホストしている場合を含め、アービターとして構成できます。ただし、ミラーのフェイルオーバー・メンバまたは DR 非同期メンバを 1 つ以上ホストしているシステムは、そのミラーのアービターとして構成してはいけません。

自動フェイルオーバーのメカニズムの詳細

このセクションでは、フェイルオーバーのメカニズムに関して追加の詳細を提示します。

フェイルオーバー・メンバ間またはフェイルオーバー・メンバとアービター間の通信が途絶えた場合のミラーの対応は、次の 2 つの異なるミラー・フェイルオーバー・モードの使用によってサポートされます。

エージェント制御モード

ミラーの開始時に、フェイルオーバー・メンバはエージェント制御モードで動作を開始します。アービターが使用不可になっているか構成されていない場合、このモードのままです。エージェント制御モードでは、フェイルオーバー・メンバは、以下で説明しているように、お互いの間の通信の損失に対応します。

通信が途絶えた場合のプライマリの対応

プライマリからアクティブなバックアップへの接続が失われた場合、またはデータ受信の確認を待機している時間がサービス品質タイムアウトを超えた場合、プライマリはバックアップのアクティブ・ステータスを取り消して、障害状態に入り、アクティブでなくなったことがバックアップで確認するのを待機します。プライマリがバックアップからの確認を受信するか、障害タイムアウト (サービス品質タイムアウトの 2 倍) の時間が過ぎると、プライマリは障害状態から出て、プライマリとして動作を再開します。

プライマリからアクティブではないバックアップへの接続が失われた場合、プライマリとして動作を続け、障害状態には入りません。

通信が途絶えた場合のバックアップの対応

バックアップがプライマリとの接続を失った場合や、プライマリからのメッセージの待機時間がサービス品質タイムアウトを超えた場合、そのバックアップはプライマリの ISCAgent との通信を試行します。そのエージェントから、プライマリのインスタンスはプライマリとして引き続き動作していることが報告されると、バックアップは再接続します。プライマリがダウンしているか、プライマリが強制終了されていることをエージェントが確認すると、バックアップは以下のように動作します。

バックアップがアクティブで、プライマリが障害タイムアウトの範囲内でダウンしていることをエージェントが確認した場合、バックアップはプライマリの役割を引き継ぎます。
バックアップがアクティブでない場合や、障害タイムアウトを超過している場合、そのバックアップは、プライマリがダウンしていることをエージェントが確認して、エージェントから最新のジャーナル・データを取得できたときに、プライマリの役割を引き継ぎます。

バックアップは、アクティブであるかどうかにかかわらず、エージェント制御モードの状態で自動的にプライマリの役割を引き継ぐことはありません。ただし、プライマリ自体がプライマリのハング状態を確認した場合、またはプライマリのエージェントが (強制終了させた後で)プライマリのダウン状態を確認した場合を除きますが、どちらの状況も、プライマリのホストがダウンしている場合や、ネットワークから切り離されている場合は発生しません。

Note:

いずれかのフェイルオーバー・メンバが再起動すると、他方の ISCAgent との通信を試行し、その動作はアクティブではないバックアップで説明したものと同じになります。

アービター制御モード

フェイルオーバー・メンバが互いに接続していて、両方がアービターに接続しており、バックアップがアクティブな場合、アービター制御モードに入ります。このモードでは、フェイルオーバー・メンバは、お互いの間の通信が途絶えた場合に、アービターから提供される他方のフェイルオーバー・メンバに関する情報に基づいて対応します。それぞれのフェイルオーバー・メンバは、アービターとの接続の損失に対して、自身から他方のフェイルオーバー・メンバへの接続と、その逆の接続をテストすることによって対応するため、1 つのネットワーク・イベントから生じる複数の接続損失が、1 つのイベントとして処理されます。

アービター制御モードでは、いずれかのフェイルオーバー・メンバがアービターへの接続のみを失ったか、バックアップがアクティブ・ステータスを失った場合に、フェイルオーバー・メンバはエージェント制御モードへの切り替えを調整して、そのモードについて説明したように、さらなるイベントに対して対応します。

アービター制御モードで、プライマリとバックアップの間の接続が失われた場合、それぞれのフェイルオーバー・メンバは、以下に説明しているようにアービターとの接続状態に基づいて対応します。

プライマリがバックアップへの接続を失った場合

プライマリがアクティブなバックアップへの接続を失った場合や、データの受信確認を待機する時間がサービス品質タイムアウトを超過した場合に、アービターもバックアップへの接続を失っているか、バックアップからの応答を待機する時間がサービス品質タイムアウトを超過していることをアービターから通知された場合、プライマリはプライマリとしての動作を継続し、エージェント制御モードに切り替えます。

アービターがバックアップに接続されていることをプライマリで確認すると、障害状態に入り、アービターを通じてバックアップとエージェント制御モードへの切り替えの調節を試行します。調節した切り替えが実行されるか、またはバックアップがアービターにはもう接続されていないことをプライマリが確認すると、プライマリはプライマリとしての通常の動作に戻ります。

バックアップへの接続と同様にアービターへの接続もプライマリが失った場合、無限に障害状態のままになるため、バックアップは安全に引き継ぐことができます。フェイルオーバーが発生すると、接続のリストア時にプライマリはシャットダウンします。

Note:

障害タイムアウトは、アービター制御モードでは適用されません。

バックアップがプライマリへの接続を失った場合

バックアップがプライマリへの接続を失った場合や、プライマリからのメッセージを待機する時間がサービス品質タイムアウトを超過した場合に、アービターもプライマリへの接続を失っているか、プライマリからの応答を待機する時間がサービス品質タイムアウトを超過していることをアービターから通知された場合、バックアップはプライマリとして役割を引き継ぎ、エージェント制御モードに切り替えます。接続が回復すると、前のプライマリがまだ障害状態で動作している場合、新しいプライマリはそれを強制終了します。

アービターがプライマリに接続されていることをバックアップで確認すると、バックアップは自身がアクティブであるとは見なさなくなり、エージェント制御モードに切り替え、アービターを通じてエージェント制御モードへのプライマリの切り替えに合わせます。その後バックアップは、プライマリへの再接続を試行します。

プライマリへの接続と同様にアービターへの接続もバックアップが失った場合、エージェント制御モードに切り替えて、エージェント制御メカニズムを通じてプライマリの ISCAgent への通信を試みます。

失われた接続に対するミラーの対応

次の図は、アービター制御モードで起こりうる接続の損失のすべての組み合わせに対するミラーの対応を示しています。最初の 3 つの状況は、ネットワーク障害のみを表し、それ以外には、フェイルオーバー・メンバの視点から見て、システム障害とネットワーク障害のいずれか、またはそれらの組み合わせが関係している可能性があります。説明では、1 つ以上の接続が失われる直前には、フェイルオーバー・メンバおよびアービターはすべて互いに通信し合っていて、バックアップはアクティブであったことが前提となっています。

アービター制御モードでの接続の損失のほとんどの組み合わせに対して、ミラーは、エージェント制御モードに切り替えて対応します。このため、1 つの障害イベントが処理された後、すべての接続が再確立される前に生じる後続のイベントに対する対応は、この図で説明している動作ではなく、エージェント制御モードで説明した動作によって制御されます。

アービター・モードで失われた接続に対するミラーの対応

generated description: mirror response lost connections

自動フェイルオーバーの阻止

何らかの状況で、ミラーで自動フェイルオーバーが発生しないようにする場合、最善の方法として、単一のフェイルオーバー・メンバを 1 つ以上の DR 非同期で構成します ("非同期ミラー・メンバ" を参照)。DR 非同期は自動的に引き継ぐことはありませんが、必要に応じてプライマリも含めたフェイルオーバー・メンバに簡単に昇格できます ("DR 非同期メンバのフェイルオーバー・メンバへの昇格" を参照)。

メンテナンス処理中にバックアップに対して自動フェイルオーバーを一時的に阻止するには、バックアップを DR 非同期に一時的に降格するか、nofailover オプションを使用します。両方とも "計画的停止の手順" で説明されています。ここにはミラー処理を中断することなくフェイルオーバー・メンバにメンテナンスを実行する手順が示されています。

自動フェイルオーバー・プロセスのさまざまなポイントでアプリケーションの操作が必要な場合は、"^ZMIRROR ルーチンの使用法" を参照してください。

ミラーリング通信

このセクションでは、ミラー・メンバ間の通信について詳細に説明します。内容は以下のとおりです。

ネットワーク構成に関する考慮事項

2 つのフェイルオーバー・メンバ間でネットワークを構成する場合は、以下の一般的なネットワーク構成項目を考慮する必要があります。

信頼性 — 信頼性を最大限に高めるために、2 つのフェイルオーバー・メンバ間のミラー通信に対して、分離された (プライベート) ネットワークを構成する必要があります ("ミラーリング・アーキテクチャとネットワーク構成のサンプル" を参照)。さらに、このネットワークは冗長性を持たせて (ポートをフェイルオーバーボンディングした複数の NIC、複数の冗長スイッチなど) 構成する必要があります。
帯域幅 — アプリケーションによって生成されるジャーナル・データ量を転送するのに十分な帯域幅を使用できる必要があります。
遅延 — フェイルオーバー・メンバ間のネットワーク遅延は、アプリケーションのパフォーマンスにおいて重要な要素の 1 つです。詳細は、"ネットワーク遅延に関する考慮事項" を参照してください。

ミラー同期は、プライマリ・フェイルオーバー・メンバでのジャーナル書き込みサイクルの一部として行われます。ジャーナル書き込みサイクルおよびミラー同期プロセスをできる限り早く完了できることが重要です。このプロセスにおける遅延はすべて、パフォーマンスの低下につながる可能性があります。

Note:

VIP 使用時の重要なネットワーキング要件や考慮事項の詳細は、"ミラー仮想 IP (VIP) の構成" を参照してください。

ネットワーク遅延に関する考慮事項

フェイルオーバー・メンバ間のネットワーク遅延に厳格な上限はありません。遅延が長くなることによる影響は、アプリケーションごとに異なります。フェイルオーバー・メンバ間を往復する時間がディスク書込みサービス時間と似通っている場合、予期される影響はありません。ただし、データが保存されるのをアプリケーションが待機する必要があるとき (ジャーナル同期と呼ばれることがあります)、往復する時間が問題となる場合があります。ミラーリングされていない環境では、データの保存の待機には、ジャーナル・データの同期ディスク書き込みも含まれます。アクティブなバックアップが含まれるミラーリング環境では、フェイルオーバー・メンバ間のネットワーク往復時間も含まれます。データが保存されるのを多くのアプリケーションは待機することはないですが、それら以外のアプリケーションは頻繁に待機します。

アプリケーションの待機メカニズムに、以下の動作が含まれる場合があります。

同期コミット・モード (既定以外) でのトランザクションのコミット。
%SYS.Journal.SystemOpens in a new tab の Sync() メソッドまたはこれに相当する $zu 関数。
アプリケーション・サーバ上で実行されているアプリケーションからの一般的な要求に応答する前に、ECP データベース・サーバが保存を待機する動作 (ロックや $increment などのアプリケーション同期化アクションの一部として待機)。
Ensemble ビジネス・サービスの SyncCommit 機能 (既定)

往復時間が比較的長い場合でも、アプリケーションの応答時間またはスループットに悪影響を及ぼすかどうかは、アプリケーション内で前述の動作が発生する頻度、およびアプリケーションがそのような動作を順番に処理するのか、それとも並行して処理するのかによって異なります。

ミラー・メンバ間のネットワーク遅延が問題になる場合は、オペレーティング・システムの SO_SNDBUF と SO_RCVBUF の最大値を管理する TCP パラメータを微調整することで、遅延を短縮できる可能性があります。これにより、プライマリとバックアップ/非同期は、それぞれに適切なサイズの送信バッファと受信バッファを設置できるようになります (最大 16 MB)。必要になるバッファ・サイズは、往復時間に必要なピーク時の帯域幅 ("受信ジャーナルの転送速度" を参照) と、プロトコルのオーバーヘッドおよび将来の増加を乗算したものを約 2 倍した値になります。例えば、以下の条件が当てはまるとします。

プライマリ・ミラー・サイトと DR サイトとの間のトラフィックは、毎秒 60 MB のジャーナル・データ (ピーク時)。
帯域幅を減らすために使用する圧縮は、ジャーナル・レートの約 33% が求められている。
往復時間は、50 ミリ秒 (一般に、1000 マイルの距離にかかる時間)。

この場合、最小のバッファサイズは、60 MB * 0.05 * .33 * 2 = 2 MB になります。バッファ・サイズをできるだけ小さく抑える大きな理由はないため、この状況では、より大きな最小値を懸念なく試してみることができます。

ジャーナル・データの圧縮

ミラーの作成時または編集時には、以下に示すように、プライマリからバックアップに転送されるジャーナル・データに対して、3 つの圧縮設定のうちのいずれかを選択できます。それとは別に、プライマリから非同期メンバに送信されるジャーナル・データに対しても圧縮設定を選択できます。

システム選択 — ほとんどの環境に最適な圧縮方法を使用します。バックアップ・メンバへの転送の場合は、高帯域幅で低遅延の接続を前提として、応答時間を最適化することを意味します。つまり、ジャーナル・データは転送前に圧縮されるということです (圧縮により、フェイルオーバー・メンバの同期に必要な時間が短縮される場合)。非同期メンバへの転送の場合は、ネットワーク使用率を最適化することを意味します。[システム選択] は、フェイルオーバー・メンバと非同期の両方に対する既定の設定です。
現時点では、バックアップへの転送については、ミラーが SSL/TLS を必要とする場合にのみ、この設定で高速圧縮が使用されます ("SSL/TLS セキュリティを使用したミラー通信の保護" を参照)。非同期への転送については、高速圧縮が常に使用されます。この動作は、ネットワーク環境の分析メカニズムの向上と、圧縮動作の最適化に応じて、そのうちに変更される可能性があります。
圧縮なし — 転送前にジャーナル・データを圧縮しません。
圧縮 — 転送前に、常にジャーナル・データを圧縮します。

ほとんどの量のデータベース更新が圧縮済みまたは暗号化済みのデータで構成されている場合は、[圧縮なし] を選択することが望ましいです。この状況では、圧縮に期待できる全体的な効果はほとんどありません。この場合、圧縮にかける CPU 時間が無駄になる可能性があります。この例として、圧縮されたイメージ、圧縮されたメディア、またはデータベースに設定される前に (Caché のデータ要素暗号化などの暗号化手法を使用して) 暗号化されたデータなどが挙げられます。 Caché データベース暗号化またはジャーナル暗号化の使用は、圧縮を選択する際の要因にはなりません。

圧縮と SSL 暗号化は、どちらもスループットと遅延に影響する計算上のオーバーヘッドの原因になります。どちらが原因になるオーバーヘッドも同様のものですが、SSL 暗号化が使用されている場合は、追加の圧縮で暗号化する必要のあるデータの量を削減することで、実際にはオーバーヘッドを減らして、パフォーマンスを向上できます。詳細は、オペレーティング・システム、CPU アーキテクチャ、およびアプリケーション・データの圧縮率により変化します。具体的には、以下のようになります。

圧縮や SSL 暗号化の使用は、データの圧縮に必要な計算時間のために、ジャーナルの転送速度を制限することがあります。最大転送速度は、最大圧縮速度に限定されます。ほとんどの構成では、圧縮と SSL 暗号化によって決まる最大転送速度は、実際にミラーリングに必要とされる最大スループットよりも、はるかに高速になります。一例を挙げると、このドキュメントの執筆時点では、一般的なシステムにおける圧縮と暗号化に対する計算速度は、毎秒 100 MB 程度であり、大規模なエンタープライズ・アプリケーションに対するピーク時のジャーナル作成速度よりも数倍も高速です。
圧縮や SSL 暗号化の使用により、ネットワーク遅延に加算される “計算上の遅延” が発生します ("ネットワーク遅延に関する考慮事項" を参照)。ほとんどのアプリケーションで、これは無視できます。圧縮や SSL 暗号化を有効にすることで達成可能なスループットよりも、さらに高いスループットが要求される構成の場合は、圧縮や SSL 暗号化を無効にして (無効にしても、認証には SSL が使用できます)、圧縮なしのピーク時の転送に十分に対応できる帯域幅を用意する必要があります。

ミラー・メンバのネットワーク・アドレス

ミラー・メンバは、お互いに通信するために、いくつかのネットワーク・アドレスを使用します。これらについては、このセクションで説明しますが、"ミラーリング・アーキテクチャとネットワーク構成のサンプル" でも説明しています。ここで説明されているミラー・アドレスの一部またはすべてに、同一のネットワーク・アドレスが使用されている可能性があることに留意してください。

ミラー・プライベート・アドレス
1 つの Caché インスタンスがプライマリ・フェイルオーバー・メンバとして実行されている場合、その他のミラー・メンバはそれぞれミラー・プライベート・アドレスを使用して、自身のミラー・データ・チャンネルを確立します。これは、プライマリからのジャーナル・データの受信に使用するチャンネルであり、最も頻繁に使用されるミラー通信チャンネルです。バックアップになろうとする第 2 のフェイルオーバー・メンバは、このアドレスに接続する必要があります。これは、フェイルオーバー・メンバに昇格された DR 非同期にも当てはまります。昇格された DR が他方のフェイルオーバー・メンバのプライベート・アドレスにアクセスできなくても、他方のフェイルオーバー・メンバがダウンしたときにプライマリになることは可能ですが、バックアップになることはできません。
プライマリは、非同期メンバの監視のために、ミラー・プライベート・アドレスも使用することがあります。
非同期メンバは、プライマリのミラー・プライベート・アドレスに接続しようしますが、そのミラー・プライベート・アドレスでプライマリに到達できないと、プライマリのスーパーサーバ・アドレスにフォールバックします。これにより、また ISCAgent がジャーナル・データを他のミラー・メンバに送信できることにより、場合によっては、ジャーナル・データはミラー・プライベート・ネットワーク以外のネットワーク経由で転送されます。

Note:

管理ポータルを使用して非同期メンバをミラーに追加する際に ("非同期ミラー・メンバを構成する" を参照)、[非同期メンバ・アドレス] を入力します。このプロンプトで指定するアドレスは、非同期メンバのミラー・プライベート・アドレスおよびスーパーサーバ・アドレスになります。これらを異なったものにする場合、ミラーに追加した後に、プライマリで非同期のアドレスを更新できます。
スーパーサーバ・アドレス/ポート
このアドレスを使用して、外部ミラー認識システムをプライマリに接続できます。現時点では、そのような外部システムのみが ECP アプリケーション・サーバになります ("フェイルオーバーまたは災害復旧後のアプリケーション接続のリダイレクト" を参照)。ただし、将来、これは別の接続にも拡張される可能性があります。その他のミラー・メンバも特定の制御目的および監視目的のためにメンバのスーパーサーバ・アドレスに接続することがあります。例えば、プライマリは、非同期メンバの監視に、このアドレスを使用することがあります。プライマリのミラー・プライベート・アドレスにアクセスできない場合、非同期メンバはこのアドレスを使用してプライマリへのデータ・チャンネルを確立しようとします。これは、ジャーナル・データがこのネットワーク経由で転送可能であることを意味します。
エージェント・アドレス/ポート
このメンバのエージェントに通信しようとする場合、他のメンバはまずこのアドレスを試用します。重要なエージェント関数 (フェイルオーバーの決定に使用する関数など) は、このアドレスにアクセスできないと、ミラー・プライベート・アドレスおよびスーパーサーバ・アドレス (異なる場合) を使用して再試行します。エージェントはジャーナル・データを他のメンバに送信することができるので、ジャーナル・データはこのネットワーク経由で転送できます。
仮想 IP (VIP) アドレス
"ミラー仮想 IP (VIP) の計画" で説明しているように仮想 IP (VIP) アドレスを使用する場合、プライマリ・フェイルオーバー・メンバを作成または編集するときに VIP アドレスを入力する必要があります。プライマリは、プライマリになる処理の一環として自身をこのアドレスに動的に登録します。2 つのフェイルオーバー・メンバは、フェイルオーバーの発生時にバックアップが VIP を取得できるように VIP に関連付けられているネットワークの同じサブネットに配置する必要があります。管理者は通常、VIP アドレスに DNS サーバの DNS 名を指定します。このアドレスをミラーリング構成の他の場所で使用してはいけません (ECP クライアントの接続先のアドレスとしても使用してはいけません。ECP には、スーパーサーバ・アドレスを使用してプライマリを検索する独自のメカニズムがあります)。
アービター・アドレス/ポート (送信)
フェイルオーバー・メンバがアービターへの接続に使用するアドレスです。このアドレスは、プライマリ・フェイルオーバー・メンバを作成または編集するときに構成します。アービターのネットワーク上の場所に関する重要な情報は、"ミラーの可用性を最適化するためのアービターの配置" を参照してください。

ここで説明したアドレス間のミラー通信に対する SSL/TLS の構成は任意ですが、強くお勧めします。機密データがフェイルオーバー・メンバ間で受け渡しされるためです。SSL/TLS は、ISCAgent に対する認証を提供します。ISCAgent は、ジャーナル・ファイルへのリモート・アクセスを提供し、システムを強制的に停止したり、その仮想 IP アドレスを操作できます。詳細は、"SSL/TLS セキュリティを使用したミラー通信の保護" を参照してください。

ミラーリング・アーキテクチャとネットワーク構成のサンプル

このセクションでは、ミラーリング・アーキテクチャと構成のサンプルをいくつか示して説明します。

一部の図では、災害復旧 (DR) 非同期メンバおよびレポート非同期メンバがさまざまな位置に描かれています。いずれかまたは両方を省略することも、それぞれを複数許可することもでき、また概して、異なる図で描かれている位置を組み合わせることもできます。

図で示すことを目的として、組織の内部ネットワークのサンプル IPv4 アドレスが示されています。サブネットは 24 ビットで指定される (つまり、CIDR 表記 a.b.c.d/24 またはネットマスク 255.255.255.0) ことが前提となっているため、同じサブネットに対して記載されているアドレスは、4 番目のドット区切り部分のみが異なります。

ミラー構成の IP アドレスの代わりに、それに相当する DNS 名も指定されている場合があります。ただし、ミラー仮想 IP (VIP) アドレスの場合は IP アドレスである必要があるため、この限りではありません。

単一のデータ・センタ、コンピュータ・ルーム、またはキャンパス内のミラーリング構成

以下の図は、1 つのデータ・センタ、コンピュータ・ルーム、またはキャンパス内で一般的な、さまざまなミラーリング構成を示しています。それぞれの図は、該当するネットワーク・トポロジ、およびミラー構成に指定されているネットワーク・アドレスとのリレーションシップを示しています。バリエーションが示されており、特にミラー・メンバが同一キャンパス内の複数の場所に配置されている場合に適用できることがあります。

単純なフェイルオーバーのペア

generated description: mirror netconfig simple

これは、最も単純なミラー構成です。複数のフェイルオーバー・メンバはプライベート・ネットワーク経由で互いに通信し、それらへの外部接続はパブリック・ネットワークを通じて確立されます。オプションでミラー仮想 IP (VIP) が使用されます。アービターは外部ネットワーク上にありますが ("ミラーの可用性を最適化するためのアービターの配置" で推奨されているとおり)、アービターへの接続を開始するのは常にフェイルオーバー・メンバであることから、VIP はアービターへの接続には関連していません。

この構成では、以下の IP アドレスが使用されています。

generated description: mirror netconfig simple table

メモ：

VIP では、両方のフェイルオーバー・メンバが同一のサブネットに配置されている必要があります。
ミラーリングに必須というわけではありませんが、ネットワーク使用率を最適に制御できるように、ここに示しているミラー通信用の個別プライベート LAN をお勧めします。このような LAN を使用しない場合、緑の背景で示しているアドレスを使用するようにミラー構成でミラー・プライベート・アドレスを変更する必要があります。ここに示されているように、メンバがこのネットワークの同一サブネット上にあることをミラー・プライベート・アドレスは示唆していますが、これは必須ではありません。

DR およびレポートが均一に接続されたフェイルオーバーのペア

generated description: mirror netconfig asyncs homogenous

この構成では、DR 非同期で機能上の柔軟性が最大限にでき、災害復旧機能を実現できることに加えて、メンテナンスや修理のために停止しているフェイルオーバー・メンバに代わるために昇格できます。昇格された DR はバックアップまたはプライマリとして完全に機能することができ、VIP に追加されます。フェイルオーバー・メンバと DR は、VIP の同一パブリック接続サブネット上にあります。これらのプライベート・ネットワーク・アドレスが使用される場合、これらはお互いにアクセス可能です (同じサブネットではない場合は、ルーティングによって)。ネットワーク・トポロジおよびネットワーク遅延によって、DR と 2 つのフェイルオーバー・メンバとの間に可能な物理的な分離に、制約が加わる場合があります。

この構成では、以下の IP アドレスが使用されています。

generated description: mirror netconfig asyncs homogenous table

メモ：

VIP を保持または取得できるメンバはすべて同じサブネット上に配置する必要があります。
ここに示しているミラー通信用の個別プライベート LAN はミラーリングに必須ではありませんが、ネットワーク使用率の最適制御でお勧めします。このような LAN を使用しない場合、緑で示しているアドレスを使用するようにミラー構成でミラー・プライベート・アドレスを変更する必要があります。示されているミラー・プライベート・アドレスは、メンバがこのネットワークの同一サブネット上にあることを示唆していますが、これは必須ではありません。
レポート・メンバはプライマリになることはできないため、ミラー・プライベート・ネットワークでは送信接続のみを確立します。このため、そのアドレスを、ミラー構成で個別に指定する必要はありません。

DR およびレポートがキャンパス上の任意の場所にあるフェイルオーバーのペア

generated description: mirror netconfig asyncs anywhere

この構成では、非同期メンバの位置およびそれらに接続しているネットワークにおいて最大限の柔軟性を実現できます。この構成において DR が VIP サブネット上にあることは前提となっていないため、災害復旧時の DR へのユーザ接続のリダイレクトには、他の代替方法を使用する必要があります。例えば、VIP ではなく DR 非同期の IP をポイントするように DNS 名を手動で更新することや、"フェイルオーバーまたは災害復旧後のアプリケーション接続のリダイレクト" で説明したメカニズムのいずれかを構成できます。さらに、DR メンバがミラー・プライベート・ネットワーク (使用されている場合) に接続されていることは前提となっていないため、稼働中のフェイルオーバー・メンバがない場合に限り、プライマリにするためにのみ昇格できます。

この構成では、以下の IP アドレスが使用されています。

generated description: mirror netconfig asyncs anywhere table

メモ：

仮想 IP を取得するメンバはすべて、同じサブネット上に配置する必要があります。
ここでは、ミラー通信用の個別プライベート LAN が示されていますが、必須ではありません。このような LAN を使用しない場合、緑で示しているアドレスを使用するようにミラー構成でミラー・プライベート・アドレスを変更する必要があります。示されているミラー・プライベート・アドレスは、フェイルオーバー・メンバがこのネットワークの同一サブネット上にあることを示唆していますが、これは必須ではありません。

災害復旧およびレポート専用のミラーリング

generated description: mirror netconfig asyncs only

この構成では、DR とレポートのいずれかまたは両方の機能のみを提供するミラーリングを使用します。このドキュメントの“システム・フェイルオーバーの方法” の章で説明されているように、OS フェイルオーバー・クラスタリング、仮想 HA、またはその他のインフラストラクチャレベルのオプションを使用すると、単一のフェイル・オーバー・メンバの場合に高可用性が実現されます。この構成で自動フェイルオーバーにミラーリングは使用されないため、VIP は描かれていません。必要に応じて、障害復旧時に使用するために VIP を構成できますが、これには DR メンバをフェイルオーバー・メンバと同じサブネットに配置する必要があります。または、災害復旧時の DR へのユーザ接続のリダイレクトに、"フェイルオーバーまたは災害復旧後のアプリケーション接続のリダイレクト" で説明したような代替のテクノロジまたは手順を使用する必要があります。

この構成では、以下の IP アドレスが使用されています。

generated description: mirror netconfig asyncs only table

メモ：

ここでは、ミラー通信用の個別プライベート LAN が示されていますが、必須ではありません。このような LAN を使用しない場合、緑で示しているアドレスを使用するようにミラー構成でミラー・プライベート・アドレスを変更する必要があります。示されているミラー・プライベート・アドレスは、フェイルオーバー・メンバがこのネットワークの同一サブネット上にあることを示唆していますが、これは必須ではありません。
レポート・メンバはプライマリになることはできないため、ミラー・プライベート・ネットワークでは送信接続のみを確立します。このため、そのアドレスを、ミラー構成で個別に指定する必要はありません。

ECP を使用するミラーリング

generated description: mirror netconfig ecp

この図は、ミラーリング環境に追加された ECP アプリケーション・サーバを示しています。複雑性は高まりますが、ECP 層によって水平スケーラビリティが可能となり、データベース・サーバのフェイルオーバーを通してユーザ・セッションが保持されます。

この構成では、以下の IP アドレスが使用されています。

generated description: mirror netconfig ecp table

メモ：

ECP アプリケーション・サーバは VIP を使用せず、任意のフェイルオーバー・メンバまたは昇格されてプライマリになった DR メンバに接続するため、VIP はプライマリへのユーザの直接接続がある場合は、それのみに使用されます。VIP では、両方のフェイルオーバー・メンバが同一のサブネットに配置されている必要があります。DR メンバが昇格時に VIP を取得するには、同じサブネットに配置する必要もあります。同じサブネットに配置していない場合、"フェイルオーバーまたは災害復旧後のアプリケーション接続のリダイレクト" を参照してください。
ここに示されている ECP 通信とミラー通信のプライベート LAN は両方とも必須ではありませんが、ネットワーク使用率および ECP データのプライバシーを最適に制御するために使用することをお勧めします。いずれかのネットワークを別のネットワークに折りたたむことによって、ネットワーク数を少なくした構成が可能です。示されているプライベート・アドレスは、メンバがこれらのネットワークの同じサブネット上にあることを示唆していますが、唯一の要件は、これらのアドレスがお互いにルーティングできることです。
ネットワーク・レイアウトについて検討する場合は、すべての非同期メンバが、プライマリのミラー・プライベート・アドレスかスーパーサーバ・アドレスでプライマリに接続できる必要があることを忘れないでください。このように、示されている構成では、緑のユーザ・ネットワークにのみアクセスできる非同期メンバは機能しません。
レポート・メンバはプライマリになることはできないため、ミラー・プライベート・ネットワークでは送信接続のみを確立します。このため、そのアドレスを、ミラー構成で個別に指定する必要はありません。

2 つのデータ・センタと地理的に分離された災害復旧に対するミラーリング構成

以下の図は、データ・センタ、キャンパス、または地域に影響を与える災害から復旧するために地理的な分離を利用した HA および DR 構成を示しています。図を単純にするためにこれらの図からレポート・メンバは省略されていますが、単一キャンパス構成で示したとおりに、いずれかの場所に追加できます。

以下の構成にはすべて、他方の場所のメンバがプライマリになったときに、そのプライマリに接続をリダイレクトする方法が必要です。地理的に分離されている場所の場合、これら 2 つの場所にわたってサブネットを拡張することが必要であるため、VIP を構成することは難しいか、または不可能な場合があります。構成したとしても、以下の段落で説明しているように、十分ではない可能性があります。"フェイルオーバーまたは災害復旧後のアプリケーション接続のリダイレクト" で説明したような代替のテクノロジ、ハードウェア、または手順では、接続をリダイレクトする他の方法を使用できます。拡張されたサブネットを利用するかどうかにかかわらず、VIP は単一のデータ・センタ内の 2 つのメンバ間の自動フェイルオーバーにはきわめて有用であるため、以下の図では VIP の使用が描かれています。

VIP 用に拡張されたサブネットは通常、内部イントラネット・アプリケーションに役立ちます。これにより、緑で示されている LAN/WAN への接続 (つまり VPN アクセス) があるユーザおよびシステムは、VIP 経由でいずれかの場所にあるプライマリにアクセスできます。

一方、インターネットに接続するアプリケーションの場合、VIP 用に拡張されたサブネットが、災害時に接続のソリューションを提供することはありません。メイン・データ・センタの DMZ が、内部ミラー VIP のプロキシとして、アプリケーションのインターネット接続 IP アドレスと DNS 名のいずれかまたは両方を提供します。災害時には、これらを他方のデータ・センタに外部的に転送する必要がある場合があります。ソリューションには、高度な外部ルーティングまたは "フェイルオーバーまたは災害復旧後のアプリケーション接続のリダイレクト" で説明したいずれかの手法が使用されます。これらの手法のいずれでも、拡張されたサブネットの必要性は除去されます。

ローカル DR と地理的に分離された DR を使用したフェイルオーバーのペア

generated description: mirror netconfig localsep

ローカル DR 非同期は、一方または両方のフェイルオーバー・メンバに影響を与えるイベントの不測の事態に備えます。ローカル DR を昇格して、メンテナンスや修理のために停止しているいずれかのフェイルオーバー・メンバの代わりとすることも、両方のフェイルオーバー・メンバに影響を及ぼす災害からの復旧に使用することもできます。地理的に分離されている DR は、メイン・データ・センタまたはキャンパス全体に影響を及ぼす災害からの復旧に使用されます。

この構成では、以下の IP アドレスが使用されています。

generated description: mirror netconfig localsep table

メモ：

VIP の前述の説明を参照してください。
可能な場合、ミラー・プライベート・ネットワーク (使用されている場合) に、データ・センタ相互接続 (WAN) を使用して DR データ・センタからアクセスできるようにすると、メンバ J にさらに機能上の柔軟性がもたらされます。これには、サブネットの拡張は必要ではなく、対象のネットワーク上のトラフィックをデータ・センタ間でルーティングすることだけが必要です。この構成では、J を昇格した場合、メイン・データ・センタのプライマリにバックアップとして接続できます。DR にミラー・プライベート・ネットワークへのアクセス権がない場合、プライマリとして機能させるためだけに昇格でき、稼働中のフェイルオーバー・メンバがない場合にのみこれは可能です。ここで述べた柔軟性は主として、VIP が拡張されていて、アプリケーションがデータ・センタ間の遅延に実質上は影響を受けない構成において有用です。

地理的に分離されていて、完全に冗長な DR 環境を使用したフェイルオーバーのペア

generated description: mirror netconfig redundant

データ・センタ 1 に影響を及ぼす災害の発生時には、データ・センタ 2 内の 2 つの DR メンバが昇格され、完全に冗長な代替 HA 環境が提供されます。この構成では、以下の IP アドレスが使用されています。

generated description: mirror netconfig redundant table

メモ：

VIP の前述の説明を参照してください。この図では、拡張されたサブネットは前提となっていません。代わりに、データ・センタ 2 への移行時に、そのデータ・センタ内での後続の自動フェイルオーバーに別の VIP を使用するようミラーが再構成されます。外部のテクノロジ、ハードウェア、または手順は、"フェイルオーバーまたは災害復旧後のアプリケーション接続のリダイレクト" で説明したように、この新しい VIP アドレスへの接続のリダイレクトに使用されます。
可能な場合、両方のデータ・センタから、データ・センタ相互接続 (WAN) を使用してミラー・プライベート・ネットワーク (使用されている場合) にアクセスできるようにすると、機能上の柔軟性がもたらされます。これには、サブネットの拡張は必要ではなく、対象のネットワーク上のトラフィックをデータ・センタ間でルーティングすることだけが必要です。この構成では、一方のデータ・センタ内の昇格された DR メンバが、バックアップとして他方のデータ・センタ内のプライマリに接続できます。これは主として、VIP が拡張されていて、アプリケーションがデータ・センタ間の遅延に実質上は影響を受けない構成において有用です。(DR にミラー・プライベート・ネットワークへのアクセス権がない場合、プライマリとして機能させるためだけに昇格でき、稼働中のフェイルオーバー・メンバがない場合にのみこれは可能です。)
データ・センタ 1 が完全にオフラインになり、メンバ J および K がフェイルオーバー・メンバに昇格された場合、新しいアービターをデータ・センタ 2 で使用可能にすることができ、ミラー構成を新しいアービターの IP アドレスで更新することができます。示されている構成では、反対側のデータ・センタで 2 つのフェイルオーバー・メンバを使用して長時間動作することは意図されていません。このように動作する場合、別の 3 つ目の場所 (この描画ではインターネット) にアービターを配置することをお勧めします。詳細は、"ミラーの可用性を最適化するためのアービターの配置" を参照してください。

地理的に分離されたフェイルオーバーのペア

generated description: mirror netconfig failoversep

この構成では、別個の場所で 2 つのマシンを利用して、最小限のハードウェアで高可用性と災害復旧の両方のニーズを満たします。フェイルオーバー・メンバ間のネットワーク遅延は、重要な考慮事項の 1 つですが、その影響がある場合、それはアプリケーションによって異なります。詳細は、"ネットワーク遅延に関する考慮事項" を参照してください。

ミラーリングでは、1 つのフェイルオーバー・メンバがプライマリとして動作するためにもう 1 つのフェイルオーバー・メンバより優先されることはなく、フェイルオーバーはあらゆるタイプの停止の結果として生じ、これはプライマリ上の問題が一時的なものであったことがわかった場合でも当てはまります。このため、この構成は、特定のデータ・センタで実行されているプライマリに暗黙的な優先順位がない場合に最適です。

この構成では、前述の説明で示されている理由により、VIP の使用は可能かどうかはわかりません。2 つのデータ・センタ間のフェイルオーバーは自動的に発生するため、採用する代替方法では、ユーザを迅速に自動で新しいプライマリにリダイレクトする必要があります。手動操作が必要な方法は通常、十分ではありません。

この構成では、以下の IP アドレスが使用されています。

generated description: mirror netconfig failoversep table

メモ：

この構成では、アービターは、3 つ目の場所に配置することが最適です。詳細は、"ミラーの可用性を最適化するためのアービターの配置" を参照してください。
ここでは、データ・センタ相互接続 (WAN) 経由で実行されるミラー通信のプライベート・ネットワークが描かれていますが、これは必須ではありません。

フェイルオーバーまたは災害復旧後のアプリケーション接続のリダイレクト

バックアップ・フェイルオーバー・メンバが自動フェイルオーバーによってプライマリになるか、DR 非同期を手動で、災害復旧の一部としプライマリに昇格する場合、アプリケーション接続を新しいプライマリにリダイレクトするメカニズムが必要です。これを実現する方法は多数ありますが、この章ではそのいくつかを詳しく取り上げます。1 つのソリューションを自動フェイルオーバーと DR の昇格の両方に適用することも、複数のソリューションを組み合わせることもできます。例えば、自動フェイルオーバーにはミラー VIP を使用し、DR の昇格には DNS の更新を使用する方法です。

組み込みのメカニズム

"ミラーリング・アーキテクチャとネットワーク構成のサンプル" で示しているように、ミラー構成に以下のメカニズムを追加して、アプリケーションのリダイレクトに対処できます。

ミラー仮想 IP アドレス (VIP)
ミラー VIP が使用されていて ("ミラー仮想 IP (VIP) の計画" を参照)、メンバがプライマリになった場合、VIP が新しいプライマリ上のローカル・インタフェースに自動的にバインドされます。これにより、外部クライアントは同じ IP アドレスに引き続き接続できます。"ミラーリング・アーキテクチャとネットワーク構成のサンプル" で示しているように、VIP の使用では、メンバが同一のサブネット上でプライマリになることが可能である必要があります。
ECP (Enterprise Cache Protocol)
ECP ミラーの配置 ("ミラーへの ECP 接続の構成" を参照) では、フェイルオーバー・メンバを ECP データ・サーバとして構成し、すべての ECP アプリケーション・サーバの接続を具体的にミラー接続として構成します。フェイルオーバーに続き、アプリケーション・サーバが新しいプライマリ・フェイルオーバー・メンバへのそれぞれの接続を再確立し、進行中の作業負荷を引き続き処理します。フェイルオーバー・プロセスの実行中は、アプリケーション・サーバに接続しているユーザが作業に復帰する前に、接続が一時的に中断することがあります。ECP リカバリの詳細は、"Caché 分散データ管理ガイド" の “ECP” の章および “分散アプリケーションの開発” の章を参照してください。
ECP によって複雑性が増すうえ、通常はロード・バランサ (またはその他の外部テクノロジ) を使用してユーザをアプリケーション・サーバにダイレクトする必要があることに留意してください。
CSP ゲートウェイ
CSP ゲートウェイのサーバ・アクセス・エントリがミラー認識で構成されている場合、ゲートウェイは初期構成でフェイルオーバー・メンバのいずれかに接続され、そのメンバからミラー内のフェイルオーバーおよび DR 非同期メンバのリストを取得します。ゲートウェイはこのリストに基づいて現在のプライマリを識別して接続します。ミラーがフェイルオーバーした場合、ゲートウェイは新しいプライマリに接続を変更します。フェイルオーバー・メンバの中でプライマリが見つからない場合、ゲートウェイはリスト内の DR 非同期の中からプライマリを見つけようと試みます。これにより、DR 非同期がプライマリに昇格するとゲートウェイは接続を再確立できます。ミラー認識構成のゲートウェイ接続では、スーパーサーバ・アドレスを使用してミラー・メンバと通信します ("ミラー・メンバのネットワーク・アドレス" を参照)。
ミラー VIP を構成した場合は、ミラー認識 CSP ゲートウェイを構成しないでください。構成すると、ゲートウェイが VIP を無視する原因となります。その代わり、他のクライアントと同様に、単に CSP ゲートウェイを VIP に接続するように構成します。一般的に、ミラー認識 CSP ゲートウェイの使用は特殊な状況下でのみ適切な選択といえます。
既定では、サーバ・アクセス・エントリはミラー認識ではありません。これは、Caché 管理ポータルをサポートしているゲートウェイ・サーバなど、多くのゲートウェイ・サーバ構成に適していないためです。ミラー認識 CSP ゲートウェイ接続の詳細は、"CSP ゲートウェイ構成ガイド" の “CSP ゲートウェイの動作と構成” の章の "サーバ・アクセスの構成" を参照してください。

外部テクノロジ

ミラーリングと併用して以下のメカニズムを実装し、アプリケーションのリダイレクトに対処できます。

ハードウェアによるロード・バランサおよびサイト選択機能
ハードウェアによるサイト選択機能などのメカニズムを使用して、ネットワーク・レベルでアプリケーション・トラフィックをリダイレクトする機能を実装できます。
DNS の更新
自動および手動のオプションを使用できます。一部のオプションは、自動フェイルオーバーで使用するには遅すぎる場合があります。
アプリケーションのプログラミング
ミラー・メンバの情報を保持して、現在のプライマリに接続するように、個々のアプリケーションを適合させることができます。
ユーザ・レベルの手順
複数のミラー・メンバに接続する手段をユーザに提供できます。例えば、災害復旧サイトに接続するための 2 つ目のアイコンなどです。

ミラー仮想 IP (VIP) の計画

"組み込みのメカニズム" で説明したように、ミラー VIP が使用されていてメンバがプライマリになると、VIP は新しいプライマリに再割り当てされます。これにより、どちらのフェイルオーバー・メンバが現行プライマリとして動作しているかに関係なく、すべての外部クライアントおよび接続が単一の静的 IP とやりとりできます。

フェイルオーバー・プロセス中に、接続しているネットワークが切断されたクライアントは、バックアップがプライマリになると再接続できます。VIP が構成されている場合、バックアップは VIP の正常割り当てが可能な場合のみフェイルオーバーを完了します。そうでない場合、フェイルオーバー・プロセスは中止され、ミラーには手動操作が必要になります。

ミラー VIP の設定準備においては、以下について検討します。

ミラー VIP を使用するには、両方のフェイルオーバー・メンバが同じサブネットに構成され、VIP が各システムで選択されているネットワーク・インタフェースと同じサブネットに属している必要があります。DR 非同期メンバは、災害復旧の一部としてプライマリに昇格した場合は、VIP を取得できるように同じサブネット上にネットワーク・インタフェースを有している必要があります。それ以外の場合は、災害復旧の手順に代替のリダイレクト・メカニズムを組み込む必要があります。
フェイルオーバー・メンバまたは DR 非同期メンバが別々のデータ・センタにある場合、VLAN サブネットをデータ・センタ間に拡張して、同じ VIP アドレスをサポートし続けることができます。これには、2 つのサイト間にレイヤ 2 接続が必要ですが、すべての状況で十分であるとは言えません。"2 つのデータ・センタと地理的に分離された災害復旧に対するミラーリング構成" の説明を参照してください。
クライアントの接続に使用するために、DNS サーバ上の VIP に DNS 名を割り当てる必要があります。
VIP が使用中であり、フェイルオーバー・メンバが VIP サブネットから削除される場合、そのメンバは DR 非同期に降格させるか ("バックアップの DR 非同期への降格" を参照)、またはミラーから削除する必要があります。あるいは、VIP 構成を両方のフェイルオーバー・メンバから削除する必要があります。そのようにしないと、フェイルオーバー・メンバがプライマリとして引き継ぎを試行しても、VIP の獲得に失敗し、プライマリになることができません。

Important:

Windows Vista、Windows 7、または Windows Server 2008 システムでミラー VIP を構成し、クライアントが複数の異なるサブネットからのフェイルオーバー・メンバに接続する場合、VIP の構成後に NDISISC ドライバをインストールして起動する必要があります。この操作には、以下の手順を使用します。

Windows の [コントロールパネル] で、[ネットワークと共有センター] を開き、[アダプターの設定の変更] を選択して [ネットワーク接続] パネルを表示します。
ミラー VIP 用に構成したインタフェース名と一致するネットワーク・アダプタ (インタフェース) を右クリックして [プロパティ] を選択します。
[プロパティ] ダイアログ・ボックスで、[インストール] をクリックして [プロトコル] を選択し、[追加] をクリックします。
次のダイアログ・ボックスで、[ディスク使用] を選択し、install-dir\ndis\ndis.inf ファイルを探して選択します。[OK] をクリックして選択したドライバのインストールを確定します。
管理者として、コマンド行で sc start ndisisc コマンドを発行し、NDISISC ドライバを起動します。

NDIS ドライバのインストールに関する質問については、インターシステムズのサポート窓口Opens in a new tabまでお問い合わせください。

1 つ以上のミラー・メンバが、UNIX® または Linux システム上の非 root Caché インスタンスの場合、"Caché インストール・ガイド" の “UNIX® および Linux への Caché のインストール” の章にある、"Caché 非 root インストール" で説明されているように、ミラー VIP は使用できません。

1 つ以上のミラーのメンバが、ip-type=shared による Oracle Solaris の非グローバル・ゾーンで実行している Caché インスタンスの場合、ミラー VIP は使用できません。

仮想環境でのミラーリング

仮想化環境でミラーリングを使用すると、ミラーを構成する Caché インスタンスは仮想ホストにインストールされ、ミラーリングの利点と仮想化の利点を併せ持つハイブリッド高可用性ソリューションが実現します。ミラーは計画的または計画外の停止に自動フェイルオーバーで即座に対応し、仮想 HA ソフトウェアは計画外のマシンの停止や OS の停止後にミラー・メンバをホストする仮想マシンを自動的に再起動します。これにより、障害が発生したメンバは、すぐにミラーに再参加できるようになり、バックアップとして動作します (必要であればプライマリを引き継ぎます)。

ミラーを仮想化環境で構成する場合は、次の推奨事項が適用されます。

フェイルオーバー・メンバの仮想ホストは、同じ物理ホスト上に配置するようには構成しないでください。
単一障害点を回避するには、フェイルオーバー・メンバ上の Caché インスタンスによって使用されるストレージは、個別のディスク・グループまたはストレージ・アレイ上の個別のデータストアに恒久的に分離しておいてください。
仮想プラットフォーム・レベルで実行される一部の操作 (バックアップや移行など) により、フェイルオーバー・メンバが長い時間応答しなくなって不要なフェイルオーバーや望ましくない頻度の警告が発生することがあります。この問題に対処するために、サービス品質タイムアウトの設定値を大きくしてください ("サービス品質タイムアウト" を参照)。
フェイルオーバー・メンバの接続中断をもたらすような、計画的なメンテナンスを実施する場合は、不要なフェイルオーバーと警告を避けるために、一時的にバックアップでのミラーリングを停止することができます。
スナップショット管理は、ミラー・メンバに対しては注意深く使用する必要があります。メンバを以前のスナップショットに戻すと、メンバの最新のステータス (例えば、スナップショットが取られて以降にプライマリからバックアップに変更が加えられている場合など) と、他のメンバにより継続して処理されているジャーナル・データの両方が消去されてしまうことになります。特に次の事柄には注意してください。
- 以前のスナップショットに戻されているフェイルオーバー・メンバは、必ず電源オフの状態から再開してください。電源オンの状態から再開すると、両方のフェイルオーバー・メンバが同時にプライマリとして動作する可能性が生じます。
- 以前のスナップショットに戻されたフェイルオーバー・メンバが、スナップショット以降に作成されたすべてのジャーナル・データを取得せずにプライマリになる場合 (例えば、強制的にプライマリにされる)、他のすべてのミラー・メンバを再構築する必要があります ("ミラー・メンバの再構築" で説明しています)。

Note:

VMware ESXi 5.5 以降の環境に Caché 2015.1 以降を配置するときの構成、システムのサイズ設定および処理能力の計画についての一般的なガイドラインは、インターシステムズのシニア・テクノロジ・アーキテクトによって書かれた InterSystems Developer Community の "InterSystems Data Platforms and performance – Part 9 Caché VMware Best Practice GuideOpens in a new tab" を参照してください。

バックアップ・フェイルオーバー・メンバへのアクセスの制限

ミラーのバックアップ・フェイルオーバー・メンバをホストするシステムに未使用のリソースまたは容量がある場合、またはそのミラーリングされたデータベースに読み取り専用のクエリを実行する場合、そのホストをバックアップ・ミラー・メンバとしての役割に専念させることを最善の方法としてお勧めします。バックアップをミラー関連としてまたはミラー以外に使用すると、以下の影響が生じる可能性があります。

バックアップのパフォーマンス低下によって、プライマリからのジャーナル・データの受信確認が遅くなると、プライマリ上のミラーリングされたデータベースにアクセスするアプリケーションのユーザに対してパフォーマンスの低下が生じる場合があります。プライマリによる確認を待機する必要があるアプリケーション対話は、明示的なジャーナル同期化、同期コミット・トランザクション、ECP アクティビティなどが関連するものを含め、すべてこのように影響を受ける可能性があります。
バックアップからの確認が遅くて、サービス品質タイムアウトの時間内に行われない場合、プライマリはバックアップのアクティブ・ステータスを取り消すので、プライマリ停止のタイプによっては、自動フェイルオーバーがより困難になるか不可能になります。
自動フェイルオーバーが発生したときに、バックアップが自身の既存のリソース使用とプライマリのユーザ・アプリケーションのリソース使用の両方をサポートします。これが起こりうる場合、バックアップのホストには、これらの負荷を両方とも処理できる容量が必要です。

これらの理由により、ユーザの操作をプライマリからオフロードする必要がある場合、バックアップではなく、非同期メンバを使用する必要があります。

単一ホストへの複数のミラー・メンバのインストール

ミラーを構成する Caché インスタンスは通常、別個の物理ホストまたは仮想ホストにインストールされますが、それは要件ではありません。パフォーマンスを低下させることなく、関係するリソース負荷を処理するのに十分な容量がシステムにあるとすれば、複数のミラー・メンバを同一ホストにインストールできます。個々の状況で、これが実現可能かどうか、またいくつのミラー・メンバをコホストできるのかを判断します。

複数のフェイルオーバー・メンバをコホストする場合、フェイルオーバー・ミラーリングでは、メンバは同等と見なされることに留意してください。優先されるプライマリ・メンバはありません。このため、フェイルオーバー・メンバのインスタンスを個別のホストに配置する際の最善の方法は、容量においてそれらのホストを可能な限り同じ、つまりほぼ同等にすることです。フェイルオーバー・メンバのコホストでは、対象モデルの境界の外に出る可能性があります。例えば、5 つのミラーを 5 つの個別ホストに作成して、1 つのホスト上の 5 つの Caché インスタンスを第 2 のフェイルオーバー・メンバとしてミラーに追加した場合、ミラーは最初、個別ホスト上の各プライマリと単独システムでコホストされているすべてのバックアップとを使用して動作します。ところが、フェイルオーバーに至る 2 つの同時、またはほとんどの同時の停止があると、単独システムで 2 つのプライマリと 3 つのバックアップをホストすることになり、適切なパフォーマンスを確保しながら処理するには、システムにとって負荷が大きくなりすぎる可能性があります。

複数のミラー・メンバをコホストする場合、各ミラーが各マシンで一意のポート・セットを使用し ("ミラー・メンバのネットワーク・アドレス" を参照)、コホストされていない他のミラー・メンバが同じポートを使用するよう設定する必要があります。例えば、2 つの個別ホスト上で実行されている 2 つのプライマリが両方ともポート 1972 を使用しているが、コホストされている DR 非同期メンバに両方が置き換えられた場合、前述の説明で示したように、新しいプライマリでは使用できません。1 つのプライマリがポート 1972 を使用し、もう 1 つのプライマリが 1973 を使用し、これらと同じポートが非同期で構成されていると、非同期は同時昇格の準備ができているので、発生時にクライアントは停止前と同じポートを使用してミラーにアクセスできます。さらに、各ミラーには独自の VIP が必要です。

1 つ以上のミラーに属する複数の Caché インスタンスがコホストされている場合、それらのインスタスは 1 つの ISCAgent を共有します。

ミラー・メンバのコホストは、各ミラーに対応するアービターのネットワークの位置に影響を与えません ("ミラーの可用性を最適化するためのアービターの配置" を参照)。関与するミラーは、アービターを共有することも、個別のアービターを使用することもできます。ただし、フェイルオーバー・メンバとアービターが適切に配置されている必要があります。

ミラーリングの構成

このセクションでは、ミラーとミラー・メンバの設定、構成、および管理について説明します。

ミラー構成のガイドライン

強固でコスト効率のよい HA ソリューションを提供するために、ミラーリングは、さまざまなシステム構成およびアーキテクチャに適応できるように設計されています。ただし、以下の一般的な構成ガイドラインに従うことをお勧めします。

Caché インスタンスおよびプラットフォームの互換性ミラーに追加するシステムを特定する前に、"Caché インスタンスの互換性" および "メンバのエンディアンに関する考慮事項" を参照してください。
フェイルオーバー・メンバの平等性 — 1 つのミラー内の 2 つのフェイルオーバー・メンバは平等であると見なされます。一方をプライマリとする優先順位を構成することはできません。また、必要に応じてプライマリとバックアップのロールは入れ替わります。このため、最適な方法として、フェイルオーバー・システムのホストが可能な限り互いに類似するように、特に類似したコンピュータ・リソースで構成します。つまり、2 つのシステムの CPU、メモリ構成、およびディスク構成に互換性を持たせて構成します。
プライマリ・インスタンス構成およびセキュリティ設定 — プライマリ・フェイルオーバー・メンバ上のユーザ、ロール、ネームスペース、およびマッピング (グローバル・マッピングとパッケージマッピングを含む) などの要素の構成は、他のミラー・メンバ上のミラーにより複製されることはありません。したがって、バックアップ・フェイルオーバー・メンバまたは DR 非同期メンバが効率的にプライマリからの引き継ぎを行うために必要な設定はいずれも、必要に応じてそれらメンバに手動で複製し、更新する必要があります。
ミラーリングされないデータ — プライマリ・フェイルオーバー・メンバのミラーリングされるデータベースにおけるデータのみが、バックアップ・フェイルオーバー・メンバまたは非同期メンバ上で複製され、同期を保ちます。したがって、バックアップまたは DR 非同期が効率的にプライマリから引き継ぎを行うために必要なファイルはすべて (例えば、SQL ゲートウェイおよび Web サーバの構成に関連するものを含む)、必要に応じて、それらのメンバに手動でコピーして更新する必要があります。

Note:

ミラーリングされたデータベースのファイル・ストリームは、デフォルトではデータベース・ディレクトリの stream サブディレクトリにあり、ミラーリングされません (ファイル・ストリームの詳細は、"クラスの定義と使用" の “ストリームを使用した作業” の章を参照してください)。
ICMP — ミラーリングはメンバへのアクセス可否の検出をインターネット制御メッセージ・プロトコル (ICMP) に依存しているため、ミラー・メンバとして構成されているすべてのシステムで、ICMP を無効にしないでください。
ネットワーク — 2 つのフェイルオーバー・メンバ間で、広帯域かつ低遅延の、信頼性の高いネットワークを使用することをお勧めします。可能であれば、2 つのフェイルオーバー・メンバ用にプライベート・サブネットを作成し、このプライベート・ネットワークにデータ・チャンネル・トラフィックと制御チャンネル・トラフィックを専用でルーティングできるようにすることをお勧めします。ネットワークが遅いと、プライマリ・フェイルオーバー・メンバとバックアップ・フェイルオーバー・メンバの両方のパフォーマンスに影響する可能性があり、フェイルオーバー時にバックアップ・フェイルオーバー・メンバがプライマリを引き継ぐときに直接的な影響を及ぼす可能性があります。ネットワーキングにおける要件および構成に関する詳細は、"ネットワーク構成に関する考慮事項" および "ネットワーク遅延に関する考慮事項" を参照してください。また、VIP 使用時の重要なネットワーキング要件や考慮事項の詳細は、"ミラー仮想 IP (VIP) の構成" を参照してください。
ディスク・サブシステム — バックアップ・フェイルオーバー・メンバをプライマリ・システムと同じ状態に保つためには、両方のフェイルオーバー・メンバのディスク・サブシステムが同等である必要があります。例えば、第 1 のフェイルオーバー・メンバにストレージ・アレイを構成する場合は、第 2 のフェイルオーバー・メンバにも同様のストレージ・アレイを構成することをお勧めします。また、ネットワーク接続ストレージ (NAS) が一方または両方のシステムで使用されている場合は、ディスク I/O とミラー・データからのネットワーク負荷に対して別々のネットワーク・リンクを構成し、ネットワークのオーバーフローの可能性を最小限に抑えることを強くお勧めします。
ジャーナリングのパフォーマンスおよびジャーナルのストレージ — ジャーナル/ディジャーナルはミラー同期の中核を成す機能なので、フェイルオーバー・メンバのジャーナリングのパフォーマンスを監視して最適化するのは重要です。特に、すべてのミラー・メンバで一般メモリ・ヒープのサイズを増やすことをお勧めします。パフォーマンスと復元可能性の両方を高めるために、プライマリおよび代替ジャーナル・ディレクトリは、それぞれ異なるストレージ・デバイスに配置し、データベースやライト・イメージ・ジャーナル (WIJ) が使用しているストレージ・デバイスとも異なるストレージ・デバイスに配置することをお勧めします。詳細は、"Caché データ整合性ガイド" の “ジャーナリング” の章の "ジャーナリングの最善の使用方法" と "ジャーナル・ファイルのリストア" を参照してください。
仮想化仮想化環境でのミラーリングの使用により、その両方の利点を併せ持つ高可用性ソリューションが提供される際には、重要な推奨事項が適用されます。詳細は、"仮想環境でのミラーリング" を参照してください。
タスクのスケジューリング — タスク・マネージャを使用してミラー・メンバのタスクを作成する場合、タスクを実行できるメンバを、プライマリのみ、プライマリ以外の任意のメンバ、もしくは任意のミラー・メンバのどれにするかを指定する必要があります。詳細は、"Caché システム管理ガイド" の “Caché の管理” の章にある "タスク・マネージャの使用" を参照してください。
開始 — プライマリ・フェイルオーバー・メンバでは、コードを既存の ^ZSTU または ^%ZSTART ルーチンから ^ZMIRROR ルーチンに移動して、ミラーの初期化まで実行しないようにすることもできます。詳細は、"^ZMIRROR ルーチンの使用法" を参照してください。

アービターのインストール

自動フェイルオーバーができる限り広範な停止シナリオに対処できるように、"自動フェイルオーバーのメカニズム" の説明に従って、各ミラーにアービターを構成することをお勧めします。"ミラーの可用性を最適化するためのアービターの配置" の説明にあるように、推奨されるアービターのネットワーク上の場所は、フェイルオーバー・メンバの位置によって異なります。1 つのシステムを複数のミラーに対応するアービターとして構成できます (そのシステムが、各ミラーにとって適切な場所にある場合)。

アービターとして動作するには、システムでバージョン 2015.1 以降の ISCAgent プロセスが稼働している必要があります。ISCAgent は Caché と共にインストールされるため、Caché バージョン 2015.1 以降のインスタンスを 1 つ以上ホストするシステムは、この要件を満たしていて、それ以上の準備を必要とせずにアービターとして構成できます。ただし、ミラーのフェイルオーバー・メンバまたは DR 非同期メンバを 1 つ以上ホストしているシステムは、そのミラーのアービターとして構成してはいけません。

バージョン 2015.1 以降の Caché インスタンスをホストしていないシステムは、この目的のためのキットを使用して ISCAgent をインストールすることで、アービターとしての役割を果たす準備が整います。システムが 2015.1 より前の Caché インスタンスをホストしている場合は、キットによって既存の ISCAgent がアップグレードされます。そのようなシステムの準備を整えるには、目的のアービター・システムに適した ISCAgent インストール・キットをインターシステムズからダウンロードして、以下に示すように ISCAgent をインストールまたはアップグレードします。

Windows システムの場合は、単にインストール・ファイル (例えば、ISCAgent-2015.2.0.540.0-win_x64.exe) を実行します。
UNIX®、Linux、および Mac OS X システムの場合は、単一ファイルのインストール・キットをアンパックして (必要な場合)、インストール・キットの最上位レベル /ISCAgent で cinstall を実行します。以下はその例です。
```
[root@arbiterhost home]# gunzip ISCAgent-2015.1.0.423.0-lnxrhx64.tar.gz
[root@arbiterhost home]# tar -xf ISCAgent-2015.1.0.423.0-lnxrhx64.tar
[root@arbiterhost home]# ./ISCAgent/cinstall
```

Note:

Caché がサポートされるすべてのプラットフォームに向けた ISCAgent インストール・キットがあります。サポート対象プラットフォームのリストは、このリリース用のオンライン・ドキュメント "インターシステムズでサポートされるプラットフォームOpens in a new tab" を参照してください。

システムの起動時に、アービター・システムで ISCAgent プロセスが起動するよう構成されていることを確認してください。詳細は、"ISCAgent の開始および停止" を参照してください。

ISCAgent の起動

ISCAgent プロセスがホスト・システムで実行されていない限り、Caché インスタンスをフェイルオーバーまたは DR 非同期メンバとしてミラーに追加することはできません。ISCAgent は、システムの起動時に自動的に起動するよう構成されている必要があります。詳細は、"ISCAgent の開始および停止" を参照してください。

SSL/TLS セキュリティを使用したミラー通信の保護

ミラー内でセキュリティを実現するために、相互での通信時に SSL/TLS を使用するようにミラーのメンバを構成できます。ミラーの作成時に SSL/TLS を使用する必要がある場合は、すべてのメンバ間のすべての通信に、すべてのメンバが SSL/TLS を使用する必要があります。

SSL/TLS セキュリティを使用したミラーの作成に関する詳細は、"ミラーの作成" を参照してください。既存のミラーへの SSL/TLS セキュリティの追加に関する詳細は、"フェイルオーバー・メンバの編集または削除" を参照してください。

SSL/TLS セキュリティを使用したミラーの作成についての唯一の包括的な演習ガイドは、インターシステムズのシニア・サポート・スペシャリストによって書かれた InterSystems Developer Community の "Creating SSL-Enabled Mirror Using Public Key Infrastructure (PKI)Opens in a new tab" を参照してください。

Important:

ミラーリングでは SSL/TLS を使用することを強くお勧めします。ミラーで SSL/TLS を無効にしないことを強くお勧めします。

ミラー・メンバのミラー接続のための SSL/TLS 使用には、ミラー・メンバ・インスタンスをホストするシステムでの適切な SSL/TLS 設定が要求されます。詳細は、"Caché セキュリティ管理ガイド" の “Caché での SSL/TLS の使用法” の章の "ミラー用 SSL/TLS 構成の作成および編集" を参照してください。

また、ミラーリングにおける暗号化ジャーナル・ファイルの使用には準備が必要です。ジャーナル暗号化の詳細は、この章の "ミラー内ジャーナル暗号の有効化" および "Caché セキュリティ管理ガイド" の “マネージド・キー暗号化” を参照してください。

^MIRROR ルーチンの使用法

ミラーリング構成、管理、およびステータスの操作のほとんどは管理ポータルで実行できます。また、%SYS ネームスペースで実行する ^MIRROR ルーチンでも実行できます。ただし、バックアップ・フェイルオーバー・メンバを強制的にプライマリ・フェイルオーバー・メンバにする操作 ("自動フェイルオーバーなしのプライマリ計画外停止" を参照) など、操作によっては、^MIRROR ルーチンでのみ実行可能なものもあります。この章に掲載する手順では、使用可能である場合の管理ポータルの操作を説明しますが、同等の操作を備える ^MIRROR オプションについても常に注記します。

ミラーの作成

ミラーの作成にあたっては、プライマリ・フェイルオーバー・メンバ、通常は (必須ではない) バックアップ・フェイルオーバー・メンバ、および (オプションで) 1 つ以上の非同期メンバを構成します。ミラーを作成した後、データベースをミラーに追加できます。

Important:

Caché インスタンスをフェイルオーバー・メンバまたは非同期メンバとしてミラーに追加する前に、この章の "ISCAgent の開始および停止" の説明に従って、ISCAgent プロセスが開始されていることを確認する必要があります。

バックアップ・メンバおよび非同期メンバを追加する手順では、推奨されているように SSL/TLS を使用するようミラーを構成する場合に、追加の手順が必要です ("SSL/TLS セキュリティを使用したミラー通信の保護" を参照)。この場合、新しいメンバをミラーに参加させる前に、プライマリでそれぞれのメンバを承認する必要があります。

ミラーを作成および構成するには、以下の手順を使用します。

ミラーを作成して、フェイルオーバー・メンバおよび任意で 1 つ以上の非同期メンバを構成してから、この章の "ミラーへのデータベースの追加" の手順を使用して、データベースをミラーに追加します。

ミラーを作成し、第 1 のフェイルオーバー・メンバを構成する

次の手順では、ミラーを作成し、第 1 のフェイルオーバー・メンバを構成する方法について説明します。

第 1 のフェイルオーバー・メンバの管理ポータルのシステム, 構成, ミラーの作成ページに移動し、[ミラーの作成] をクリックします。このオプションがアクティブでない場合、ミラーリングが有効になっていません。[ミラーサービスを有効にする] をクリックし、[サービス有効] チェック・ボックスにチェックを付けて、[保存] をクリックしてから、[ミラーの作成] オプションを選択します。
システム, 構成, ミラーの作成ページで、[ミラー情報] セクションに次の情報を入力します。
1. [ミラー名] — ミラーの名前を入力します。
  
  Note:
  
  有効な名前は、1 ～ 15 文字の英数字とする必要があります。小文字は自動的に大文字に置き換えられます。
2. [SSL/TLS を要求] — このチェック・ボックスにチェックを付ける、または外すことにより、ミラー内のすべての通信に対して (推奨どおりに) SSL/TLS セキュリティを必要とするかどうかを指定します。[SSL/TLS を要求] を選択するときに、インスタンスでミラーリングに対する有効な SSL/TLS 構成を済ませていない場合は、手順を完了する前に、[SSL/TLS の設定] リンクをクリックして、このメンバに対して必要な SSL/TLS 構成を作成する必要があります。(SSL/TLS 構成の作成方法の詳細は、"Caché セキュリティ管理ガイド" の “Caché での SSL/TLS の使用法” の章にある "ミラー用 SSL/TLS 構成の作成および編集" を参照してください。[ミラーの作成] の手順は、キャンセルすることも可能で、ポータル・ホーム・ページから [SSL/TLS 構成] ページに移動することもできます (システム管理, セキュリティ, SSL/TLS 構成))。ミラーリングに対する有効な SSL/TLS 構成が行われいるインスタンスの場合、そのリンクは [SSL/TLS の編集] になりますが、[SSL/TLS を要求] を選択している場合は、そのリンクを使用する必要はありません (その構成を変更する場合を除く)。
3. [アービターを使用] — "自動フェイルオーバーのメカニズム" で説明したように、できる限り広範な停止シナリオに対して自動フェイルオーバーを有効にするために (推奨どおりに) アービターを構成するかどうかを指定します。[アービターを使用] を選択した場合、アービターとして構成するシステムのホスト名または IP アドレス、およびその ISCAgent プロセスで使用するポート (既定では 2188) を指定する必要があります。アービターに関する詳細は、"ミラーの可用性を最適化するためのアービターの配置" および "アービターのインストール" を参照してください。
4. [仮想 IP を使用] — チェック・ボックスにチェックを付ける、または外すことにより、仮想 IP アドレスを使用するかどうかを指定します。[仮想 IP を使用] を選択した場合、IP アドレス、クラスレスのドメイン間ルーティング (CIDR) マスク、およびネットワーク・インタフェースの入力を求められます。
  
  Important:
  
  VIP 構成前の要求事項や重要考慮事項の詳細は、"ミラー仮想 IP (VIP) の構成" を参照してください。
5. [フェイルオーバー・メンバの圧縮モデル]、[非同期メンバの圧縮モデル] — プライマリからバックアップ・メンバおよび非同期メンバにジャーナル・データを転送する前に、データを圧縮するかどうかをそれぞれ指定します。詳細は、"ジャーナル・データの圧縮" を参照してください。既定の設定は、どちらも [システム選択] です。この設定では、フェイルオーバー・メンバ間の応答時間と、プライマリと非同期との間のネットワーク使用率が最適化されます。
6. [並列デジャーナリングを許可する] — 並列デジャーナリングを有効にする対象をフェイルオーバー・メンバおよび DR 非同期にする (既定) か、レポート非同期を含むすべてのメンバにするか、またはフェイルオーバー・メンバのみにするかを指定します。並列デジャーナリングではミラーのスループットが向上しますが、複数のデータベースが関与するクエリまたはレポートの結果の一貫性が損なわれる可能性が若干高まる場合があります。詳細は、"並列デジャーナリングの構成" を参照してください。
[ミラー・フェイルオーバー情報] セクションに次の情報を入力します。
- [ミラー・メンバ名] — このシステムで構成しているフェイルオーバー・メンバの名前 (既定値は、システムのホスト名と Caché インスタンス名の組み合わせです)。ミラー・メンバー名には、以下の後に続くスペース、タブ、および句読点文字を含めることはできません。
  : [ ] # ; / * = ^ ~ ,
  保存する前にアルファベット文字は大文字に変換されます。ミラー・メンバの名前の最大長は 32 文字です。
- [エージェント・ポート] — このフェイルオーバー・メンバの ISCAgent のポート番号。既定値は 2188 です。エージェント・ポートに関する詳細は、"ISCAgent の管理" を参照してください。
[詳細設定] をクリックして、以下のように追加のミラー設定を表示および編集します。
- サービス品質のタイムアウト (msec) — フェイルオーバー・メンバが、アクションを実行する前に、他のフェイルオーバー・メンバからの応答を待機する最大時間 (ミリ秒単位)。さらに、フェイルオーバー・メンバの応答をアービターが待機する場合にも適用されます。サービス品質 (QoS) タイムアウトに関する詳細は、"サービス品質 (QoS) タイムアウトの構成" を参照してください。
- [ミラー・プライベート・アドレス] — このフェイルオーバー・メンバとの通信に別のフェイルオーバー・メンバが使用できる IP アドレスまたはホスト名を入力します。"ミラー・メンバのネットワーク・アドレス" と "ミラー・メンバのネットワーク・アドレスの更新" を参照してください。
- [エージェント・アドレス] — このメンバの ISCagent に別のミラー・メンバが最初に通信しようとするアドレスを入力します。"ミラー・メンバのネットワーク・アドレス" と "ミラー・メンバのネットワーク・アドレスの更新" を参照してください。
[保存] をクリックします。

Note:

ミラーの作成には、^MIRROR ルーチンも使用できます ("^MIRROR ルーチンの使用法" を参照)。既存のミラー構成なしで、Caché インスタンスの ^MIRROR を実行する際に、ミラーリングがまだ有効になっていない場合は、[ミラーサービスを有効にする] オプションを使用できます。ミラーが有効になると、[ミラーの作成] オプションを使用でき、ミラー作成およびプライマリ・フェイルオーバー・メンバとしてのインスタンス構成の代替手段になります。また、SYS.Mirror.CreateNewMirrorSet()Opens in a new tab ミラーリング API メソッドもこの目的に使用できます。

第 2 のフェイルオーバー・メンバを構成する

次の手順に従って、ミラーに第 2 のフェイルオーバー・メンバを構成します。

第 2 のフェイルオーバー・メンバで、管理ポータルのシステム, 構成, フェイルオーバーとして参加に移動します。[フェイルオーバーとして参加] オプションが使用できない場合、最初に [ミラーサービスを有効にする] をクリックし、[サービス有効] チェック・ボックスにチェックを付けて、[保存] をクリックしてから、[フェイルオーバーとして参加] オプションを選択します。
[フェイルオーバーとしてミラーに参加] ページで、[ミラー情報] セクションに、第 1 のフェイルオーバー・メンバを構成したときに指定したミラー名を入力します。
[他方のミラー・フェイルオーバー・メンバの情報] セクションに次の情報を入力します。
- [その他のシステムのエージェント・アドレス] — 第 1 のフェイルオーバー・メンバを構成したときに指定した [スーパーサーバ・アドレス] を入力します。
- [エージェント・ポート] — 第 1 のフェイルオーバー・メンバを構成したときに指定した ISCAgent のポートを入力します。
- [Cach インスタンス名] — 第 1 のフェイルオーバー・メンバとして構成されている Caché インスタンスの名前を入力します。
[次へ] をクリックして、ミラーおよび第 1 のフェイルオーバー・メンバに関する情報を取得および表示します。[ミラー・フェイルオーバー・メンバ情報] セクションには、次の情報が入力されています。
- [ミラー・メンバ名] — このシステムで構成しているフェイルオーバー・メンバの名前を指定します (既定値は、システムのホスト名と Caché インスタンス名の組み合わせです)。ミラー・メンバー名には、以下の後に続くスペース、タブ、および句読点文字を含めることはできません。
  : [ ] # ; / * = ^ ~ ,
  保存する前にアルファベット文字は大文字に変換されます。ミラー・メンバの名前の最大長は 32 文字です。
- [スーパーサーバ・アドレス] — このフェイルオーバー・メンバとの通信に外部システムが使用できる IP アドレスまたはホスト名を入力します。詳細は、"ミラー・メンバのネットワーク・アドレス" と "ミラー・メンバのネットワーク・アドレスの更新" を参照してください。
- [エージェント・ポート] — このフェイルオーバー・メンバの ISCAgent のポート番号を入力します。既定値は 2188 です。エージェント・ポートに関する詳細は、"ISCAgent の管理" を参照してください。
- [仮想 IP 用ネットワーク・インタフェース] — 第 1 のフェイルオーバー・メンバを構成したときに指定したネットワーク・インタフェースが表示されます。この設定を第 2 のフェイルオーバー・メンバで変更することはできません。
- [SSL/TLS の要件] — 第 1 のフェイルオーバー・メンバを構成したときに指定した設定が表示されます。この設定を第 2 のフェイルオーバー・メンバで変更することはできません。
  ミラーが SSL/TLS を要求している場合に、インスタンスでミラーリングに対する有効な SSL/TLS 構成を済ませていないときには、手順を完了する前に、[SSL/TLS の設定] リンクをクリックして、このメンバに対して必要な SSL/TLS 構成を作成する必要があります。(SSL/TLS 構成の作成方法の詳細は、"Caché セキュリティ管理ガイド" の “Caché での SSL/TLS の使用法” の章にある "ミラー用 SSL/TLS 構成の作成および編集" を参照してください。[フェイルオーバーとして参加] の手順は、キャンセルすることも可能で、ポータル・ホーム・ページからシステム管理, セキュリティ, SSL/TLS 構成に移動できます)。
  ミラーリングに対する有効な SSL/TLS 構成が行われているインスタンスの場合、そのリンクは [SSL/TLS の編集] になりますが、SSL/TLS が要求される場合は、そのリンクを使用する必要はありません (その構成を変更する場合を除く)。
- [ミラー・プライベート・アドレス] — このフェイルオーバー・メンバとの通信に別のフェイルオーバー・メンバが使用できる IP アドレスまたはホスト名を入力します。"ミラー・メンバのネットワーク・アドレス" と "ミラー・メンバのネットワーク・アドレスの更新" を参照してください。
- [エージェント・アドレス] — このメンバの ISCagent に別のミラー・メンバが最初に通信しようとするアドレスを入力します。"ミラー・メンバのネットワーク・アドレス" と "ミラー・メンバのネットワーク・アドレスの更新" を参照してください。
[詳細設定] をクリックすると、第 1 のフェイルオーバー・メンバを構成したときに指定した [サービス品質タイムアウト (ミリ秒)] の設定が表示されます。この設定を第 2 のフェイルオーバー・メンバで変更することはできません。
[保存] をクリックします。

SSL/TLS を使用するようにミラーを構成した場合は、以下のセクションで説明するように、第 1 のフェイルオーバー・メンバで第 2 のフェイルオーバー・メンバを承認することで、第 2 のフェイルオーバー・メンバをミラーに追加するプロセスを完了する必要があります。

Note:

第 2 のフェイルオーバー・メンバの構成には、^MIRROR ルーチンも使用できます ("^MIRROR ルーチンの使用法" を参照)。既存のミラー構成なしで、Caché インスタンスの ^MIRROR を実行する際に、ミラーリングがまだ有効になっていない場合は、[ミラーサービスを有効にする] オプションを使用できます。ミラーリングが有効になると、[フェイルオーバー・メンバとしてミラーに参加] オプションを使用でき、バックアップ・フェイルオーバー・メンバの構成とミラーへの追加の両方についての代替手段になります。また、SYS.Mirror.JoinMirrorAsFailoverMember()Opens in a new tab ミラーリング API メソッドもこの目的に使用できます。

第 2 のフェイルオーバー・メンバまたは非同期メンバを承認する (SSL/TLS ミラーのみ)

SSL/TLS を使用するようにミラーを構成した場合は、第 2 のフェイルオーバー・メンバの構成後または非同期メンバの構成後に、追加の手順が必要になります。ミラーを作成してから第 1 のフェイルオーバー・メンバを構成したシステムでは、次の手順に従って、新しいミラー・メンバを承認する必要があります。

管理ポータルのシステム, 構成, ミラーの編集ページに移動します。
ページの下部にある、[保留中の新しいメンバ] 領域には、ミラーに追加されているメンバがリスト表示されます。承認するメンバを選択し、[承認] をクリックして確定します。(第 2 のフェイルオーバー・メンバを追加する際に、そのメンバの SSL 証明書が自動的に検証されます)。
[ミラーの編集] ページの [ミラーメンバ情報] セクションに示される情報には、追加したメンバが含まれています。(このリストに表示されるアドレスの詳細は、"ミラー・メンバのネットワーク・アドレス" を参照してください。)

ただし、バージョン 2015.2 よりも前の Caché の非同期を追加した場合は、プライマリの [ミラーの編集] ページにある [新規非同期メンバの追加] ボタンを使用する必要があります。詳細は、"フェイルオーバー・メンバの編集または削除" を参照してください。また、^MIRROR ルーチンの [ミラー構成] メニューにある [保留リストにない非同期メンバの追加] オプションを使用して、2015.2 より前のバージョンの Caché の非同期メンバを認証することもできます (一方のフェイルオーバー・メンバが Caché 2015.2 以降の場合は、もう一方も同じにする必要があります。フェイルオーバー・メンバは、同じバージョンであることが必要です)。

Note:

また、第 1 のフェイルオーバー・メンバの ^MIRROR ルーチンの [ミラー構成] メニューにある [保留中の新しいメンバの承認/拒否] オプションも、SSL/TLS を要求するように構成したミラーで、新しいフェイルオーバー・メンバまたは非同期メンバを承認するために使用できます。

SYS.Mirror.AddFailoverMember()Opens in a new tab ミラーリング API メソッドは、SSL/TLS を要求するように構成したミラーで、第 2 のフェイルオーバー・メンバを承認するために使用できます。また、Config.MapMirrors.Create() API メソッドは、承認されるメンバ (フェイルオーバーまたはバックアップ) を作成するために使用できます。

SSL/TLS を要求するミラーのメンバに対する X.509 DN 更新を承認する (メンバの証明書が置き換えられた場合など) 方法の詳細は、"X.509 DN 更新の承認 (SSL/TLS のみ)" を参照してください。

フェイルオーバー・メンバのステータスをミラー・モニタで確認する

"ミラーの監視" で説明しているように、ミラー内のフェイルオーバー・メンバに関する情報を、ミラーにおけるその現行ステータス (ロール) を含め、ミラー・モニタを使用して確認できます。以下の手順に従い、ミラー・モニタを使用して、ミラーおよびそのフェイルオーバー・メンバが本来の意図どおりに設定されていることを確認します。

構成した第 1 のフェイルオーバー・メンバで、システム, ミラー・モニタページに移動し、ミラー・モニタを表示します。
[ミラー・フェイルオーバー・メンバ情報] 領域に、2 つのフェイルオーバー・メンバのミラー・メンバ名およびネットワーク・アドレスがリストされます。
[ミラー・メンバ・ステータス] 領域の [ステータス] 列に、構成した第 1 のフェイルオーバー・メンバが [プライマリ] として表示され、第 2 のフェイルオーバー・メンバが [バックアップ] として表示されます。"ミラー・メンバのジャーナル転送およびデジャーナリングのステータス" で説明しているように、バックアップの [ジャーナル転送] ステータスが [アクティブ] で、[デジャーナリング] ステータスが [キャッチアップ済み] になっているはずです。
アービターが構成されている場合、[アービター接続ステータス] 領域に、アービターのネットワーク・アドレスとエージェント・ポート番号が表示されます。[フェイルオーバー・モード] が [アービター制御] で、[接続ステータス] が [両方のフェイルオーバー・メンバがアービターに接続されている] になっているはずです。そのようになっていない場合、アービターが正しくインストールされていないか、アービターの ISCAgent プロセスが実行されていないか、または入力したネットワーク・アドレスかポート番号が正しくない可能性があります。ネットワーク上の問題により、一方または両方のフェイルオーバー・メンバがアービターと通信できなくなっている場合も、[フェイルオーバー・モード] が [エージェント制御] になる可能性があります。

バックアップ・フェイルオーバー・メンバのミラー・モニタにも同じ情報が表示されます。

非同期ミラー・メンバを構成する

構成する各非同期メンバに対して、以下の手順を使用します。フェイルオーバーのペアを使用するミラーには、レポート非同期メンバまたは災害復旧 (DR) 非同期メンバを最大 14 含めることができます。単一の Caché インスタンスは、最大で 10 個のミラーのレポート非同期メンバになれます。ただし、インスタンスは 1 つのミラーでのみ、DR 非同期になれます。読み取り専用または読み書き可能いずれかのレポート非同期としてインスタンスを構成すれば、そのいずれかのタイプのレポート非同期メンバとしてのみ、他のミラーに追加することができます (ただし、"非同期メンバのミラー構成の編集" の説明のとおり、レポート非同期メンバのタイプをそのメンバの属するすべてのミラーに対して変更することはできます)。

Note:

レポート非同期メンバとしてインスタンスをミラーに追加する手順は、ここで説明する [非同期として参加] オプションを使用する場合も、"非同期メンバのミラー構成の編集" で説明する [非同期構成の編集] ページの [ミラーに参加] ボタンを使用する場合も同じです。ただし、DR 非同期が所属できるのは 1 つのミラーにのみであるため、[非同期構成の編集] ページの [ミラーに参加] ボタンは、レポート非同期メンバにのみ使用できます。

管理ポータルのシステム, 構成, 非同期として参加に移動します。[非同期として参加] オプションが使用できない場合は、[ミラーサービスを有効にする] を選択して、サービスを有効化します。
[非同期としてミラーに参加] ページにて、[ミラー名] プロンプトで、ミラーの作成時に指定したミラー名を入力します。
プライマリまたはバックアップ・フェイルオーバー・メンバを選択し、[ミラー・フェイルオーバー・メンバの情報] セクションで、以下のプロンプトそれぞれに、選択したメンバの情報を入力します。
1. [フェイルオーバー・システムのエージェント・アドレス] — 選択したフェイルオーバー・メンバを構成したときに指定した [スーパーサーバ・アドレス] を入力します。
2. [エージェント・ポート] — 選択したフェイルオーバー・メンバに指定した ISCAgent のポートを入力します。
3. [Cach インスタンス名] — 選択したフェイルオーバー・メンバとして構成されている Caché インスタンスの名前を入力します。
[次へ] をクリックして、フェイルオーバー・メンバの情報を確認した後、[非同期メンバ情報] セクションに移動します。このセクションで、次の情報を入力します。
1. [非同期メンバ名] — 対象のシステムで構成している非同期メンバの名前を指定します (既定値は、システムのホスト名と Caché インスタンス名の組み合わせです)。ミラー・メンバの名前には、英数文字、下線文字、およびハイフンが使用できます。
  
  Note:
  
  ミラー・メンバ名を変更することはできないので、この名前はレポート非同期メンバが将来、他のミラーに参加する際にも使用されることになります。
2. [非同期メンバ・アドレス] — この非同期メンバと通信するために外部システムが使用できる IP アドレスまたはホスト名を入力します。
  
  Note:
  
  入力した [非同期メンバ・アドレス] は、非同期メンバのスーパーサーバ・アドレスおよびミラー・プライベート・アドレスになります ("ミラー・メンバのネットワーク・アドレス" を参照)。例えば、DR 非同期のミラー・プライベート・アドレスをミラー・プライベート・ネットワークに配置し、そのスーパーサーバ・アドレスを外部ネットワークに置いたままにするなど、これらのアドレスを異なったものにするには、ミラーに追加後、非同期のアドレスをプライマリで更新できます。詳細は、"ミラー・メンバのネットワーク・アドレスの更新" を参照してください。
3. [エージェント・アドレス] — このメンバの ISCagent に別のミラー・メンバが最初に通信しようとするアドレスを入力します。"ミラー・メンバのネットワーク・アドレス" と "ミラー・メンバのネットワーク・アドレスの更新" を参照してください。
4. [非同期メンバのシステム・タイプ] — ドロップダウン・リストから以下のタイプのいずれかを選択します。単一の Caché インスタンスは、複数のミラーのレポート非同期メンバになれます。ただしインスタンスは 1 つのミラーでのみ、DR 非同期になれます。
  - [災害復旧 (DR)] — 単一ミラー内のミラーリングされるデータベースすべてを読み取り専用コピーとして維持するシステムに対するオプションです。これにより、いずれかのフェイルオーバー・メンバの障害時に、DR 非同期メンバがフェイルオーバー・メンバに昇格することができます。DR 非同期の昇格に関する詳細は、この章の "DR 非同期メンバのフェイルオーバー・メンバへの昇格" を参照してください。
    
    Important:
    
    VIP を使用するようにミラーが構成されている場合、災害復旧の非同期メンバには、フェイルオーバー・メンバへの TCP/IP 直接接続性を備える必要となります。詳細は、"ミラー仮想 IP (VIP) の構成" を参照してください。
  - [読み取り専用のレポート] — このオプションを使用して、1 つ以上のミラーからのミラーリングされるデータベースの読み取り専用コピー (すなわちミラーリングされるデータベースのサブセット) を維持し、データの変更/追加の必要性のないデータ・マイニングおよび企業レポートを利用します。
  - [読み書き可能のレポート] — このオプションを使用して、1 つ以上のミラーからのミラーリングされるデータベースの読み書き可能コピー (すなわちミラーリングされるデータベースのサブセット) を維持します。それらのデータベースは、解析中にデータの変更や追加が可能であることが必要なレポート/ビジネス・インテリジェンス業務のデータ・ソースとして利用されます。
5. [SSL/TLS の設定] — ミラーが SSL/TLS を要求するときに、インスタンスでミラーリングに対する有効な SSL/TLS 構成を済ませていない場合は、エラー・メッセージと、このリンクが含まれるようになります。手順を完了する前に、このリンクをクリックして、このメンバに対して必要な SSL/TLS 構成を作成する必要があります。(SSL/TLS 構成の作成方法の詳細は、"Caché セキュリティ管理ガイド" の “Caché での SSL/TLS の使用法” の章にある "ミラー用 SSL/TLS 構成の作成および編集" を参照してください。[非同期として参加] の手順は、キャンセルすることも可能で、ポータル・ホーム・ページからシステム管理, セキュリティ, SSL/TLS 構成に移動できます)。
6. [SSL/TLS の編集] — ミラーリングに対する有効な SSL/TLS 構成が行われているインスタンスの場合、このリンクが [SSL/TLS の設定] の代わりに表示されます。必要な場合は、このリンクを使用して、既存の SSL/TLS 構成を編集できます。インスタンスの X.509 識別名も表示されます。
[保存] をクリックします。

SSL/TLS を使用するようにミラーを構成した場合は、"第 2 のフェイルオーバー・メンバまたは非同期メンバを承認する (SSL/TLS のみ)" で説明するように、第 1 のフェイルオーバー・メンバで非同期メンバを承認することで、非同期メンバをミラーに追加するプロセスを完了する必要があります。

Note:

非同期ミラー・メンバの構成には、^MIRROR ルーチンも使用できます ("^MIRROR ルーチンの使用法" を参照)。ミラーリングが有効化された Caché インスタンスで ^MIRROR ルーチンを実行すると、[ミラー構成] メニューの [非同期メンバとしてミラーに参加] (または [非同期メンバとして他のミラーに参加]) オプションが選択でき、非同期メンバを構成してミラーに追加するための代替手段になります。また、SYS.Mirror.JoinMirrorAsAsyncMember()Opens in a new tab ミラーリング API メソッドを使用して、非同期メンバを構成することもできます。

このセクションで説明する手順を使用して、インスタンスを非同期メンバとして 1 つのミラーに追加した後に、[非同期の編集] ページ ("非同期メンバのミラー構成の編集" を参照) の [ミラーに参加] ボタンを使用してインスタンスを他のミラーも追加できますが、同じタイプの非同期に限られます。

ミラーへのデータベースの追加

ミラーに追加できるのは、現在のプライマリ・フェイルオーバー・メンバのローカル・データベースのみです。最初はプライマリ上、その次にバックアップ上、さらにその次に任意の非同期メンバ上で追加します。すべてのミラーリングされるデータベースはジャーナリングされる必要があります。

ミラーリングされるデータベースの同一セットをプライマリおよびバックアップ・フェイルオーバー・メンバの両方、ならびにあらゆる DR 非同期メンバに追加する必要があります。いずれのミラーリングされるデータベースをレポート非同期メンバに追加するかは、レポートのニーズによって異なります。ミラーリングされるデータベースに関連付けられるネームスペースやグローバル/ルーチン/パッケージのマッピングは、すべてのミラー・メンバで同じである必要があります。メンバにはそのデータベースが存在するすべての非同期メンバも含まれます。バックアップ・フェイルオーバー・メンバのミラーリングされるデータベースをマウントおよびキャッチアップして ("ミラーリングされるデータベースの有効化とキャッチアップ" を参照)、フェイルオーバー時にプライマリを引き継げるようにする必要があります。DR 非同期メンバのミラーリングされるデータベースをマウントおよびキャッチアップして、フェイルオーバー・メンバへの昇格に適するようにする必要があります。

ミラーリングされるデータベースの作成手順 (つまり、データが含まれない新規データベースの追加) は、ミラーへの既存データベース追加の手順とは異なります。ミラーリングされるデータベースとして作成されたデータベースでのグローバル操作は、始めからミラー・ジャーナル・ファイルに記録されるので、ミラーはミラー・メンバ全体のデータベースと同期する必要があるデータすべてに対するアクセス権を備えています。しかし、ミラーへ追加される前の既存データベースのグローバル操作は非ミラー・ジャーナル・ファイルに含まれるので、ミラーにはアクセス権がありません。この理由から、既存のデータベースは、ミラーに追加した後にプライマリ・フェイルオーバー・メンバにバックアップし、データベースを置くことになるバックアップ・フェイルオーバー・メンバおよび非同期メンバにリストアする必要があります。これを実行した後には、データベースをアクティブにしてキャッチアップし、プライマリと同じ最新状態にする必要があります。

ミラーリングされたデータベースの考慮事項

ミラーリング・データベースを作成および追加する際は、以下の点に注意してください。

ミラーリングできるのは、CACHE.DAT ファイル内のデータのみです。外部データ (すなわち、ファイル・システムに保存されているデータ) は、Caché ではミラーリングできません。
システム・データベース (CACHESYS、CACHELIB、CACHE、CACHETEMP、CACHEAUDIT、および Ensemble がインストールされている場合には ENSLIB) はミラーリングできません。
ミラーリングされたデータベースにはさらに多くのデータベース・ディレクトリ情報が格納されるので、Caché インスタンス内に構成可能なデータベースの最大数は減ります。詳細は、"Caché システム管理ガイド" の “Caché の構成” の章にある "データベースの構成" を参照してください。
同じデータベースに対してミラーリングとシャドウイングの両方を構成する場合、次の 2 つの選択肢があります。
- ミラーにフェイルオーバー・メンバが 1 つしかない場合、フェイルオーバー・メンバをシャドウ・ソースとして構成できます。
- ミラーに 2 つのフェイルオーバー・メンバがある場合、レポート非同期メンバをシャドウ・ソースとして構成する必要があります。(DR 非同期は、昇格の対象で 2 番目のフェイルオーバー・メンバとなる可能性があるため、シャドウ・ソースとして構成できません。)
  レポート非同期ミラー・メンバ上のミラーリングされるデータベースとミラーリングされないデータベースの両方をシャドウイングするには、ミラーリングされるシャドウとミラーリングされないシャドウを個別に構成する必要があります。レポート非同期で複数の異なるミラーからデータベースをシャドウイングするには、各ミラーに個別シャドウを構成する必要があります。
シャドウイング構成の詳細は、"Caché データ整合性ガイド" の “シャドウイング” の章を参照してください。
ミラーは、バックアップまたは非同期のミラーされたデータベースの以下のプロパティを、プライマリのデータベースのプロパティと自動的にかつ継続的に同期します。
- 最大サイズ
- 拡張サイズ
- リソース名
- 照合
例えば、プライマリで、ミラーリングされたデータベースの [最大サイズ] が増やされた場合、必要に応じて、プライマリと一致するようにその他のメンバ上のミラーリングされたデータベースも自動的に増やされます。非同期で [最大サイズ] が減らされた場合、同期によってプライマリ上の値もその値まで自動的に増やされます。データベースのプロパティがプライマリまたは別のミラー・メンバで変更され、そのメンバが切断されている場合、そのメンバがミラーに再接続したときに自動的に同期されます。これらのデータベースのプロパティの自動同期には、次の 2 つの例外があります。
- 非同期の [最大サイズ] プロパティと [拡張サイズ] プロパティの値は、同期によって増加することがありますが、減少することはありません。例えば、プライマリ上のデータベースの [最大サイズ] が減らされた場合、バックアップのこのプロパティ値は減らされますが、ミラーに属している非同期のこのプロパティ値は減らされません。非同期のデータベースの [最大サイズ] がプライマリのものより増やされた場合、この値が同期によってプライマリの値にまで減らされることはありません。
- データベースの [リソース名] プロパティは、バックアップでプライマリと同期されますが、非同期メンバではプライマリと同期されません。
ミラーリングされるデータベースのプロパティの詳細は、"Caché システム管理ガイド" の “Caché の構成” の章にある "ミラーされているローカル・データベース・プロパティの編集" を参照してください。

ミラーリングされるデータベースを作成する

ミラーリングされるデータベースを作成するには、以下の手順に従います。

Note:

^DATABASE ルーチンを使用して、ミラーリングされるデータベースを作成することもできます。この章の "^DATABASE ルーチンを使用したミラーリングされるデータベースの作成" を参照してください。

現在のプライマリ・フェイルオーバー・メンバで、管理ポータルのシステム, 構成, システム構成, ローカルデータベースページに移動して、[新規データベース作成] ボタンをクリックします。
"Caché システム管理ガイド" の “Caché の構成” の章にある "ローカル・データベースの作成" の手順に従います。2 番目のパネルで、[ミラーリングされるデータベース] に対して [はい] を選択して、ミラー内のデータベースの名前を入力します。既定はユーザが提供したローカル・データベース名となります(ミラー・データベース名の先頭文字は、英字またはアンダースコアである必要があり、残りの部分は、英字、ハイフン、およびアンダースコアである必要があります)。ミラー・データベース名では大文字と小文字が区別されないため、2 つの名前を大文字と小文字の違いだけで区別することはできません。既にミラーに含まれているミラー・データベース名を入力した場合、新規データベースをミラーに追加できないので、削除する必要があります。(以前のバージョンの Caché で作成した、ミラーリングされるデータベースの名前は、小文字または大文字小文字が混ざった状態で保存されている可能性がありますが、重複する大文字の名前が付いたデータベースの追加は、これまでどおりに防止されます。)
複数のミラーに属している非同期メンバでは、そのデータベースが属することになるミラーも選択する必要があります。

Note:

[ミラーされたデータベース] に対して [はい] を選択した場合、[ジャーナルグローバル] は自動で [はい] に固定されます。
手順によってデータベースが作成されたことを確認し、そのデータベースをプライマリのミラーに追加します。
バックアップ・フェイルオーバー・メンバ、およびミラーリングされるデータベースを追加する各非同期メンバで、前述の 3 つのステップに従います。それぞれの他のメンバのミラーリングされるデータベース名として、プライマリの正しいミラー・データベース名を入力するよう注意してください (ローカル・データベース名と一致する必要はありません)。

Note:

プライマリ上のミラーリングされるデータベースとして作成されていないが作成後にミラーに追加した非プライマリ・メンバ上のミラーに新しいデータベースを追加しようとすると、これについて知らせるエラー・メッセージが表示され、操作は完了できません。

Important:

ミラーリングされたデータベースの最初のミラー・ジャーナル・ファイルがプライマリから削除されると、別のメンバでデータベースをミラーリングされたデータベースとして作成できなくなります。その代わり、"ミラーへ既存データベースを追加する" の説明のとおり、プライマリにバックアップを作成し、バックアップまたは非同期でリストアする必要があります。このため、プライマリでデータベースを作成した後は、できるだけすぐにバックアップと非同期メンバでデータベースを作成することをお勧めします。(プライマリでミラー・ジャーナル・ファイルが削除された場合の詳細は、"Caché データ整合性ガイド" の “ジャーナリング” の章にある "ジャーナル・ファイルの削除" を参照してください)。

ミラーへ既存データベースを追加する

以下の手順を使用して、1 つ以上の既存データベースをミラーに追加します。

Note:

バックアップ・フェイルオーバー・メンバまたは非同期メンバのエンディアンがプライマリ・フェイルオーバー・メンバのエンディアンと異なっている場合は、この手順を使用できません。代わりに、データベースの CACHE.DAT ファイルをコピーして、データベースのエンディアンを変更する手順を挿入した後で、この手順を使用する必要があります。詳細は、"メンバのエンディアンに関する考慮事項" を参照してください。

SYS.Mirror.AddDatabase()Opens in a new tab ミラーリング API メソッドは、既存のデータベースをミラーに追加するための代替手段を提供します。

現在のプライマリ・フェイルオーバー・メンバで、管理ポータルのシステム, 構成, システム構成, ローカルデータベースページに移動して、[ミラーに追加] ボタンをクリックします。
リストのデータベース (システム・データベース以外はまだミラーに存在しない) から、追加するものを選択して、[追加] をクリックします。ミラー内の各データベースの名前を入力する必要があります。既定はユーザが提供したローカル・データベース名となります (ミラー・データベース名の先頭文字は、英字またはアンダースコアである必要があり、残りの部分は、英字、ハイフン、およびアンダースコアである必要があります)。ミラー・データベース名では大文字と小文字が区別されないため、2 つの名前を大文字と小文字の違いだけで区別することはできません。既にミラーに含まれているミラー・データベース名を入力した場合、操作は失敗します。 (以前のバージョンの Caché で作成した、ミラーリングされるデータベースの名前は、小文字または大文字小文字が混ざった状態で保存されている可能性がありますが、重複する大文字の名前が付いたデータベースの追加は、これまでどおりに防止されます。)
タスクをバックグラウンドで実行するには、[バックグラウンドで追加を実行] を選択します。5 つ以上のデータベースを選択する場合、タスクはバックグラウンドで自動的に実行されます。手順により、プライマリ上で選択したデータベースがミラーに追加されたことを確認します。
また、個々のデータベースをミラーに追加するには、名前のクリックによりプロパティを編集してから、[ミラー <mirrorname> に追加] リンクをクリックし、その後、[追加] をクリックして、手順を確認することでも行えます(データベースでジャーナリングが有効になっていない場合、このリンクの代わりに [ミラーリングのためにデータベースをジャーナリングする必要があります] と表示されるので、[グローバルジャーナル状態] ドロップダウン・リストから [はい] を選択します)。また、^MIRROR ルーチンの [ミラー管理] メニューの [ミラーリングされるデータベースの追加] オプションでも、個々のデータベースを追加できます。どちらの場合も、ローカル名と同じ既定のミラー・データベース名をそのまま使用することも、別の名前を入力することもできます。

Note:

バックアップ・フェイルオーバー・メンバまたは非同期メンバにプライマリ・フェイルオーバー・メンバとは異なるエンディアンがある場合は、"メンバのエンディアンに関する考慮事項" での手順に従って、データベースをプライマリに追加してから、バックアップまたは非同期メンバに追加する必要があります。以下の手順では、データベースをバックアップまたは非同期メンバ上で追加します。
データベースがミラーに追加されたら、プライマリ・フェイルオーバー・メンバ上でバックアップを行います。各種バックアップ技術および関連するリストア手順の詳細は、"Caché データ整合性ガイド" の “バックアップとリストア” の章にある "バックアップの方法"、"バックアップからのリストア"、および "ミラーリングされたデータベースの考慮事項" を確認してください。

Important:

コピーしているデータベースをプライマリで暗号化する場合、暗号化に使用したキーをバックアップ (および非同期 (存在する場合)) で有効化するか、cvencrypt ユーティリティを使用して宛先システムで有効化されたキーを使用するようデータベースを変換する必要があります (これについては、"Caché セキュリティ管理ガイド" の “cvencrypt ユーティリティの使用” の章にある "新しいキーを使用するように暗号化データベースを変換する" セクションで説明しています)。
バックアップからのミラーリングされるデータベースのリストア後 (以下のステップを参照)、そのデータベースが確実に同期するには、プライマリ・フェイルオーバー・メンバ上でのバックアップ時点よりジャーナル・ファイルが使用可能かつオンラインである必要があります。例えば、関連ジャーナル・ファイルが削除されてしまった場合、より最新のバックアップを作成およびリストアする必要があります。ミラー・ジャーナル・ファイルのリストアについての一般事項は、"Caché データ整合性ガイド" の “ジャーナリング” の章にある "ミラー・ジャーナル・ファイルのリストア" を参照してください。ミラー・ジャーナル・ファイルの削除に関する詳細は、"Caché データ整合性ガイド" の “ジャーナリング” の章にある "ジャーナル・ファイルの削除" を参照してください。
バックアップ・フェイルオーバー・メンバおよび接続された各非同期メンバでは、以下の手順を実行します。
1. プライマリ・フェイルオーバー・メンバ上で追加したばかりのミラーリングされるデータベースと同じローカル名とデータベース・ディレクトリを持つローカル・データベースがまだ存在しない場合は、それを作成します。
2. プライマリ上のミラーリングされるデータベースで作成したバックアップをリストアして、既存のデータベースを上書きします。この手順は、以下のように使用しているリストア方法によって異なります。
  - Caché オンライン・バックアップ・リストア (^DBREST routine) — このルーチンは、バックアップおよび非同期メンバのミラーリングされるデータベースを自動的に認識、有効化、およびキャッチアップします。詳細は、"Caché データ整合性ガイド" の “バックアップとリストア” の章の "ミラーリングされたデータベースの考慮事項" を参照してください。
    
    Note:
    
    ミラーリングされるデータベースが非プライマリ・メンバ上でリストアされる場合、自動同期プロセスを開始するためのデータがまだ送信されていない場合があります。必要なデータが 60 秒以内に到着しない場合、プロセスはとりあえず開始されます。データが必要となる前に到着しない場合、それらのデータベースがキャッチアップしないことがあります。ただしその場合は、問題のあるデータベースに関するメッセージが cconsole.log ファイルにロギングされます (データベース作成中は、このプロセスに影響されるデータベースは 1 つのみとなります。ただし、これは複数のデータベースが関係するその他の状況のキャッチアップにも適用されます)。
  - 外部バックアップ・リストアまたはコールド (オフライン) バックアップ・リストア — これらのどちらの方法でも、ミラーリングされるデータベースを、バックアップ・フェイルオーバー・メンバまたは非同期メンバ上でリストアし、かつマウントした後に、手動で有効化し、キャッチアップする必要があります。これについては、直後の "ミラーリングされるデータベースの有効化とキャッチアップ" で説明しています。

前述の手順の代わりとして、既存のデータベースをプライマリ上のミラーに追加した後で、データベースのバックアップとリストアを実行するのではなく、データベースの CACHE.DAT ファイルをプライマリからバックアップ・メンバと非同期メンバにコピーすることもできます。この操作には、以下の手順を使用します。

バックアップ・メンバまたは各非同期メンバ上にプレースホルダのターゲット・データベースが存在することを確認します。
両方のフェイルオーバー・メンバと各非同期メンバで、ソース・データベースとターゲット・データベースがマウントされていないことを確認します ("Caché システム管理者ガイド" の “Caché の管理” の章にある "ローカル・データベースの管理" を参照)。
ミラーリングされる CACHE.DAT ファイルをプライマリ・フェイルオーバー・メンバから、バックアップおよび各非同期メンバ上のプレースホルダ・ターゲット・データベースのデータベース・ディレクトリにコピーして、既存 CACHE.DAT ファイルを上書きします。

Note:

コピーしているデータベースをプライマリで暗号化する場合、暗号化に使用したキーをバックアップ (および非同期 (存在する場合)) で有効化するか、cvencrypt ユーティリティを使用して宛先システムで有効化されたキーを使用するようデータベースを変換する必要があります (これについては、"Caché セキュリティ管理ガイド" の “cvencrypt ユーティリティの使用” の章にある "新しいキーを使用するように暗号化データベースを変換する" セクションで説明しています)。
すべてのメンバにデータベースをマウントします。
バックアップ・フェイルオーバー・メンバおよび非同期メンバ上のミラーリングされるデータベースを有効化してキャッチアップします。詳細は、この章の "ミラーリングされるデータベースの有効化とキャッチアップ" を参照してください。

Note:

既存のミラーリングされるデータベースを非同期メンバに追加するときに、完全にキャッチアップされているものと仮定すると、プライマリではなく、バックアップ・フェイルオーバー・メンバまたは別の非同期メンバ上でデータベースをバックアップする (または、それらのメンバから CACHE.DAT ファイルをコピーする) ことができます。バックアップをリストアする非同期とは異なるデータ・センタにプライマリがある場合など、これは便利な場合があります。ただし、データベースの整合性に高度な信頼性がない限り、メンバをソースとして使用しないでください。

ミラーリングされるデータベースの有効化とキャッチアップ

ミラー・モニタを使用して、バックアップ・フェイルオーバー・メンバおよび非同期メンバ上のミラーリングされるデータベースの有効化またはキャッチアップ、あるいはその両方を実行できます。

"ミラーへ既存データベースを追加する" でも記載していますが、データを含んでいてミラーリングされる新規追加データベースは、^DBREST ルーチンの使用を通してプライマリと自動的に同期して、プライマリ・フェイルオーバー・メンバからバックアップをリストアできます。その他の手段を使用する場合、バックアップ・フェイルオーバー・メンバおよび非同期メンバ上で有効化およびキャッチアップする必要があります。

ミラーリングされるデータベースを有効化およびキャッチアップするには、バックアップ・フェイルオーバー・メンバおよび非同期メンバで次の手順を実行します。

システム, ミラーモニタページに移動します。
必要に応じて、非同期メンバ上で、実行するデータベースを含むミラーの [詳細] リンクをクリックします。
"ミラー・モニタの使用法" で説明しているように、[ミラーリングされるデータベース] リストに、各データベースのステータスが表示されます。ここに表示される可能性のあるステータスの中で特に、[要キャッチアップ] はキャッチアップ処理が必要であることを示し、[要有効化] は有効化とキャッチアップの両方の処理が必要であることを示し、[キャッチアップ実行中] はデータベースで現在キャッチアップ処理が実行中であることを示します。
1 つのデータベースに対してのみ処理を実行する場合、[有効化] リンクまたは [キャッチアップ] リンクを選択します。または、アクションの対象として該当するすべてのデータベースのリストから複数のデータベースを選択できるダイアログを開いて、選択したすべてのデータベースに一度にアクションを適用する場合、[アクションを選択してください] ドロップダウンから [有効化] または [キャッチアップ] を選択して、[進む] をクリックします。これを実行する場合、[有効化] および [キャッチアップ] タスクはバックグラウンドで実行されます。[キャッチアップ] を選択すると、[要有効化] ステータスのデータベースと [要キャッチアップ] ステータスのデータベースが表示されます。[有効化] と [キャッチアップ] の両方が、選択したすべての [要有効化] データベースに適用されます。

[ミラーリングされるデータベース] リストを使用して、1 つ以上のミラーリングされたデータベースをマウントまたはディスマウントするか、またはミラーから 1 つ以上のデータベースを削除することもできます。これについては "ミラーリングされるデータベースをミラーから削除する" で説明します。

Note:

^MIRROR ルーチンの [ミラー管理] メニューの [ミラーリングされるデータベースの有効化/キャッチアップ] オプション、および SYS.Mirror.ActivateMirroredDatabase()Opens in a new tab と SYS.Mirror.CatchupDB()Opens in a new tab ミラーリング API メソッドは、ミラーリングされるデータベースを有効化/キャッチアップするための代替手段となります。

管理ポータルの [データベース] ページの [ミラーリングされるデータベース] リスト ("Caché システム管理ガイド" の “Caché の管理” の章を参照)、または ^DATABASE ルーチン ("Caché セキュリティ管理ガイド" の “文字ベースのセキュリティ管理ルーチンの使用” の章を参照) を使用して、ミラーリングされるデータベースをマウントする場合、以下のマウント操作に従ってデータベースをキャッチアップするかどうかを選択できます。

並列デジャーナリング ("並列デジャーナリングの構成" を参照) は、有効になっていて、使用可能なリソースによってサポートされている場合、ミラーリングされるデータベースをキャッチアップするときに使用されます。ただし、キャッチアップされるデータベースそれぞれに使用されるデジャーナリング・ジョブは 1 つのみで、合計で最大 4 つです。

ミラー・メンバの編集または削除

以下の手順は、ミラーをまとめて削除する処理も含め、ミラー・メンバでミラー構成を編集または削除する方法と、ミラー構成を削除しない場合にミラーからデータベースを削除する方法を示しています。

Note:

^MIRROR ルーチンの [ミラーの構成] メニューにあるいくつかのオプションでは、ミラー構成の編集のための代替手段を用意しています。使用可能な具体的オプションは、ルーチンがフェイルオーバー・メンバまたは非同期メンバのいずれにより使用されるかによって異なります。

レポート非同期ミラー・メンバの FailoverDB フラグのクリア

"非同期ミラー・メンバ" の説明にあるように、非同期メンバは、以下の 3 つのタイプのいずれかであることが必要です。

災害復旧 (DR) — プライマリ上のミラーリングされるデータベースのすべての読み取り専用コピーを維持します。フェイルオーバー・メンバに昇格する条件を満たしています (詳細は、"DR 非同期メンバのフェイルオーバー・メンバへの昇格" を参照)。
読み取り専用のレポート — ミラーリングされるデータベースの読み取り専用コピーを維持します。フェイルオーバー・メンバに昇格する条件を満たしていません。
読み書き可能のレポート — ミラーリングされるデータベースの読み書き可能のコピーを維持します。フェイルオーバー・メンバに昇格する条件を満たしていません。

ミラーリングされるデータベースが DR または読み取り専用のレポート非同期に追加されると、そのデータベースは読み取り専用としてマウントされ、プライマリでデータベースを作成したときに設定される [FailoverDB] フラグは、以下の目的で非同期のコピーに設定されたままになります。

データベースが読み取り専用の状態を維持するようにして、プライマリ上のデータベースの正確なコピーであることを保証します (デジャーナリングがキャッチアップされることが前提)。
DR 非同期メンバがフェイルオーバー・メンバに昇格したときに、データベースがミラー内でプライマリ・コピーになれることを示します。DR 非同期メンバは、ミラー内のすべてのデータベースを含んでいて、そのすべてのデータベースに [FailoverDB] フラグが設定されている場合にのみ昇格できます。

その一方で、ミラーリングされるデータベースが、読み書き可能のレポート非同期に追加されるときには、データベースを読み書き可能でマウントできるように、[FailoverDB] フラグがクリアされます。ミラーリングされるデータベースは、[FailoverDB] フラグがクリアされていると、ミラーのプライマリ・コピーとして使用できなくなります。

DR 非同期の場合、[FailoverDB] フラグはクリアできません。ただし、レポート非同期では、このフラグを手動でクリアできます。

読み取り専用のレポート非同期の場合、[FailoverDB] フラグをクリアすると、データベースは読み書き可能に変更されますが、一般に、これは推奨されません。そのため、非同期のタイプを [災害復旧 (DR)] から [読み取り専用のレポート] に変更する場合を含めて ("非同期メンバの編集または削除" を参照)、ほとんどの場合、読み取り専用レポート非同期のすべてのデータベースでは、[FailoverDB] フラグを設定したままにできます。

非同期メンバのタイプを [災害復旧 (DR)] または [読み取り専用のレポート] から [読み書き可能のレポート] に変更する場合は、すべての [FailoverDB] フラグをクリアするオプションが使用可能です。ミラーリングされるデータベースの [FailoverDB] フラグは読み取り専用を維持する必要があるため、一般に、このオプションを使用することになります。ただし、読み書き可能のレポート非同期で、1 つ以上のミラーリングされるデータベースを読み取り専用のままにする必要がある場合は、[ミラーリングされるデータベース] リストにある個別の [フラグのクリア] リンクを使用して、一部のデータベースを読み書き可能にし、それ以外のものを読み取り専用のままにすることができます。

タイプを変更した後の非同期メンバに追加したデータベースは、前述したように、メンバの新しいタイプに従ってマウントされ、フラグが設定されます。[FailoverDB フラグのクリア] ボタンを使用すると、どちらのタイプのレポート非同期でも、すべてのデータベースから、いつでもフラグをクリアできます。

[FailoverDB] フラグを手動で設定することはできません。このフラグは、ミラーリングされるデータベースが DR または読み取り専用のレポート非同期に追加されるときにのみ設定されます。

ミラー・メンバ削除時のミラーされるデータベースの属性の削除

メンバをミラーから削除するときには、そのミラーに属するミラーリングされるデータベースからミラー属性を削除するためのオプションが常に提供されます。その結果は、以下のとおりです。

ミラー属性を保持しておいて、後で Caché インスタンスをそのミラーにリストアする場合、データベースはミラーに自動的に追加されますが、キャッチアップして同期するにはそれらのデータベースを有効化する必要があります ("ミラーリングされるデータベースの有効化とキャッチアップ" を参照)。
ただし、ミラー属性を維持すると、以下のいずれかを先に実行しない限り、そのデータベースは削除できなくなります。
- メンバを削除した同じミラーにメンバを復元する (メンバがプライマリ・フェイルオーバー・メンバであった場合、ミラーは存在しなくなっているため、この方法は選択できません)。そうすると、1 つ以上のデータベースをミラーから削除できるようになり ("ミラーリングされるデータベースのミラーからの削除" を参照)、必要な場合は消去します。
- ^MIRROR ルーチンの [1 つ以上のミラーリングされるデータベースの削除] オプションを使用して ("^MIRROR ルーチンの使用法" を参照)、1 つ以上のデータベースからミラー属性を削除し、必要に応じてデータベースを削除する。
ミラー属性を削除すると、そのデータベースは永久にミラーリングされなくなり、ローカル・データベースのように使用できるようになります。インスタンスがミラー・メンバとして再び参加した後にミラーに戻す場合、最初にデータベースを既存データベースとしてミラーに追加するための手順を使用する必要があります。

バックアップまたは非同期メンバのミラーから個別のデータベースを削除すると、ミラーリングされるデータベースの属性は、自動的に削除されます。

非同期メンバの編集または削除

管理ポータルのシステム, 構成, 非同期の編集ページに移動します。
[ミラー構成を削除する] ボタンを使用して、DR 非同期をミラーから削除するか、レポート非同期をすべての所属先ミラーから削除して、インスタンスのミラー構成全体を削除します。(単一ミラーからレポート非同期を削除するには、この手順の後半で述べる [ミラーから脱退] リンクを使用します)。
メンバ上のミラーリングされるデータベースからミラー属性を削除するためのオプションが選択できます。この選択の判断に関する詳細は、"ミラー・メンバ削除時のミラーリングされるデータベースの属性の削除" を参照してください。
また、インスタンスの SSL/TLS 構成を削除するというオプションを選択することもできます ("SSL/TLS セキュリティを使用したミラー通信の保護" を参照)。
[ミラー構成を削除する] ボタンを使用して、インスタンスのミラー構成全体を削除した後は、Caché を再起動する必要があります。

Note:

^MIRROR ルーチンの [ミラー構成] メニューにある [ミラー構成を削除する] オプションでは ("^MIRROR ルーチンの使用法" を参照)、非同期メンバのミラー構成全体を削除するための代替手段が提供されています。
[ミラーに参加] ボタンを使用して、レポート非同期メンバを他のミラーに追加します (最大で 10 個まで所属できます)。非同期メンバを最初のミラーに追加するための手順は、"非同期ミラー・メンバを構成する" で説明したものと同じですが、メンバ名と非同期タイプ (読み取り専用または読み書き可能) の変更は不可能です。このボタンは、DR 非同期メンバには使用できません。別のミラーに参加するには、まず、後述の手順で説明するように、[非同期メンバのシステム・タイプ] を変更しておく必要があります。
"レポート非同期ミラー・メンバの FailoverDB フラグのクリア" の説明にあるように、[FailoverDB フラグのクリア] ボタンを使用すると、読み取り専用のレポート非同期にあるすべてのミラーリングされるデータベースの [FailoverDB] フラグをクリアできます。または、非同期システム・タイプを [災害復旧 (DR)] から [読み書き可能] または [読み取り専用のレポート] に変更した後で、このボタンを使用するとフラグをクリアできます。
[ミラー・メンバ情報] セクションの以下の設定は、編集中の非同期メンバに対して変更可能ですが、ミラー・メンバ名は例外です。1 つ以上変更した後に、[保存] をクリックします。
- [ミラー・メンバ名] — 非同期メンバが最初のミラーへ参加したときに、与えられる名前。変更はできません。
- [非同期メンバのシステム・タイプ] — ドロップダウン・リストを使用して、非同期メンバのタイプを変更できます。以下の条件が適用されます。
  - [災害復旧 (DR)] から [読み書き可能のレポート] に変更すると、すべてのミラーリングされるデータベースに対して、[FailoverDB] フラグをクリアするよう促されます。これについては、"レポート非同期ミラー・メンバの FailoverDB フラグのクリア" で説明しています。
  - [読み書き可能のレポート] から [読み取り専用のレポート] (またはその逆) へ変更した場合、変更はレポート非同期メンバが属するすべてのミラーに対して施されます。
  - [読み書き可能] または [読み取り専用のレポート] から [災害復旧 (DR)] に変更することはできません。ただし、以下の条件がすべて当てはまる場合は変更できます。
    - ジャーナル暗号化を使用している場合、非同期はフェイルオーバー・メンバと同じジャーナル暗号化キーを使用していること ("ミラー内ジャーナル暗号の有効化" を参照)。
    - [FailoverDB] フラグが、ミラーリングされるデータベースのすべてに設定されていること (このフラグは、いったんクリアしたら再設定できません。これに対応するため、FailoverDB が設定された別のメンバから取得したデータベースのコピーに置き換えることができます)。
    - メンバば別のミラーに属していないこと。
    - ISCAgent を実行していること ("ISCAgent の開始および停止" を参照)。
    デジャーナル・フィルタが非同期に対して設定されている場合 ("レポート非同期に対するデジャーナル・フィルタの使用" を参照)、そのフィルタは、[非同期メンバのシステム・タイプ] を [災害復旧 (DR)] に変更するときに削除されます。
    Important:
    
    レポート非同期を DR 非同期に変換する前に、昇格が必要になるような災害が発生した場合にメンバがフェイルオーバー・メンバになる準備ができていることを確認してください (" DR 非同期メンバのフェイルオーバー・メンバへの昇格" を参照してください)。このためには以下を確認します。
    - ミラーリングされたすべてのデータベースを持っている
    - 他のすべてのメンバが接続できる ("ミラーリング通信" および "ミラーリング・アーキテクチャとネットワーク構成のサンプル" を参照)
    - プライマリとしての動作に必要なリソースを持っている
- [ミラー・ジャーナル・ファイルの保有] (レポート非同期のみ) — ミラー・ジャーナル・ファイルがデジャーナルされた直後にミラー・ジャーナル・ファイルを削除するか、またはインスタンスのローカル削除ポリシーに従ってミラー・ジャーナル・ファイルを削除するか。この設定は、レポート非同期にのみ使用できます。ジャーナル・ファイルの削除方法についての詳細は、"Caché データ整合性ガイド" の “ジャーナリング” の章にある "ジャーナル・ファイルの削除" を参照してください。
- [SSL/TLS構成] — SSL/TLS が要求される場合は ("SSL/TLS セキュリティを使用したミラー通信の保護" を参照)、X.509 識別名 (DN) と共に [SSL を検証] ボタンが表示されます。このボタンを使用すると、編集中の非同期と通信可能な、現在のすべてのミラー・メンバの SSL 証明書を検証できます。有効でない証明書があった場合、情報メッセージが表示されます。(証明書は、^Mirror ルーチンを使用して検証することもできます。)
  ミラーで SSL/TLS を使用していないときに、ミラーに SSL/TLS を追加する場合は、SSL/TLS を構成するための [SSL/TLS] リンクを使用できます (”フェイルオーバー・メンバの編集または削除” を参照)。
  
  Note:
  
  SYS.Mirror.UpdateMirrorSSL()Opens in a new tab ミラーリング API メソッドおよび ^SECURITY ルーチンを使用して、ミラー・メンバの SSL 設定を更新することもできます。
[この非同期メンバが属するミラー] リストにより、非同期メンバとしてインスタンスが属するすべてのミラーが表示されます。各エントリには、変更のための 3 つのリンクがあります。
- [ミラー名] — [名前] 列に表示されるミラーの名前をクリックすると、[ミラーの編集] ダイアログが開き、ミラーのすべてのメンバのインスタンス・ディレクトリおよびネットワーク・アドレスが表示されます ("ミラー・メンバのネットワーク・アドレス" を参照)。
  現時点で非同期がミラーに接続されている場合、非同期のスーパーサーバ・ポートを除いて、表示されているネットワーク情報は一切変更できません。非同期メンバが切断されているときに、プライマリのネットワーク情報を更新した場合、ここでプライマリの情報を更新できるので、必要に応じて非同期を再接続できます。ミラー・メンバのネットワーク・アドレスの更新に関する重要な情報は、"ミラー・メンバのネットワーク・アドレスの更新" を参照してください。
- [ミラーから脱退] — クリックしたリンク先のミラーから、およびそのミラーのみから非同期メンバを削除します。(DR 非同期の場合、これは所属ミラーのみになります。)
  非同期メンバ上のミラーリングされるデータベースからミラー属性を削除するためのオプションが提供されます。このときの判断に関する詳細は、"ミラーリングされるデータベースの属性の保持または削除" を参照してください。
  
  Note:
  
  ^MIRROR ルーチン ("^MIRROR ルーチンの使用法" を参照) の [ミラー構成] メニューにある [ミラーからこのメンバを削除する] オプションでは、非同期メンバをミラーから削除するための代替手段が提供されます。フェイルオーバー・メンバ上で [ミラーの編集] ページの [他のミラー・メンバを削除する] ボタンを使用して、ミラーから非同期メンバを削除することもできます。
  あらゆる非同期メンバで、ミラーリングを一時停止できます (1 つのレポート非同期が複数ミラーに所属している場合は、ミラーごとに一時停止できます)。詳細は、"バックアップおよび非同期メンバのミラーリングの停止" を参照してください。
- [デジャーナル・フィルタの編集] (レポート非同期のみ) — 非同期に対するデジャーナル・フィルタを設定または削除できます。詳細は、"レポート非同期に対するデジャーナル・フィルタの使用" を参照してください。
[ミラーリングされるデータベース] リストにより、非同期メンバのミラーリングされるデータベースがすべて表示されます。インスタンスが DR 非同期メンバの場合は、インスタンスにミラーのフェイルオーバー・メンバ上のミラーリングされるデータベースをすべて含める必要があります。また、それぞれに [FailoverDB] フラグが設定される必要があります。
SSL/TLS を使用するミラーで、[保留中の DN 更新の承認] を選択し (表示されている場合)、プライマリからの保留中の DN 更新を承認して、非同期がプライマリとの通信を継続できるようにします。DN 更新の承認の詳細は、"X.509 DN 更新の承認 (SSL/TLS のみ)" を参照してください。

フェイルオーバー・メンバの編集または削除

管理ポータルのシステム, 構成, ミラーの編集ページに移動します。
バックアップ・フェイルオーバー・メンバで [ミラー構成を削除する] ボタンを使用すると、ミラーから削除され、Caché インスタンスのミラー構成全体が削除されます。

Important:

ミラー全体を削除する場合、ミラーからまずすべての非同期メンバを削除してから、バックアップ・フェイルオーバー・メンバを削除し、最後にプライマリ・フェイルオーバー・メンバを削除します。

ミラーからフェイルオーバー・メンバを削除するときには、そのメンバ上のミラーリングされるデータベースからミラー属性を削除するオプションが選択できます。この選択の判断に関する詳細は、"ミラー・メンバ削除時のミラーリングされるデータベースの属性の削除" を参照してください。これは、プライマリ・フェイルオーバー・メンバを削除することで、ミラーを永久に削除する場合は特に重要です。
バックアップでは、インスタンスの SSL/TLS 構成を削除するオプションを選択することもできます ("SSL/TLS セキュリティを使用したミラー通信の保護" を参照)。
プライマリで [他のミラー・メンバを削除する] ボタンを使用して、ミラーからバックアップまたは非同期を削除することもできます。バックアップで [他のミラー・メンバを削除する] ボタンを使用すると、ミラーから非同期を削除できます。
[ミラー構成を削除する] ボタンまたは [他のミラー・メンバを削除する] ボタンを使用して、非同期またはバックアップ・メンバのミラー構成全体を削除した場合は、Caché を再起動する必要があります。

Note:

^MIRROR ルーチンの [ミラー構成] メニューにある [ミラー構成を削除する] オプションでは ("^MIRROR ルーチンの使用法" を参照)、フェイルオーバー・メンバのミラー構成全体を削除するための代替手段が提供されています。
バックアップ・フェイルオーバー・メンバのミラーリングは一時的に停止できます。詳細は、"バックアップおよび非同期メンバのミラーリングの停止" を参照してください。
ミラーからプライマリ・フェイルオーバー・メンバを削除して、ミラー全体を削除するには、以下の手順を使用します (プライマリがミラー内に残された最後のメンバである場合にのみ実行できます)。
1. [ミラーの編集] ページの [ミラー構成を削除する] ボタンを使用します。ダイアログが表示され、インスタンスの [JoinMirror] フラグをクリアできます。
2. フラグをクリアした後で、インスタンスを再起動します。
3. システム, 構成, ミラーの編集ページに移動して、再度、[ミラー構成を削除する] ボタンを使用します。
SSL/TLS を要求するミラーに、バージョン 2015.2 より前の Caché の非同期メンバを追加する場合は ("非同期ミラー・メンバを構成する" を参照)、[新規非同期メンバの追加] ボタンを使用して、新しい非同期の X.509 DN を承認します ("第 2 のフェイルオーバー・メンバまたは非同期メンバを承認する (SSL/TLS のみ)" を参照)。ミラーへの非同期メンバの追加ウィザードが表示されます。新しい非同期のスーパーサーバ・アドレスとポートを入力し、[次へ] をクリックして非同期メンバを承認します。ボタンを使用して、2015.2 プライマリ上の 2015.2 より前の非同期の DN を更新することもできます ("X.509 DN 更新の承認 (SSL/TLS のみ)" を参照)。
[ミラー情報] セクションで [ミラー名] を編集することはできません。それ以外の設定は、プライマリ・フェイルオーバー・メンバでのみ変更できます。
- [SSL/TLS を使用] — ミラー作成時に SSL/TLS セキュリティを選択しなかった場合 ("SSL/TLS セキュリティを使用したミラー通信の保護" を参照)、以下の手順に従ってミラーに SSL/TLS セキュリティを追加できます。
  1. プライマリ、バックアップ、およびすべての非同期 (存在する場合) を含む各ミラー・メンバでのミラーの編集時に、[SSL/TLS を使用] チェックボックスの右にある [SSL/TLS を設定] リンクをクリックし、"Caché セキュリティ管理ガイド" の “Caché での SSL/TLS の使用法” の章の "ミラー用 SSL/TLS 構成の作成および編集" セクションの説明に従って、メンバに対してミラーの SSL/TLS 構成を作成してください。(リンクが [SSL/TLS を設定] ではなく [SSL/TLS を編集] である場合、構成は既に存在するため、そのメンバに対しては作成する必要はありません。)
  2. プライマリでミラーを編集し、[SSL を検証] ボタンをクリックします。これにより、編集中のフェイルオーバー・メンバが通信できる現在のすべてのミラー・メンバの SSL 証明書を検証できます。(証明書は、^MIRROR ルーチンを使用して検証することもできます)。無効な証明書がある場合、通知メッセージが表示されます。構成を確認し、必要に応じて証明書を置き換えてください。それ以外の場合は、次のステップに進みます。
  3. [SSL/TLS を使用] チェックボックスを選択して、[保存] をクリックします。
  4. "第 2 のフェイルオーバー・メンバまたは非同期メンバを承認する (SSL/TLS のみ)" に説明されているとおり、バックアップおよび非同期のメンバを承認します。
  Note:
  
  この手順で SSL/TLS セキュリティを追加する際、ミラーが稼働している必要はありません。
  SYS.Mirror.UpdateMirrorSSL()Opens in a new tab ミラーリング API メソッドおよび ^SECURITY ルーチンを使用して、ミラー・メンバの SSL 設定を更新することもできます。
- アービターを使用 — ミラー作成時にアービターを構成しなかった場合は、この設定をプライマリで選択し、アービターとして構成するシステムのホスト名または IP アドレス、およびその ISCAgent プロセスで使用するポート (既定では 2188) を入力することで、アービターを構成できます。アービターに関する詳細は、"自動フェイルオーバーのメカニズム"、"ミラーの可用性を最適化するためのアービターの配置"、および "アービターのインストール" を参照してください。
- 仮想 IP を使用 — このチェック・ボックスにチェックを付ける、または外すことにより、仮想 IP アドレスを使用するかどうかを変更します。[仮想 IP を使用] を選択した場合、IP アドレス、クラスレスのドメイン間ルーティング (CIDR) マスク、およびネットワーク・インタフェースを与える必要があります (提供済みの場合は変更可能)。
  
  Important:
  
  VIP 構成前の要求事項や重要考慮事項の詳細は、"ミラー仮想 IP (VIP) の構成" を参照してください。
- サービス品質のタイムアウト (msec) — フェイルオーバー・メンバが、アクションを実行する前に、他のフェイルオーバー・メンバからの応答を待機する最大時間 (ミリ秒単位)。さらに、フェイルオーバー・メンバの応答をアービターが待機する場合にも適用されます。詳細は、"サービス品質 (QoS) タイムアウトの構成" を参照してください。この設定は、プライマリ・フェイルオーバー・メンバでのみ変更できます。
- [フェイルオーバー・メンバの圧縮モデル]、[非同期メンバの圧縮モデル] — プライマリからバックアップ・メンバおよび非同期メンバにジャーナル・データを転送する前に、データを圧縮するかどうかを指定する、それぞれの設定を変更します。詳細は、"ジャーナル・データの圧縮" を参照してください。一方または両方の圧縮設定を変更すると、その影響を受けるすべてのメンバ (バックアップや非同期) のミラー接続が再起動され、新しい圧縮モードがすぐに使用できるようになります。
- [並列デジャーナリングを許可する] — 並列デジャーナリングを有効にする対象をフェイルオーバー・メンバおよび DR 非同期にする (既定) か、レポート非同期を含むすべてのメンバにするか、またはフェイルオーバー・メンバのみにするかを指定する設定を変更します。並列デジャーナリングではミラーのスループットが向上しますが、複数のデータベースが関与するクエリまたはレポートの結果の一貫性が損なわれる可能性が若干高まる場合があります。詳細は、"並列デジャーナリングの構成" を参照してください。
[ミラー・メンバ情報] セクションには、各ミラーメンバのメンバ名とタイプ、インスタンス・ディレクトリ、およびネットワーク・アドレスが表示されます。プライマリで、メンバ名をクリックして、そのメンバのネットワーク情報を更新します (メンバのスーパーサーバ・ポートを除きます。このポートは、ローカルに更新する必要があります。詳細は、"ミラー・メンバのネットワーク・アドレス"の更新" を参照してください)。
現時点でバックアップがミラーに接続されている場合、ネットワーク情報は一切変更できません (バックアップのスーパーサーバ・ポートを除く)。バックアップを切断して、プライマリのネットワーク情報を変更した場合は、ここでプライマリの情報を更新できるので、必要に応じてバックアップが再接続できます。ミラー・メンバのネットワーク・アドレスの更新に関する重要な情報は、"ミラー・メンバのネットワーク・アドレスの更新" を参照してください。
SSL/TLS を使用するミラー内のプライマリで、[保留中の新しいメンバの承認/拒否] リンクを選択し (表示されている場合)、新しいメンバを承認して、ミラーに参加できるようにします。または、[保留中の DN 更新の承認/拒否] リンクを選択し (表示されている場合)、その他のメンバの DN 更新を承認して、ミラーの通信を継続できるようにします。バックアップで、[保留中の DN 更新の承認] を選択し (表示されている場合)、プライマリからの保留中の DN 更新を承認して、バックアップがプライマリとの通信を継続できるようにします。DN 更新の承認の詳細は、"X.509 DN 更新の承認 (SSL/TLS のみ)" を参照してください。
[保存] をクリックします。

ミラーリングされるデータベースをミラーから削除する

ミラー・モニタを使用して、データベースをミラーから削除することにより、データベースをミラーリングされる状態から、ミラーリングされないローカル用に変換できます (ミラー・モニタに関する詳細は、"ミラーの監視" を参照してください)。

Note:

あるいは、ミラーリングされるデータベースをミラーから複数削除するには、^MIRROR ルーチンの [ミラー管理] メイン・メニュー・リストから [ミラーリングされるデータベースの削除] オプションを選択できます ("^MIRROR ルーチンの使用法" を参照)。

非同期メンバ上でミラーからデータベースを削除しても、フェイルオーバー・メンバは影響を受けません。データベースは機能しているミラーの一部として残ります。ただし、データベースをフェイルオーバー・メンバから削除した場合、データベースがミラーリングされる他のフェイルオーバー・メンバや非同期メンバからもデータベースを削除する必要があります。データベース全体をミラーから削除するには、プライマリ・フェイルオーバー・メンバ、バックアップ・フェイルオーバー・メンバ、任意の非同期メンバの順でデータベースの削除を行います。

Important:

プライマリでミラーからデータベースを削除すると、データベースは完全に削除されます。プライマリで、ミラーリングされるデータベースを削除して、後でミラーに戻すには、最初に既存のデータベースをミラーに追加するために使用した手順が必要になります。

データベースをミラーから削除するには、いずれかのフェイルオーバー・システムで次の手順を実行します。

プライマリ・フェイルオーバー・メンバのシステム, ミラーモニタページに移動します。
[ミラーリングされるデータベース] リスト内で、ミラーから削除するデータベースの行の [削除] をクリックします。
一度に複数のデータベースを削除する場合は、[アクションを選択してください] ドロップダウンから [削除] を選択し、[検索] をクリックしてダイアログを開き、そこで複数のミラーリングされたデータベースを選択してすべてを一度に削除できます。

ミラー内ジャーナル暗号の有効化

"Caché セキュリティ管理ガイド" の “マネージド・キー暗号化” の章の説明に従って、任意の Caché インスタンスのジャーナル・ファイル暗号化を有効にできます。そのようにする場合は、以下の 3 つの重要な考慮事項に注意を払ってください。

ミラーが SSL/TLS セキュリティを要求しない場合、ジャーナル・ファイルの暗号化を有効にできません。
ジャーナル暗号化がプライマリで有効化されている場合は、ミラーに属しているレポート非同期でも有効化されている必要があります。さらに、バックアップ非同期および DR 非同期も同様にジャーナル暗号化を有効化することが最善策になります。これにより、フェイルオーバーまたは DR 昇格の発生時に、ジャーナル暗号化の強制実施が継続されます。
フェイルオーバー・メンバ間または DR 非同期間でのジャーナル暗号化には、あるメンバでアクティブ化されるジャーナル暗号化に使用する暗号化キー (ただし、必ずしもジャーナル暗号化に使用されている必要はありません) が別のメンバで必要になります。具体的には以下の処理を行います。
- ジャーナル暗号化がプライマリで有効化されている場合、プライマリでジャーナル暗号化に使用されているキーは、バックアップおよびすべての DR 非同期にロードされていて有効化されている必要があります。(プライマリのジャーナル暗号化キーがアクティブ化されていないレポート非同期が DR 非同期に変更されると、警告が生成されます。その非同期は一時的にミラーに接続された状態を維持できますが、次回の再接続ができなくなります。キーがアクティブ化されている場合を除いて、これが必要になります。)
- バックアップまたは DR 非同期でジャーナル暗号化がアクティブ化されている場合は、そのメンバでジャーナル暗号化に使用されているキーはプライマリにロードされていてアクティブ化されている必要があります。
繰り返しになりますが、フェイルオーバーまたは昇格の準備をする際の最善策として、フェイルオーバー・メンバであるメンバ (プライマリ、バックアップ) またはフェイルオーバー・メンバになる可能性のあるメンバ (DR 非同期) にジャーナル暗号化キーが指定されている場合、そのようなメンバのすべて (複数の DR 非同期を含む) に、このキーをロードしておく必要があります

Note:

1 つの Caché インスタンスは常に最大 4 つの暗号化キーをアクティブ化できますが、ジャーナル暗号化に指定されるのは、これらのキーのうち 1 つのみです。異なるジャーナル暗号化キーを異なるミラー・メンバに使用することはできますが、キーが 4 つに制限されているため、この最善策に従う場合、複数の DR 非同期メンバを持つ 1 つのミラーは複数のメンバに同じ暗号化キーを使用する必要があります。

例えば、フェイルオーバー・メンバ A (現在のプライマリ) と B (現在のバックアップ)、DR 非同期 D、およびレポート非同期 R1 および R2 で構成されるミラーがあるとします。このミラー内でジャーナル暗号化をアクティブ化する場合は、以下の手順を実行することになります。

現時点でミラーに SSL/TLS セキュリティが必要ない場合は ("SSL/TLS セキュリティを使用したミラー通信の保護" を参照)、"フェイルオーバー・メンバの編集または削除" で説明している手順を使用して、そのようにミラーを構成します。
A、B、および D の暗号化ジャーナル・ファイルに使用する 1 つまたは複数の暗号化キーを選択します。これらは、別々のものにすることができます (必要な場合)。
選択した 1 つまたは複数のキーを A、B、および D にロードしてアクティブ化します。必要に応じて、R1 および R2 でキーをアクティブ化できますが、それらが DR 非同期に変更される可能性がない場合は必要ありません。
ジャーナルの暗号化を A、B、D、および R2 の順にアクティブ化します。
ジャーナル暗号化をアクティブ化した後で、ミラーに DR 非同期を追加するときに、A、B および D で使用しているジャーナル暗号化のキー (1 つまたは複数) が、追加前の新しい DR 非同期でアクティブ化されていることを確認してください。

Note:

ミラー・メンバ上のデータベース暗号化には、いずれのシステムでも準備が必要ですが、データベース暗号化についてはミラーリングに関する特定の要件はありません。ただし、最高度のセキュリティを実施するには、すべてのミラー・メンバ上のミラーリングされるデータベースを暗号化することをお勧めします。この理由から、プライマリ上で暗号化されているミラーリングされたデータベースを、別のメンバを暗号化せずにそのメンバに追加する場合、警告がコンソール・ログに送信されます。

"ミラーへ既存データベースを追加する" で説明しているように、プライマリのミラーに既存データベースを追加する場合、そのデータベースが暗号化されていると、使用するメソッドによっては、その他のミラー・メンバにおける追加時に、データベースの暗号化キーを変換しなければならない場合があります。このトピックの詳細は、"Caché データ整合性ガイド" の “バックアップとリストア” の章の "データベース暗号化に関する注意事項" を参照してください。

ミラーへの ECP 接続の構成

ECP アプリケーション・サーバ上のミラー接続として ECP データ・サーバを構成すると、アプリケーション・サーバは、ミラーについて更新された情報をプライマリから定期的に収集し、フェイルオーバーを自動的に検出し、必要に応じて新しいプライマリに接続をリダイレクトします。

以下の手順を使用して、ミラーを ECP データ・サーバとして構成し、ECP アプリケーション・サーバ上のミラー接続として構成します。

両方のフェイルオーバー・メンバおよび任意の DR 非同期メンバで、管理ポータルのシステム, 構成, ECP設定ページに移動し、システムを ECP データ・サーバとして構成します。詳細は、"Caché 分散データ管理ガイド" の “分散システムの構成” の章にある "ECP データ・サーバの構成" を参照してください。両方のフェイルオーバー・メンバとすべての DR 非同期がこのように構成されている必要があります。すべて同じ [アプリケーションサーバの最大数] 設定にします。
ECP アプリケーション・サーバで、システム, 構成, ECP設定ページに移動し、[リモート・データ・サーバの追加] をクリックしした後、次の情報を入力します。
1. [サーバ名] — プライマリ・フェイルオーバー・メンバのインスタンス名を入力します。
2. [ホスト DNS 名または IP アドレス] — プライマリ・フェイルオーバー・メンバの IP アドレスまたはホスト DNS 名を入力します。(ミラー VIP を入力しないでください。詳細は、"ミラー仮想 IP (VIP) の構成" を参照してください。)
3. [IP ポート] — [ホスト DNS 名または IP アドレス] テキスト・ボックスで指定した IP アドレスまたはホスト DNS 名を持つプライマリ・フェイルオーバー・メンバのスーパーサーバ・ポート番号を入力します。
4. [ミラー接続] — このチェック・ボックスのチェックを付けます。
[保存] をクリックします。
システム, 構成, リモートデータベースに移動し、[新規リモートデータベース作成] を選択して [データベースウィザード] を開始します。
[データベースウィザード] で、[リモートサーバ] ドロップダウン・リストから ECP データ・サーバを選択し、[次] をクリックします。
この ECP チャンネルを介してアクセスするデータベースをリモート・データベースのリストから選択します。
ミラーリングされないデータベース (:ds:DB_name としてリストされているデータベース) とミラーリングされるデータベース (:mirror:mirror_name:mirror_DB_name としてリストされているデータベース) の両方を選択できます。
- ミラーリングされない、ジャーナルされるデータベースは、読み取り専用モードでのみ使用可能です。
- ミラーリングされず、ジャーナルされないデータベースは、読み取り/書き込みモードで使用可能です。
- ミラーリングされるデータベースは、読み取り/書き込みモードで使用可能です。
Note:

ミラーリングされるデータベースの「:mirror:mirror_name:mirror_DB_name:」というパス形式は、暗示的なネームスペース拡張グローバル参照に使用することもできます ("Caché グローバルの使用法" の “グローバル構造” の章の "拡張グローバル参照" を参照)。

Important:

フェイルオーバー・ミラー・メンバは、前記の 2 つの方法のいずれかでミラー接続として構成されていない ECP 接続を受け入れません。また、ミラー・メンバではない ECP データ・サーバは、ミラー接続として構成されている ECP 接続を受け入れません。つまり、既存の ECP データ・サーバをミラーに追加する場合、または ECP データ・サーバをミラーから削除する場合、すべての ECP アプリケーション・サーバのリモート・データ・サーバとして ECP データ・サーバを削除してから、適切な手順、つまり 2 つの方法のいずれか、またはフェイルオーバー・メンバへの接続がない場合には [ミラー接続] のチェック・ボックスのチェックを外して、再度 ECP データ・サーバを追加します。

ミラーに接続する ECP アプリケーション・サーバは、Caché 2010.2 以降を実行している必要があります。

ミラーに接続するよう ECP アプリケーション・サーバを構成した後に、現在のプライマリを適切にシャットダウンすることによってリダイレクト・テストを実施し、アプリケーション・サーバが目的のミラー・メンバに接続していることを確認してください。

アプリケーション・サーバの ECPServer 定義の Address プロパティおよび Port プロパティによって指定されたミラー・メンバに接続を制限している間には、ECP データ・サーバをミラー接続として識別することもできます。つまり、アプリケーション・サーバは、指定されたメンバがプライマリではない場合でも接続をリダイレクトしません。このように接続を構成すると、以下のルールが適用されます。

指定されたメンバがプライマリの場合、アプリケーション・サーバからの接続を通常として受け入れます。メンバがフェイルオーバー・メンバだがプライマリではない場合 (前のプライマリが再起動されてバックアップになったときなど)、これがプライマリになったときに接続を受け入れます。
指定されたメンバが前のプライマリで、再起動されて再びプライマリになった場合、アプリケーション・サーバのこのメンバへの接続はリカバリされます。メンバがフェイルオーバー・メンバだがプライマリではない場合、これがプライマリになるまで接続を受け入れません。
指定されたメンバが DR 非同期の場合、接続を受け入れ、ミラーリングされるデータベースへの読み取り専用アクセス権をアプリケーション・サーバに付与します。

指定されたミラー・メンバに接続を制限することは、他のメンバに接続をリダイレクトすることが望ましくないとき (接続が高遅延 ECP 接続になるなど) に、ある特別な構成で役に立ちます。2 つの使用例を以下に示します。

ミラー・プライマリがデータ・センタ A (DCA) にあり、バックアップまたは DR 非同期がリモート・データ・センタ (DCB) にあるとします。各メンバにアプリケーション・サーバが構成された独自のバンクがあるとします。ネットワーク・ロード・バランサが接続を正しいデータ・センタに接続します。ただし、プライマリが使用できなくなり、DCB のメンバがフェイルオーバーまたは昇格によってプライマリになった場合、DCA のアプリケーション・サーバが DCB のメンバに接続することを望みません。DCA と DCB の間で高遅延接続が発生することになるからです。この状況では、DCA のアプリケーション・サーバで、フェイルオーバー発生時に DCB にリダイレクトしないようにミラー接続をプライマリに制限し、DCA のメンバが再びプライマリになるときにデータセンタ間の接続をリカバリできるようにします。
プライマリとバックアップが DCA にあり、DR 非同期が災害発生時に使用する独自のアプリケーション・サーバと共にリモート DCB にあるとします。 DCA のアプリケーション・サーバでは、プライマリは標準のミラー接続で構成されます。これは、フェイルオーバー時に DCA 内で接続をリダイレクトするためです。ただし、DCB のアプリケーション・サーバでは、ミラー接続は DR 非同期にリダイレクトされます。このようにすれば、災害リカバリ準備の一環としてまたは実際の災害時のカット・オーバーの前に読み取り専用ベースでミラー接続をテストできます。DR 非同期が昇格された後、DCA のアプリケーション・サーバは接続を DCB の新しいプライマリにリダイレクトしますが (ネットワーク・レベルで妨げられていない場合)、まだ降格されていない場合には、降格してこの動作を妨げることができます。

管理ポータルを使用してアプリケーション・サーバの接続を指定ミラー・メンバに制限できません。代わりに、以下の手順を実行します。

このセクションで説明した手順を使用してフェイルオーバー・メンバおよび DR 非同期を ECP データ・サーバとして構成し、アプリケーション・サーバでデータ・サーバへの接続を構成します (この手順をまだ実行していない場合)。
Config.ECPServer クラスを使用してアプリケーション・サーバの MirrorConnection プロパティを変更し、その値として -1 を指定します。アプリケーション・サーバ・インスタンスの cache.cpf ファイルを編集することもできます (この方法は、"Caché パラメータ・ファイル・リファレンス" を参照)。ファイルの [ECPServers] セクションで、3 番目のパラメータを 0 から -1 に変更します。詳細は、"Caché パラメータ・ファイル・リファレンス" の "ECPServers" を参照してください。
いずれかの方法で MirrorConnection プロパティを変更したら、管理ポータルを使用して [ミラー接続] チェック・ボックスの設定を変更しないでください。

ミラー仮想 IP (VIP) の構成

"ミラー仮想 IP (VIP) の計画" で説明しているように、フェイルオーバーで継続的なアクセスを確保するために、外部アプリケーションが単一のアドレスを使用してミラーと対話できるようにするミラー仮想アドレスを構成することができます。

ミラー VIP を使用するよう Caché を構成してからミラー VIP を構成した後に、現在のプライマリを適切にシャットダウンすることによってフェイルオーバー・テストを実施し ("計画的停止の手順" に記載)、どちらのフェイルオーバー・メンバがプライマリであるかに関係なく、アプリケーションが引き続きミラーに接続できることを確認してください。

Important:

Note:

VIP 使用時に DR 非同期をプライマリに昇格する処理に関する重要な情報は、"DR 非同期メンバのフェイルオーバー・メンバへの昇格" を参照してください。

ミラー VIP の Caché 構成

現在どちらのフェイルオーバー・メンバがプライマリとなっているのかに関係なく、管理ポータルと Caché スタジオが、確実にミラーにシームレスにアクセスできるようにするために、同じスーパーサーバ・ポート番号および Web サーバ・ポート番号を使用するように、フェイルオーバー・メンバを構成することをお勧めします。

ECP アプリケーション・サーバはミラーの VIP を使用しません。ECP データ・サーバとしてミラーを追加する場合は ("ミラーへの ECP 接続の構成" を参照)、ミラーの仮想 IP アドレス (VIP) を入力するのではなく、現在のプライマリ・フェイルオーバー・メンバの DNS 名または IP アドレスを入力します。アプリケーション・サーバは、指定のホストからミラーに関する更新情報を定期的に収集しているので、フェイルオーバーを自動的に検出し、新しいプライマリ・フェイルオーバー・メンバに切り替えます。この理由から、フェイルオーバー・メンバとすべての DR 非同期メンバは、ECP データ・サーバとして、同じ [アプリケーションサーバの最大数] 設定で構成する必要があります。ECP の考慮事項についての詳細は、"ミラーへの ECP 接続の構成" を参照してください。

1 つまたは両方のフェイルオーバー・メンバをライセンス・サーバとして構成する場合 ("Caché システム管理ガイド" の “Caché ライセンスの管理” の章で説明しています)、[ホスト名/IP アドレス] として構成するシステムの実際のホスト名または IP アドレスを指定します。VIP アドレスは入力しないでください。

ミラー VIP の構成

ミラー VIP を構成するには、次の情報を入力する必要があります。

ミラー VIP として使用可能な IP アドレス。VIP を予約して、その他のシステムが使用できないようにしておくことが重要です。例えば、動的ホスト構成プロトコル (DHCP) のネットワーク構成では、この VIP を予約し DNS テーブルから削除して、ネットワークに参加しているホストに動的に割り当てられないようにする必要があります。
クラスレスのドメイン間ルーティング (CIDR) 表記での指定が必要な適正ネットワーク・マスク。CIDR 表記の形式は、ip_address/CIDR_mask です。ip_address は、システムのベース IP アドレスです。CIDR_mask は、次のようにプラットフォームによって異なります。
- Mac OS X — /32 でなければなりません。
- 他のすべてのプラットフォーム — ベース・インタフェースに割り当てられた IP アドレスのマスクと一致する必要があります。以下はその例です。
```
bash-2.05b# uname -a 
AIX apis 3 5 00C0B33E4C00
bash-2.05b# ifconfig en1
en1:
flags=5e080863,c0<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,
GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),PSEG,LARGESEND,CHAIN>
        inet 10.0.2.11 netmask 0xffffff00 broadcast 10.0.2.255
        tcp_sendspace 131072 tcp_recvspace 65536 rfc1323 
```
  この例では、[en1] インタフェースは、ベース・アドレスが 10.0.2.11 でネットマスクが 0xffffff00 となっており、ネットマスクは /24 に変換されます。したがって、[en1] インタフェースに 10.0.2.100 を VIP として割り当てるには、ネットワーク・マスクを 10.0.2.100/24 (CIDR 表記) と指定します。
各フェイルオーバー・メンバで使用可能なネットワーク・インタフェース2 つのシステムで選択されたインタフェースは、VIP と同じサブネットとする必要があります。
ネットワーク・インタフェースを選択するときには、そのインタフェースを正しく動作させるために、以下のプラットフォーム固有の規則に従う必要があります。
- HP-UX — VIP を構成するときに、新しい (未使用の) 仮想ネットワーク・インタフェースを使用できるよう設定する必要があります。ネットワーク・カードに関連付けられたインタフェース名は、インタフェースの名前 (例えば、lan または snap)、このインタフェースのカード・インスタンスを識別する ppa 番号、およびインタフェース用に複数の IP アドレスを構成できるようにするオプションの IP インデックス番号から構成されます。仮想インタフェースは、0 以外の IP インデックス番号を含むインタフェースです (例えば、lan0:1)。ただし、ベース・インタフェース (この場合 lan0) が既に存在している必要があります。
- Oracle Solaris — VIP を構成するときに、新しい (未使用の) 仮想ネットワーク・インタフェースを使用できるよう設定する必要があります。ネットワーク・カードに関連付けられたインタフェース名は、インタフェースの名前 (例えば、lan または snap)、およびインタフェース用に複数の IP アドレスを構成できるようにするオプションの IP インデックス番号から構成されます。仮想インタフェースは、0 以外の IP インデックス番号を含むインタフェースです (例えば、lan0:1)。ただし、ベース・インタフェース (この場合 lan0) が既に存在している必要があります。
- IBM AIX®、Linux (Red Hat および SuSE)、Apple Mac OS X、および Windows — VIP を構成するときに、既存の物理ネットワーク・インタフェースを使用できるように設定する必要があります。これらのプラットフォームでは、IP アドレスのエイリアスは、IP アドレス (すなわち VIP) を既存の物理ネットワーク・インタフェースにバインドするために使用されます。また、このプラットフォームでは、単一の物理ネットワーク・インタフェースで複数の IP アドレスをホストできます。

ISCAgent の構成

ISCAgent の実行は、各ミラー・メンバ上の構成可能な専用ポート (既定値は 2188) で安全に行われます。このエージェントがネットワーク接続を受信してミラーリングされたインスタンスにつながると、そのインスタンスの cuxagent を実行して、ミラー・メンバの管理に必要な特権にエスカレートします。ミラーが SSL/TLS を要求する構成の場合、何らかのアクションを実行する前に、受信接続が認証されます。

1 つ以上のミラーに属する複数の Caché インスタンスが、1 つのシステムでホストされている場合、それらのインスタンスは、1 つの ISCAgent を共有します。

ここでは、以下の方法で ISCAgent を管理するための情報を提供します。

ISCAgent の開始および停止

Caché のインストールまたはアップグレード時にインストールされる ISCAgent は既定により、ユーザ [ISCAgent] として、かつ [ISCAgent] グループのメンバとして動作します。Caché インスタンスへのアクセスを提供する cuxagent ユーティリティの実行に必要なグループ特権 ("ISCAgent" を参照) を取得するために、ISCAgent は、システム起動時に自動で開始されるようにするか、root 特権を持つユーザが開始する必要があります。ISCAgent は、自身に必要なユーザ特権およびグループ特権を割り当てると、すべての root 特権を破棄します。

ISCAgent の構成により、各フェイルオーバー・メンバおよび DR 非同期ミラー・メンバでのシステム起動時に、ISCAgent を自動で開始させる必要があります。システム管理者が初期化プロセスに追加できるプラットフォーム固有の制御スクリプトが提供されています。これについて、以下の節で説明します (システム起動の構成手順の詳細は、オペレーティング・システムのドキュメントを参照してください)。

UNIX® および Mac OS X システムでの ISCAgent の開始

UNIX® および Mac OS X のプラットフォームでは、オペレーティング・システムに応じて、次の場所にインストールされる ISCAgent の開始および停止スクリプトを実行します。

IBM AIX® : /etc/rc.d/init.d/ISCAgent
HP-UX ： /sbin/init.d/ISCAgent
Solaris ： /etc/init.d/ISCAgent
Mac OS X ： /Library/StartupItems/ISCAgent/ISCAgent

例えば、IBM AIX® プラットフォームで ISCAgent を開始する場合は、root としてコマンド /etc/rc.d/init.d/ISCAgent start を実行します。このサービスを停止するには、コマンド /etc/rc.d/init.d/ISCAgent stop を実行します。

UNIX®/Linux のプラットフォームでの ISCAgent に関するその他の考慮事項としては、以下のものがあります。

前述したように、ISCAgent は、各フェイルオーバー・メンバまたは DR 非同期メンバで、システム起動時に自動的に開始される必要があります。また、ユーザがこのエージェントを開始、停止、または再開するのが便利なときもあります。これは以下の方法で実行できます。
- 前の手順で説明したように、root ユーザが直接的に実行します。
- Caché インスタンスの開始と停止が可能なユーザが、Caché インスタンスの /bin ディレクトリにある agentctrl 実行ファイルを使用します。例えば、エージェントを開始するには、以下のコマンドを実行します。
```
/cache/bin$ ./agentctrl start
```
  このコマンドは、引数 [停止] および [再開始] を取ります。
Caché では、ISCAgent のステータスを追跡するために iscagent.status ファイルを使用します。このファイルは、CACHESYS 環境変数で指定されるディレクトリ内にあります ("Caché インストールガイド" の序文の "Caché のインストール・ディレクトリ" を参照)。CACHESYS が定義されていない場合は、/var/run にあります。エージェントは、このファイルに対する排他的ロックを取得できる必要があるため、iscagent.status ファイルが /var/run に配置されていて、/var/run が NFS でマウントされたファイルシステムにある場合は、その NFS 構成が fcntl ファイル・ロックをサポートしている必要があります。
前述したように、ISCAgent は cuxagent を使用して、Caché インスタンスの管理に必要な特権を取得します。既定により、エージェントは cuxagent の実行に必要な特権 ([ISCAgent] ユーザまたは [ISCAgent] グループ) を所有しており、標準的な構成においては変更が不要です。
ただし、ユーザ・システムのセキュリティ構成により、ユーザ・サイトのインスタンスには、cuxagent を実行するにあたって、ミラーリングされるインスタンスの /bin ディレクトリに移動するための追加特権が必要になる場合があります。この場合、ISCAgent の特権がコマンドの実行に十分なものであるかを確認する必要があります。そのためには、以下の手順に従って、エージェントの特権を変更できます。
1. /etc/iscagent/iscagent.conf ファイルを作成します。ファイルが既に存在する場合は、それを編集します (例えば、以前にファイルを作成して、ISCAgent のポート番号やインタフェースをカスタマイズした場合)。
2. グループ特権を追加するには、以下の行を追加して、cuxagent の実行が必要なグループを 1 つ以上指定します。
```
privileges.group=iscagent,<groupname>[,<groupname>[,...]]
```
  通常は、グループ特権の追加で十分となります。しかし、一部の構成では、別のユーザとして ISCAgent を実行することが必要になる場合もあります。これは、/etc/iscagent/iscagent.conf で、以下のように実行することもできます。
```
privileges.user= <username>
```
  Note:
  
  cuxagent には、[ISCAgent] グループ特権が必要なので、[ISCAgent] はグループ・リストに残る必要があります。
ミラーリングには、env 実行可能スクリプトを /usr/bin ディレクトリにインストールすること、かつ Bash シェルをロードして、開始環境パスに置くことが必要になります。後者を実現する容易な方法のひとつに、ln -s <bash_dir> /usr/bin/bash などのシンボリック・リンクの作成があります。<bash_dir> は、Bash がインストールされるディレクトリです (/usr/local/bin/bash など)。/usr/bin は、あらゆるユーザのパスにあるので、このようなリンクによって、すべてのプロセスで Bash の自動検出が可能になります。
ISCAgent はオペレーティング・システムのシステム・エラー・ログ (Linux では /var/log/messages など) にメッセージを書き込みます。

Linux システムでの ISCAgent の開始

systemd をサポートしている Linux システム (SUSE Linux Enterprise Server 12 SP1 以降など) の場合は、/etc/systemd/system/ISCAgent.service ファイルがインストールされています。これにより、systemd を使用した ISCAgent の管理がサポートされるようになります。このようなシステムでは、ISCAgent の開始、停止およびステータスの表示に、以下のコマンドを使用できます。

systemctl start ISCAgent.service
systemctl stop ISCAgent.service
systemctl status ISCAgent.service

systemd をサポートするシステムの場合、システムのブート時に ISCAgent を開始するかどうかを制御するには、以下のコマンドを使用します。

sudo systemctl enable ISCAgent.service
sudo systemctl disable ISCAgent.service

既定では、systemd サービスは無効化されています。このサービスが無効化されている場合でも、systemctl を使用すると、必要に応じてサービスを開始および停止できます。

ISCAgent.service ファイルは、Caché レジストリ・ファイルと共有サポート・ファイルの場所を CACHESYS 環境変数から読み込みません ("Caché インストール・ガイド" の序文の "Caché インストール・ディレクトリ" を参照)。代わりに、その場所として /usr/local/etc/cachesys にインストールされます。ISCAgent.service を編集して、別のレジストリ・ディレクトリを指定することもできます (必要な場合)。

どの Linux システムでも、ISCAgent の開始/停止スクリプトは、/etc/init.d/ISCAgent にインストールされます。このスクリプトについては、"UNIX® および Mac OS X システムでの ISCAgent の開始" を参照してください。systemd がサポートされていない場合は、上記のセクションで説明している ISCAgent の開始および停止コマンドを使用します。

"UNIX® および Mac OS X システムでの ISCAgent の開始" に記載されたそれ以外の情報は、systemd をサポートする Linux システムにも適用されます。

Important:

systemd をサポートする Linux システムでは、systemctl コマンドと /etc/init.d/ISCAgent スクリプトのどちらを使用することも可能ですが、どちらか一方の方法に決めて、それを切り替えることなく排他的に使用する必要があります。ISCAgent を停止する際には、常に、それを開始した方法を使用する必要があります。

前述のような Linux システムで Caché をアップグレードすると、実行中の ISCAgent は systemd を使用して自動的に再起動します。/etc/init.d/ISCAgent スクリプトを使用して ISCAgent を管理している場合、このエージェントが自動的に再起動しないように、アップグレードを実行する前にエージェントを停止し、アップグレード後にスクリプトを使用してエージェントを再起動します。

/etc/init.d/ISCAgent スクリプトの使用から systemctl コマンドの使用に変更したら、初めて systemctl でエージェントを開始する前に root として以下を実行します。

以下のコマンドを実行します。
```
systemctl status ISCAgent
```
このコマンドの出力に以下の警告が含まれている場合：
```
Warning: Unit file changed on disk, 'systemctl daemon-reload' recommended.
```
以下のコマンドを実行します｡
```
systemctl daemon-reload
```
上記のコマンドが完了したら、systemctl status ISCAgent を再実行し、警告が表示されないことを確認します。

UNIX®/Linux および Mac OS X システムでの非 root インスタンス用 ISCAgent の開始

通常、Caché は root としてインストールされますが、UNIX®/Linux および Mac OS X システムでは、それとは別のユーザがインスタンスをインストールして実行することが可能です。非 root インストールの詳細は、"Caché インストール・ガイド" の “UNIX® および Linuxへの Caché のインストール” の章にある "Caché 非 root インストール" を参照してください。

非 root インスタンス用の ISCAgent は、インストール・ユーザが ISCAgentUser スクリプト (CACHESYS 環境変数で定義されたディレクトリにある) を実行すると、バックグラウンドで開始されます。以下に例を示します。

nohup <CACHESYS_directory>/ISCAgentUser &

システム起動時に、ISCAgent が自動的に開始するように構成することはできないかもしれませんが、それが実現可能ならば、そちらを選択してください。ミラーに 2 つのフェイルオーバー・メンバが含まれている場合のベスト・プラクティスは、システムの起動後に、Caché を開始するつもりがない場合でも、できるだけ早くエージェントを起動することです。これは、"両方のフェイルオーバー・メンバの計画外停止" の説明にあるような特定の状況で、復旧の支援になります。

Microsoft Windows システムでの ISCAgent の開始

Microsoft Windows システムでは、次の方法で ISCAgent プロセスを開始します。

Microsoft Windows の [コントロールパネル] で、[管理ツール] の [サービス] を選択し、[ISCAgent] をダブルクリックして、[ISCAgent のプロパティ] ウィンドウを表示します。
[拡張] タブで、[開始] をクリックして ISCAgent を開始するか、[停止] をクリックして停止します。
[全般] タブの [スタートアップの種類] ドロップダウン・リストから [自動] を選択します。

ISCAgent ポート番号のカスタマイズ

この章の "ISCAgent" のセクションで説明するとおり、既定の ISCAgent ポートは 2188 です。通常はこれで十分ですが、以降のサブセクションで説明するとおり、このポート番号は必要に応じて変更できます。

UNIX® または Linux システムでの ISCAgent ポート番号のカスタマイズ

既定では、ISCAgent プロセスは、ポート 2188 で開始されます。UNIX® または Linux システムでこのポートをカスタマイズするには、次の手順を実行します。

/etc/iscagent/iscagent.conf ファイルを作成します。ファイルが既に存在する場合は、そのファイルを編集します。
次の行を追加し、<port> を目的のポート番号に置き換えます。
```
application_server.port=<port>
```

Microsoft Windows システムでの ISCAgent ポート番号のカスタマイズ

既定では、ISCAgent プロセスは、ポート 2188 で開始されます。Windows システムでこのポートをカスタマイズするには、次の手順を実行します。

<windir>\system32\iscagent.conf ファイルを作成します。ファイルが既に存在する場合は、そのファイルを編集します。
次の行を追加し、<port> を目的のポート番号に置き換えます。
```
application_server.port=<port>
```

ISCAgent インタフェースのカスタマイズ

ISCAgent は使用可能なインタフェースすべての既定 (もしくは構成された) ポートに結合します。通常はこれで十分ですが、必要に応じて、特定のアドレスに対応するインタフェースに結合するよう ISCAgent を変更することができます。この手順は、以下のサブセクションで説明します。

UNIX® または Linux システムでの ISCAgent インタフェースのカスタマイズ

ISCAgent プロセスは使用可能なインタフェースすべての既定 (もしくは構成された) ポートに結合します。ISCAgent をカスタマイズして、UNIX® または Linux システムの指定アドレスに対応するインタフェースへ結合するには、以下の手順を実行します。

/etc/iscagent/iscagent.conf ファイルを作成します。ファイルが既に存在する場合は、そのファイルを編集します。
次の行を追加し、<ip_address> を目的のインタフェースが対応するアドレスに置き換えます。
```
application_server.interface_address=<ip_address>
```
使用可能インタフェースすべてに明示的に結合するには (つまり、既定とするには)、次のように * を指定します。application_server.interface_address=*。

Microsoft Windows システムでの ISCAgent インタフェースのカスタマイズ

ISCAgent プロセスは使用可能なインタフェースすべての既定 (もしくは構成された) ポートに結合します。ISCAgent をカスタマイズして、Windows システムの特定のアドレスに対応するインタフェースへ結合するには、以下の手順を実行します。

<windir>\system32\iscagent.conf という名前のファイルを作成します。ファイルが既に存在する場合は、そのファイルを編集します。
次の行を追加し、<ip_address> を目的のインタフェースが対応するアドレスに置き換えます。
```
application_server.interface_address=<ip_address>
```
使用可能インタフェースすべてに明示的に結合するには (つまり、既定とするには)、次のように * を指定します。application_server.interface_address=*。

サービス品質 (QoS) タイムアウトの構成

[サービス品質タイムアウト] (QoS タイムアウト) は、フェイルオーバー・メンバとアービターの動作を管理する際に重要な役割を果たすものであり、ミリ秒単位の時間の範囲を定義します。ミラー・メンバは、この時間の範囲内で別のミラー・メンバからの応答を待機し、その範囲を超えると対応策を実行します。QoS タイムアウト自体は、最大待機時間を表します。最小待機時間は、その半分になります。QoS タイムアウトの値を大きくすると、ホストやネットワークが停止と見なされるまでの無応答時間の許容範囲が広くなります。QoS の値を小さくすると、ミラーは迅速に停止に対応できるようになります。具体的には、QoS タイムアウトは以下の状況に作用します。

バックアップ・フェイルオーバー・メンバが、プライマリからのデータに対して QoS タイムアウトで定義した範囲内に受信確認を行わないと、プライマリはバックアップとの接続を切断して、バックアップが停止したと見なしてアクションを取ります。
バックアップが、プライマリからのメッセージを QoS タイムアウトで定義した範囲内に受信できなかった場合、バックアップは接続を切断して、プライマリが停止したと見なしてアクションを取ります。
アービターが、フェイルオーバー・メンバからの応答を QoS タイムアウトで定義した範囲内に受信できなかった場合、アービターは、そのフェイルオーバー・メンバとの接続が失われていると見なします。
フェイルオーバー・メンバのホストで実行される処理により、QoS タイムアウトで定義した範囲内の期間、ホストが完全に無反応になると、不要なフェイルオーバーやアラートが発生することがあります。これは、バックアップや移行を伴う処理を実行する仮想化プラットフォームで特に問題になります。詳細は、"仮想環境でのミラーリング" を参照してください。

フェイルオーバー・メンバとアービターの動作に関して QoS タイムアウトが果たす役割についての完全な詳細は、"自動フェイルオーバーのメカニズム" を参照してください。

既定の QoS は 8 秒 (8000 ミリ秒) です。これは、一部のハードウェア構成で発生する数秒間の断続的な無応答状態を考慮に入れたものです。一般に、専用のローカル・ネットワークに接続された物理 (仮想化されていない) ホストへの配置では、停止に対するより迅速な対応が必要な場合に、この設定を短くすることができます。バージョン 2015.2 より前の Caché からアップグレードしたミラーは、以前のデフォルト値の 2000 ミリ秒が維持されている可能性があります。

[サービス品質タイムアウト] の設定は、[ミラーの作成] ページ、またはプライマリ・フェイルオーバー・メンバの [ミラーの作成] ページで調整できます。

Note:

QoS タイムアウトは、^MIRROR ルーチンの [ミラー構成] メニューにある [サービス品質タイムアウト・パラメータの調整] オプションを使用して調整することもできます ("^MIRROR ルーチンの使用法" を参照)。

並列デジャーナリングの構成

"ミラー同期" で説明したように、バックアップ・フェイルオーバー・メンバおよびミラーの非同期メンバのミラーリングされるデータベースは、デジャーナリングによってプライマリとの同期状態が維持されます。これは、プライマリで実行され、プライマリのジャーナル・ファイルに記録されるデータベース更新を他のメンバの対応するデータベースに適用する動作です。十分な処理能力があり、十分なメモリ・リソースを利用できる場合、1 回のデジャーナリング操作で最大 4 つのジョブが別々のデータベースの更新を並列で実行できます。この機能は、並列デジャーナリングと呼ばれ、特にデータベースの更新頻度が高いミラーのスループットを向上します。

並列デジャーナリングは、ホスト・システムに最低 8 個の CPU が搭載されていて、この目的に割り当て可能な一般メモリを関連する Caché インスタンスが十分に確保している場合にのみ使用します。実際には、並列デジャーナリングは、一般メモリを増やさない限り、ほとんどの Caché インスタンスでは使用されません。並列デジャーナリングのジョブ数は、一般メモリ・ヒープのサイズを 200 で除算した数を超過することはできません。例えば、同時に 4 つのデジャーナリング・ジョブが実行されているとすると、800 MB 以上の一般ヒープが必要になります。(並列デジャーナリングをサポートするにはメモリが不足している場合でも、一般メモリ・ヒープのサイズを既定値よりも増やすと、デジャーナリングのスループットが向上することがあります。)

Note:

一般メモリ・ヒープまたは gmheap (共有メモリ・ヒープまたは SMH とも呼びます) のサイズを変更するには、[メモリ詳細設定] ページ ([システム管理] > [構成] > [追加設定] > [詳細メモリ]) に移動します。詳細は、"Caché 追加構成設定リファレンス" の “Caché 追加構成設定” の章にある "詳細メモリ設定" を参照してください。

並列デジャーナリングはジャーナル・リストア中にも使用されます。詳細は、"Caché データ整合性ガイド" の “ジャーナリング” の章にある "^JRNRESTO を使用したジャーナル・ファイルからのグローバルのリストア" を参照してください。

並列デジャーナリングは、ミラーのフェイルオーバー・メンバでは常に有効になっています (使用可能なリソースによってサポートされている場合)。既定では、DR 非同期メンバでも有効になっています。レポート非同期についても有効にすることができます (つまり、すべてのメンバについて有効にできます)。また、フェイルオーバー・メンバのみに制限することもできます。そのためには、第 1 のフェイルオーバー・メンバを構成するときに [並列デジャーナリングを許可する] 設定を変更 ("ミラーを作成し、第 1 のフェイルオーバー・メンバを構成する" を参照)、またはプライマリでミラーを編集 ("フェイルオーバー・メンバの編集または削除" を参照) します。設定に関係なく、1 回の操作で複数のデータベースをキャッチアップするときに、並列デジャーナリングがサポートされている場合には、この操作が常に使用されます。"ミラーリングされるデータベースの有効化とキャッチアップ" を参照してください。

レポート非同期について並列デジャーナリングを有効にするとパフォーマンスの観点では有利ですが、複数のデータベースが関与するクエリまたはレポートで予期しない結果になる可能性が高まる場合があります。これは、個別のデジャーナリング・ジョブによって更新されるデータベースがデジャーナリング順序において若干異なる場所にある可能性があるためです。例えば、データベース B が 11:45:28 からの更新に対してのみ準備できているときに、データベース A に 11:45:30 にプライマリで実行される更新が含まれている場合です。ただし、並列デジャーナリングが原因の不確実性は、デジャーナリング処理において変化するデータに対してレポートまたはクエリを実行するときに常に発生する不確実性と同様です。したがって、インターシステムズは、並列デジャーナリングが有効になっている、ミラーリングされるデータベースを実行するほとんどのレポート・アプリケーションでは、その影響を無視できると考えています。単一のデータベースに対するすべての更新は単一のデジャーナリング・ジョブによって適用されるため、単一のデータベースに対する正しい更新順序が保証されることを覚えておくことも重要です。

^ZMIRROR ルーチンの使用法

ユーザ定義の ^ZMIRROR ルーチンにより、特定のミラーリング・イベント用の (プライマリ化するフェイルオーバー・メンバなど)、独自のカスタムで構成固有のロジックおよびメカニズムを実装できます。

^ZMIRROR ルーチンには、次のエントリ・ポイントが含まれています。値を省略した場合、これらすべては、適切な既定値が指定されます。

$$CanNodeStartToBecomePrimary^ZMIRROR() — インスタンスで以下のことと判断された場合、このプロシージャが呼び出されます。
- 他方のフェイルオーバー・メンバが現在プライマリとして動作しておらず、手動操作なしではプライマリになれない。
- ローカル・メンバはプライマリになることが可能で、引き継ぎのプロセスを開始しようとしている。
CanNodeStartToBecomePrimary は、起動時またはバックアップとしての接続時のいずれかに、フェイルオーバー・メンバが自動的にプライマリになることをブロックするロジックのエントリ・ポイントを提供し、フェイルオーバーを手動制御できるようにします。これはほとんどの ^ZMIRROR ルーチンには組み込まれていません。
CanNodeStartToBecomePrimary が 1 を返すと、ローカル・インスタンスがプライマリ・フェイルオーバー・メンバとして完全初期化され、プライマリになるプロセスを続行できます。つまり、ミラーリングされるデータベースすべてが読み書き可能となり、ECP セッションが回復またはロールバックされていて、以前のプライマリからのローカル・トランザクション (存在する場合) がロールバックされています。ユーザのログインは許可されておらず、スーパーサーバ接続は阻止され、かつ ECP が復旧途中にあるので、新規の処理は実行されていません。
このエントリ・ポイントが 0 (False) を返す場合、インスタンスは再試行ループに入り、CanNodeStartToBecomePrimary の呼び出しを 30 秒ごとに、以下のことが生じるまで続けます。
- CanNodeStartToBecomePrimary が 1 (True) を返し、ローカル・メンバがプライマリになるプロセスを続行する。
- インスタンスで、他方のフェイルオーバー・メンバがプライマリになったこと (手動操作による必要があります) が検出され、この時点でローカル・メンバがバックアップになる。
$$CheckBecomePrimaryOK^ZMIRROR() — このプロシージャは CanNodeStartToBecomePrimary が 1 (True) を返した後に呼び出されます。
CheckBecomePrimaryOK が存在し、1 を返すと、ミラーはローカル・メンバをプライマリとして動作を再開します。この時点で、任意のローカル・プロセスを開始でき、またユーザのアプリケーション環境を整えるために必要な初期化ができます。ただし、CheckBecomePrimaryOK を実行するプロセスのみが、1 を返した後に、ミラーリングされるデータベースに実際に書き込み、その時点でミラーリングされるデータベースが一般の使用のために更新されることに注意してください。
CanNodeStartToBecomePrimary と同様に、CheckBecomePrimaryOK が 0 (False) を返すと、インスタンスはプライマリになるプロセスを中止して、CheckBecomePrimaryOK の呼び出しを 30 秒ごとに、以下のことが生じるまで再試行します。
- エントリ・ポイントが 1 を返し、ミラーがローカル・メンバをプライマリとして動作を再開する。
- インスタンスで、他方のフェイルオーバー・メンバがプライマリになったこと (手動操作による必要があります) が検出され、この時点でローカル・メンバがバックアップになる。
通常、CheckBecomePrimaryOK は正常に実行されます。ノードがプライマリ・メンバにならない “事例がよく起こる” 場合は、CheckBecomePrimaryOK ではなく、CanNodeStartToBecomePrimary を使用して処理する必要があります。
コードを、プライマリの既存の ^ZSTU または ^%ZSTART ルーチンから ^ZMIRROR に移動することで、ミラーが初期化されるまで実行されないようにする場合、CheckBecomePrimaryOK が最適な位置となります。ただし、job コマンドを使用してその他のジョブを開始する場合、そのジョブは $SYSTEM.Mirror.IsPrimary() が true を返すまで待機します。これは CheckBecomePrimaryOK が 1 を返した後に行われます。または、代わりに $$NotifyBecomePrimary^ZMIRROR() でジョブを開始できます。

Note:

CheckBecomePrimaryOK が False を返す場合、ECP セッションはリセットされます。ノードのプライマリ化が成功すると、ECP クライアントは再接続され、ECP トランザクションが (保持ではなく) ロールバックされます。クライアント・ジョブは、TRollback コマンドが明示的に実行されるまで、<NETWORK> エラーを受信します ("Caché 分散データ管理ガイド" の付録 “ECP リカバリ保証と制限” で、"ECP Rollback Only の保証" のセクションを参照してください)。
$$NotifyBecomePrimary^ZMIRROR() — このプロシージャは、プライマリ・フェイルオーバー・メンバになるプロセスの最後に情報提供を目的として呼び出されます (つまり、ユーザが許可された後、かつ ECP セッションが (存在する場合) アクティブになった後)。このエントリ・ポイントは値を返しません。コードを組み込むことにより、必要に応じた通知の生成やアプリケーション・ログインの有効化ができます。
$$NotifyBecomePrimaryFailed^ZMIRROR() — このプロシージャは、以下の場合に情報提供を目的として呼び出されます。
- フェイルオーバー・メンバが起動したが、プライマリまたはバックアップ・メンバになれなかった。
- バックアップがプライマリの失敗を検出し、バックアップがプライマリになろうとしたが、なれなかった。
このエントリ・ポイントは、各問題の発生に対して 1 回だけ呼び出されます。メンバがプライマリになるか、プライマリが検出されるまで再度呼び出されることはありません。

ミラーへのシャドウの変換

ミラーリングでは、シャドウのソースと宛先、およびそれらの間でマップされシャドウイングされるデータベースを、プライマリ・フェイルオーバー・メンバ、バックアップ・フェイルオーバー・メンバか非同期メンバ、およびミラーリングされるデータベースが含まれるミラーに変換できるようにするユーティリティが提供されます。シャドウに宛先が複数ある場合、それらのすべてをミラー・メンバに変換できます。シャドウイング設定をミラーに変換するには、次の手順に従います。

"ミラーを作成し、第 1 のフェイルオーバー・メンバを構成する" の説明に従って、ミラーを作成し、シャドウ・ソースの Caché インスタンスをプライマリ・フェイルオーバー・メンバにします。
宛先シャドウの Caché インスタンスを、"第 2 のフェイルオーバー・メンバを構成する" の説明に従ってバックアップ・フェイルオーバー・メンバとして、または "非同期ミラー・メンバを構成する" の説明に従って非同期メンバとして、ミラーに追加します。
"ミラーへ既存データベースを追加する" の説明に従って、プライマリ・フェイルオーバー・メンバ (シャドウ・ソース) で、シャドウイングされるデータベースをミラーに追加します。
ミラーリングされるデータベースをプライマリでバックアップし、シャドウイングを停止して、ミラーリングされるデータベースをバックアップ/非同期でリストアします。バックアップとリストアの操作は、"ミラーへ既存データベースを追加する" の説明に従って実行します。

必要に応じて、前述の手順の最後のステップを以下のステップに置き換えることができます。

バックアップまたは非同期 (シャドウ宛先) がキャッチアップできるようにします。これによって、そのシャドウのチェックポイントが少なくとも最初のミラー・ジャーナル・ファイルのポイントになり、ミラー以外のジャーナル・ファイルで開始したオープン・トランザクションをシャドウが追跡しないようになります。
シャドウイングを停止します。
バックアップまたは非同期 (シャドウ宛先) で、Caché ターミナルを開き、zn "%SYS" と入力して、%SYS ネームスペースに切り替えて、ConvertShadowDatabases^MIRROR と入力します。このユーティリティは、以下のように動作します。
1. ミラーの名前とシャドウの名前の入力を求めます (両方のプロンプトとも、インスタンスが 1 つにのみ属している場合、入力は必要ありません)。
2. 変換するデータベースとそれらのミラー・データベース名のリストの入力を求めます。
3. 指定されたデータベースを、指定されたミラー内のミラーリングされるデータベースに変換します。
4. 変換されたデータベースを有効化してキャッチアップするよう求めます ("ミラーリングされるデータベースの有効化とキャッチアップ" を参照)。
5. 変換されたデータベースをシャドウから削除するよう求めます。

ミラーリングの管理

このセクションでは、Caché のミラーについて、運用上の管理と維持に関連するトピックについて説明します。

ミラーの監視

以下の 2 つの方法のいずれかを使用して、既存のミラーの動作を監視できます。

管理ポータルの [ミラー・モニタ] ページ
^MIRROR ルーチンの [ステータス・モニタ] オプション

どちらの方法でも、ミラーおよびそのメンバの動作状態、受信ジャーナルの転送速度、およびミラーリングされるデータベースの状態に関する情報が表示されます。また、ミラー・モニタでは、ミラーリングされるデータベースに対して複数の処理を実行できます。

"ミラーリング通信プロセスの監視" で、ミラー・メンバ上で実行されるミラー通信プロセスについて説明します。

Note:

管理ポータル・ホーム・ページのメッセージ・ペインには、ミラー・モニタへのリンクを含め、基本的なミラー・メンバの情報も表示されます ("Caché システム管理ガイド" の “管理ポータルの使用” の章の "管理ポータルのメッセージ・ペイン" を参照)。

データベースのマウントとディスマウントやミラーに対するデータベースの追加と削除など、データベースおよびミラーに関連する多くの操作は、コンソール・ログに記録されます ("Caché 監視ガイド" の “管理ポータルを使用した Caché の監視” の章の "ログ・ファイルの監視" を参照)。

ミラー・モニタの使用法

ミラー・モニタを表示するには、ミラー・メンバでシステム, ミラー・モニタページに移動します。

フェイルオーバー・メンバでは、ミラー・モニタに以下のボタンとセクションが含まれています。

[ミラー・ジャーナル・ファイルの表示] ボタンは、メンバのミラー・ジャーナル・ファイルまたは非ミラー・ジャーナル・ファイルを表示および検索します。詳細は、"Caché データ整合性ガイド" の “ジャーナリング” の章の "ジャーナル・ファイルの表示" を参照してください。
[このメンバのミラーリングを停止] ボタン (バックアップのみ) は、"バックアップおよび非同期メンバのミラーリングの停止" で説明されているとおり、バックアップのミラーリングを一時的に停止します。
バックアップを DR 非同期に降格させ、ミラーに 1 つのフェイルオーバー・メンバを残すための 2 つのボタンのうちの 1 つ。詳細は、"バックアップの DR 非同期への降格" を参照してください。
[ミラー・フェイルオーバー・メンバ情報] には、各フェイルオーバー・メンバのメンバ名、スーパーサーバ・アドレス、およびミラー・プライベート・アドレスが表示されます (これらのアドレスの詳細は、"ミラー・メンバのネットワーク・アドレス" を参照してください)。
[アービター接続ステータス] には、アービターが構成されている場合にそのアドレス (ホスト名とポート)、現在のフェイルオーバー・モード、およびメンバのアービター接続のステータスが次のように表示されます。
- [両方のフェイルオーバー・メンバがアービターに接続されている]
- [このメンバのみがアービターに接続されている]
- [このメンバはアービターに接続されていない] (接続が失われているか、アービターが構成されていない場合)
アービターおよびこの接続情報の意味に関する詳細は、"自動フェイルオーバーのメカニズム" を参照してください。

Note:

フェイルオーバー・メンバがアービターとの通信を失うと、深刻度 2 のメッセージがコンソール・ログに送信されます。そのメンバがアービターとの接続の再構築に失敗すると、別の深刻度 2 のメッセージがログに記録されます。
[ミラー・メンバ・ステータス] には、"ミラー・メンバのジャーナル転送およびデジャーナリングのステータス" で説明しているように、各ミラー・メンバのメンバ・タイプとステータス、ジャーナル転送ステータス、およびデジャーナリング・ステータスが表示されます。このテーブルには、メンバの X.509 DN が構成されている場合はそれも表示されます。
[ミラーリングされるデータベース] には、"ミラーリングされるデータベースのステータス" で説明しているように、現在のメンバ上のミラーリングされるデータベースそれぞれに関する情報が、その名前、ディレクトリ、ステータス、およびデジャーナリング・ステータスも含めて表示されます。[ミラーリングされるデータベース] を使用して、1 つ以上のデータベースに対して複数の処理を実行することもできます。

Note:

[ミラーリングされるデータベース] リストには、現在のメンバのミラーに含まれているデータベースのみが挙げられます。例えば、異なるレポート非同期メンバでリストされるデータベースは異なる場合があります。ミラーリングされるデータベースのセットが異なる場合があるからです。

非同期メンバでは、ミラー・モニタには、以下のボタンとセクションが含まれています。

[ジャーナル・ファイルの表示] ボタン (DR 非同期のみ) は、メンバのミラー・ジャーナル・ファイルまたは非ミラー・ジャーナル・ファイルを表示および検索します。詳細は、"Caché データ整合性ガイド" の “ジャーナリング” の章の "ジャーナル・ファイルの表示" を参照してください。
[このメンバのミラーリングを停止] ボタン (DR 非同期のみ) は、"バックアップおよび非同期メンバのミラーリングの停止" で説明されているとおり、非同期のミラーリングを一時的に停止します。
[フェイルオーバー・メンバに昇格] ボタン (DR 非同期のみ) は、DR 非同期をフェイルオーバー・メンバに昇格します。この操作とその使用法については、"DR 非同期メンバのフェイルオーバー・メンバへの昇格" を参照してください。
ボタンの下部のセクションには、メンバのメンバ名、非同期タイプ、および X.509 DN (構成されている場合) が表示されます。
[この非同期メンバの所属先のミラー] には、"ミラー・メンバのジャーナル転送およびデジャーナリングのステータス" で説明しているように、レポート非同期メンバの所属先の各ミラーに関する情報、およびそのミラー内でのメンバのステータス、ジャーナル転送ステータス、およびデジャーナリング・ステータスが表示されます。各行には、そのミラーのメンバに関する情報を表示する [詳細] リンクと、そのミラーの非同期メンバによるミラーリングを停止させる [このメンバのミラーリングを停止] リンクが含まれています。詳細は、"バックアップおよび非同期メンバのミラーリングの停止" を参照してください。
[ミラー・メンバ・ステータス] には、現在の非同期メンバを含めて、[この非同期メンバの所属先のミラー] で選択したミラーのすべてのメンバのタイプ、ステータス、ジャーナル転送遅延、およびデジャーナル遅延が表示されます。
非同期メンバが単一ミラーに属している場合 (すべての DR 非同期に当てはまります)、既定でそのミラーがこのセクションに表示されます。メンバが複数のミラーに属している場合、このセクションおよびその下の [ミラーデータベース] MIRROR セクションは、[この非同期メンバの所属先のミラー] セクションに示されるいずれかのミラーの [詳細] リンクをクリックするまで表示されません。
[ミラーデータベース] MIRROR セクションは、フェイルオーバー・メンバの場合の説明と同様で、また同じ処理を実行できます。レポート非同期の場合は、[この非同期メンバの所属先のミラー] で選択し [ミラー・メンバ・ステータス] に表示されるミラーに含まれるデータベースが表示されます。

ミラー・メンバのジャーナル転送およびデジャーナリングのステータス

"ミラーの監視" で説明しているように、Caché インスタンスがミラーに属している場合、そのメンバ・タイプとステータス、ジャーナル転送ステータス、およびデジャーナリング・ステータスは、ミラー・モニタおよび ^MIRROR ルーチンの [ステータス・モニタ] オプションによって表示されます。

次のテーブルは、表示される可能性のあるタイプおよびステータスを示しています。

タイプ	ステータス	説明
フェイルオーバー	プライマリ	現在のプライマリ。
	バックアップ	バックアップとしてプライマリに接続
	障害中	バックアップとの接続が切断されたために、プライマリが障害になった状態。プライマリが一時的または永久的な障害状態になりうるさまざまな状況の詳細は、"自動フェイルオーバーのメカニズム" を参照してください。
災害復旧	Connected	非同期としてプライマリに接続
読み取り専用レポート
読み書き可能のレポート
(上記のいずれか)	移行	初期化やその他の操作が完了したときの、その後すぐに変わる遷移状態。この状態では、メンバの状態を検索するプロセスがすぐに再検索を実行します。動作中のプライマリがない場合、フェイルオーバー・メンバはこの状態を長時間レポートできますが、プライマリになる途中でジャーナル・ファイルを取得し、適用します。プライマリである別のフェイルオーバー・メンバがある場合、ステータスは代わりに同期になります。
	同期	停止または切断された後の起動または再接続。バックアップになるまたは接続される前に、データベースをジャーナルの状態と同期させるために、ジャーナル・ファイルを取得し、適用します。
	待機中	プライマリになるまたはプライマリに接続するなどのアクションを完了できない状態。無限に再試行されますが、ユーザの介入が必要な場合があります。詳細は、コンソール・ログを参照してください。
	停止	ユーザにより、メンバのミラーリングが無期限に停止され、自動的には開始されません。詳細は、コンソール・ログを参照してください。
	クラッシュ	不測の事態によりミラー実行不可。詳細は、コンソール・ログを参照してください。
	Error	メンバのステータスをフェッチ中に予期しないエラーが発生しました。
	ダウン	他のメンバに表示された、ダウンしたまたはアクセスできないメンバ。
不確定	初期化されていない	メンバが初期化されていません (ミラー構成がまだロードされていません)。

Note:

バージョン 2013.1 よりも前の Caché を実行しているミラー・メンバの場合、[タイプ] フィールドと [ステータス] フィールドに、異なる値が表示されます。

ミラー・メンバの [タイプ] と [ステータス] は、%SYSTEM.Mirror.GetMemberType()Opens in a new tab メソッドおよび %SYSTEM.Mirror.GetMemberStatus()Opens in a new tab メソッドを使用して取得することもできます。上記にリストされていない [タイプ] と [ステータス] の一部の組み合わせは、以下の呼び出しによって報告されます。

[メンバではない] および [初期化されていない] — インスタンスがミラー・メンバ以外として構成されています。
[読み取り専用] または [読み取り/書き込みレポート] および M/N [ステータス] — インスタンスがいくつかのミラーの非同期メンバです。mirrorname 引数を指定して特定のミラーの [ステータス] を取得してください。

バックアップおよび非同期ミラー・メンバの場合、[ジャーナル転送] は、プライマリからの最新ジャーナル・データがミラー・メンバにあるかどうかを示します。データがない場合、ジャーナル転送の遅延の度合いを示します。一方、[デジャーナリング] は、プライマリから受信したジャーナル・データがすべてデジャーナル (そのメンバのミラーリングされるデータベースに適用) されているかどうかを示します。デジャーナルされていない場合、デジャーナリングの遅延の度合いを示します。以下のテーブルは、ミラー・モニタと＾MIRROR で表示される可能性のある、これらのフィールドのステータスを示しています(プライマリの場合、これらのフィールドは常に [N/A] です)。

ジャーナル転送	説明
アクティブ (バックアップのみ)	バックアップは、プライマリから最新のジャーナル・データを受信しており、プライマリと同期されています。([アクティブ] バックアップ・ステータスに関する詳細は、"バックアップ・ステータスと自動フェイルオーバー" を参照してください。)[デジャーナリング] ステータスが [キャッチアップ済み] でない場合でも、バックアップは [アクティブ] になることがあります。必要なジャーナル・ファイルをバックアップがすべて有している限り、プライマリとの接続を失った後でもデジャーナルできます。
キャッチアップ済み	バックアップの場合、バックアップは最新のジャーナル・データをプライマリから受信していますが、プライマリがジャーナル・データの受信確認を待機していないという点で完全には同期されていないことを意味します。多くの場合、このステータスは、バックアップがミラーに再接続しているときなど、一時的なものです。非同期の場合は、プライマリから最新のジャーナル・データを受信していて、プライマリと同期されていることを意味します。
time 遅延	メンバは明示されている時間だけプライマリから遅延しています。time は、メンバが最後に受信したジャーナル・ブロックのタイムスタンプから現在の時刻までに経過した時間を表します。


time に切断	メンバは、明示されている時刻にプライマリから切断されました。

記載のとおり、[ジャーナル転送] フィールドの [アクティブ] は、バックアップがプライマリからジャーナル・データをすべて受信しており、プライマリと同期されていることを示しています。このため、バックアップは、フェイルオーバーの発生時に、追加ジャーナル・データを取得するためにプライマリの ISCAgent と通信する必要なく、プライマリから引き継ぐことができます。

デジャーナリング	説明
キャッチアップ済み	プライマリから受信したジャーナル・データすべてがデジャーナルされています (メンバのミラーリングされるデータベースに適用されています)。
time 遅延	プライマリから受信したジャーナル・データの一部がまだデジャーナルされていません。time は、最後にデジャーナルされたジャーナル・ブロックのタイムスタンプと、プライマリから最後に受信したジャーナル・ブロックのタイムスタンプとの間で経過した時間を表します。


time に切断	メンバは、明示されている時刻にプライマリから切断されました。
警告 : データベースの一部に対処が必要です。	1 つ以上のミラーリングされるデータベースが正常な状態ではありません。データベースを確認する必要があります。
警告 : デジャーナリングが停止しました。	オペレータまたはエラーの発生によりデジャーナリングが停止しています。"データベース・デジャーナリングの管理" を参照してください。

[アクティブ] なバックアップ・フェイルオーバー・メンバの場合の [デジャーナリング] フィールドの [キャッチアップ済み]、および非同期メンバの場合の [デジャーナリング] フィールドと [ジャーナル転送] フィールドの [キャッチアップ済み] は、そのメンバがプライマリから最新のジャーナル・データを受信して、そのデータに含まれる最新のグローバル処理を適用したことを表します。そのメンバがキャッチアップされていない場合、最新ジャーナル・データが生成された時点からの経過時間または最新処理をプライマリで記述した時点からの経過時間が代わりに表示されます。

受信ジャーナルの転送速度

以下に示すバックアップおよび非同期のミラー・メンバのステータス・リストは、プライマリから到着したジャーナル・データの速度です。この速度は、[ミラー・モニタ] の前回の更新以降のもので、[このメンバの受信ジャーナルの転送速度] の下に表示されます。

[ミラー・モニタ] ページを最初にロードしたときには、この領域に [--- (更新時に表示)] というテキストが表示されます。次に手動または自動でページが更新されたとき (自動更新は、ページの上部で [オン] に設定されています)、表示される情報は受信ジャーナル・データが圧縮されているかどうかによって異なります ("ジャーナル・データの圧縮" を参照)。以下に例を示します。

ジャーナル・データが圧縮されていない場合、受信ジャーナル・データの速度は、キロバイト (KB) 毎秒で示されます。以下に例を示します。
42345 KB/s (22s 間隔)
受信ジャーナル・データが圧縮されている場合は、受信圧縮データの速度、受信ジャーナル (非圧縮) データの速度、および圧縮データ速度に対する非圧縮データ速度の比率が表示に含まれます。以下に例を示します。
14288 KB/s ネットワーク; 39687 KB/s ジャーナル; 比率 2.78:1 (143s 間隔)

ミラーリングされるデータベースのステータス

Important:

バックアップおよび DR 非同期メンバの場合は、[ミラー・モニタ] ページの [見つからないミラーリングされるデータベースのレポート] に、プライマリに存在していても、現在のメンバには存在していないミラーリングされるデータベースについての警告が表示されます。これは、バックアップとして非常に重要なことです。DR 非同期がバックアップに昇格したときに、ミラーリングされるデータベースの完全なセットが揃っていないと、プライマリが停止したときに、その役割を正常に引き継ぐことができなくなります。見つからないデータベースごとに、完全なミラー・データベース名がリストされます。見つからないデータベースが存在しない場合、[見つからないミラーリングされるデータベースのレポート] は表示されません。

すべてのメンバに関して、[ミラー・モニタ] ページの [ミラーリングされるデータベース] リストには、リストされている各データベースについて、次のいずれかのステータスが表示されます。

ステータス	説明
正常 (プライマリのみ)	ミラーリングされるデータベースは書き込み可能 (読み取り専用データベースではない場合) で、グローバル更新がジャーナルされています。
デジャーナリング (バックアップおよび非同期)	データベースはアクティブ化され、キャッチアップされており、ミラーがデータベースにジャーナル・データを適用しています。
要キャッチアップ	データベースはアクティブ化されていますが、まだキャッチアップされていません。ユーザ開始のキャッチアップ操作が必要です。
要有効化	データベースはまだアクティブ化されていません。ユーザ開始のアクティブ化操作とキャッチアップ操作が必要です。
キャッチアップ実行中	データベースでユーザ開始のキャッチアップ操作が実行されています。
デジャーナリング停止	オペレータまたはエラーによってデジャーナリングが停止されています。"バックアップおよび非同期メンバのミラーリングの停止" および "データベース・デジャーナリングの管理" を参照してください。
データベース・ディスマウント	データベースがディスマウントされています。
独立 (バックアップおよび非同期)	ミラーリングされるデータベースがプライマリに存在しません。
廃止	ミラーリングされるデータベースは廃止されているため、ミラーから削除する必要があります。

プライマリでは、データベースのステータスが [正常] の場合、[次にデジャーナルするレコード] 列には、[N/A] が表示されます。それ以外の場合、この列には以下の情報が表示されます。

[時刻] は、データベースに適用される次のジャーナル・レコードの先頭のタイムスタンプです。または、これがプライマリの現在のジャーナル位置に一致する場合は [現在] と表示されます。
[ファイル名] は、次に適用されるジャーナル・レコードが含まれるミラー・ジャーナル・ファイルの名前です。
[オフセット] は、次に適用されるジャーナル・レコードの先頭の、ジャーナル・ファイル内における位置です。

データベースのステータスおよびそれに関連する操作 (有効化およびキャッチアップ) については、"ミラーリングされるデータベースの有効化とキャッチアップ" で説明しています。これらの操作は、リストの下にあるドロップダウンで選択できます。このドロップダウンを使用して、ディスマウントされているデータベースをマウントできます (ただし、マウントされているデータベースのディスマウントには使用できません)。[削除] リンクを使用して、またはドロップダウンから [削除] を選択して、リストされているデータベースをミラーから削除することができます。詳細は、"ミラーリングされるデータベースをミラーから削除する" を参照してください。

^MIRROR ステータス・モニタの使用法

^MIRROR ルーチンには、文字ベースのステータス・モニタが用意されています。^MIRROR の [ステータス・モニタ] オプションでは、タイプ、ステータス、ジャーナル転送遅延、およびデジャーナル遅延を含む、ミラー・メンバのステータスを表示できます ("ミラー・メンバのジャーナル転送およびデジャーナリングのステータス" を参照)。このモニタは任意のミラー・メンバで実行できます。ただし、これをフェイルオーバー・メンバで実行すると、アービター構成に関する情報およびすべての接続非同期メンバに関する情報が表示されますが、これらの情報は、非同期メンバで実行する場合には表示されません。

このステータス・モニタを起動するには、ターミナル・ウィンドウを開き、%SYS ネームスペースで ^MIRROR ルーチンを実行し ("^MIRROR ルーチンの使用法" を参照)、[ミラー・ステータス] メニューから [ステータス・モニタ] を選択します。フェイルオーバー・メンバで実行した場合のモニタからの出力のサンプルを以下に示します。

Status of Mirror MIR25FEB at 17:17:53 on 02/27/2014

Member Name+Type            Status     Journal Transfer  Dejournaling
--------------------------  ---------  ----------------  --------------
MIR25FEB_A
     Failover               Primary    N/A               N/A
MIR25FEB_B
     Failover               Backup     Active            Caught up
MIR25FEB_C
     Disaster Recovery      Connected  Caught up         Caught up
MIR25FEB_D
     Read-Only Reporting    Connected  Caught up         Caught up

Arbiter Connection Status: 
     Arbiter Address: 127.0.0.1|2188 
     Failover Mode: Arbiter Controlled 
     Connection Status: Both failover members are connected to the arbiter 

Press RETURN to refresh, D to toggle database display, Q to quit,
 or specify new refresh interval <60>

非同期メンバでステータス・モニタを実行すると、フェイルオーバー・メンバおよび対象の非同期メンバのみがリストされ、非同期メンバのデジャーナリング・ステータス (running または stopped) も表示されます。以下に例を示します。

Status of Mirror MIR25FEB at 17:17:53 on 02/27/2014

Member Name+Type            Status     Journal Transfer  Dejournaling
--------------------------  ---------  ----------------  --------------
MIR25FEB_A
     Failover               Primary    N/A               N/A
MIR25FEB_B
     Failover               Backup     Active            Caught up
MIR25FEB_C
     Disaster Recovery      Connected  Caught up         Caught up
 Dejournal Status: running (process id: 12256)

Press RETURN to refresh, D to toggle database display, Q to quit,
 or specify new refresh interval <60>

既定では、ミラーリングされるデータベースの情報は表示されません。"ミラー・モニタの使用法" で説明しているように、プロンプトで d を入力すると、名前、ディレクトリ、ステータス、および次にデジャーナルされるレコードを含め、ミラー内の各データベースに関する情報が表示されます。

Mirror Databases:
                                                                   Last Record
Name           Directory path                          Status      Dejournaled
-------------  -----------------------------------     ----------- -----------
MIR25FEB_DB1   C:\InterSystems\20142209FEB25A\Mgr\MIR25FEB_DB1\
                                                       Active
   Current,c:\intersystems\20142209feb25a\mgr\journal\MIRROR-MIR25FEB-20140227.001,40233316
MIR25FEB_DB2   C:\InterSystems\20142209FEB25A\Mgr\MIR25FEB_DB2\
                                                       Active
   Current,c:\intersystems\20142209feb25a\mgr\journal\MIRROR-MIR25FEB-20140227.001,40233316

ミラーリング通信プロセスの監視

ミラー通信および同期化を行う各システム (プライマリ・フェイルオーバー・メンバおよびバックアップ・フェイルオーバー・メンバと、接続されている各非同期メンバ) 上で実行されるプロセスがあります。

詳細は、次のトピックを参照してください。

プライマリ・フェイルオーバー・メンバ上でのミラーリング・プロセス

プライマリ・フェイルオーバー・メンバ上でシステム・ステータス・ルーチン (^%SS) を実行すると、次の表にリストされたプロセスが表示されます。

Note:

ここでは、CPU、Glob、および Pr の各列を ^%SS の出力から意図的に省略しています。

プライマリ・フェイルオーバー・メンバ上でのミラーリング・プロセス

デバイス	ネームスペース	ルーチン	ユーザおよび場所
/dev/null	%SYS	MIRRORMGR	Mirror Master
MDB2	%SYS	MIRRORCOMM	Mirror Primary*
192.168.1.1	%SYS	MIRRORCOMM	Mirror Svr:Rd*

プロセスは次のように定義されます。

Mirror Master ：システム起動時に開始されるこのプロセスでは、さまざまなミラー制御タスクおよび管理タスクが実行されます。
Mirror Primary ：これは、発信データ・チャンネルであり、単方向チャンネルです。接続されているシステム (バックアップ・フェイルオーバー・メンバまたは非同期メンバ) ごとに 1 つのジョブがあります。
Mirror Svr:Rd* ：これは、受信応答チャンネルで、単方向チャンネルです。接続されているシステム (バックアップ・フェイルオーバー・メンバまたは非同期メンバ) ごとに 1 つのジョブがあります。

接続されている各非同期メンバは、プライマリ・フェイルオーバー・メンバにおいて、Mirror Master、Mirror Primary、および Mirror Svr:Rd* の各プロセスの新しいセットになります。

バックアップ・フェイルオーバー・メンバおよび非同期メンバ上でのミラーリング・プロセス

バックアップ・フェイルオーバー/非同期メンバ上でシステム・ステータス・ルーチン (^%SS) を実行すると、次の表にリストされたプロセスが表示されます。

バックアップ・フェイルオーバー・メンバおよび非同期メンバ上でのミラーリング・プロセス

デバイス	ネームスペース	ルーチン	ユーザおよび場所
/dev/null	%SYS	MIRRORMGR	Mirror Master
/dev/null	%SYS	MIRRORMGR	Mirror Dejour
/dev/null	%SYS	MIRRORMGR	Mirror Prefet*
/dev/null	%SYS	MIRRORMGR	Mirror Prefet*
MDB1	%SYS	MIRRORMGR	Mirror Backup
/dev/null	%SYS	MIRRORMGR	Mirror JrnRead

この表で識別されるプロセスは、接続された各非同期メンバでも表示されます。

Mirror Master ：システム起動時に開始されるこのプロセスでは、さまざまなミラー制御タスクおよび管理タスクが実行されます。
Mirror JrnRead (ミラー・ジャーナル読み取り) ：このプロセスは、バックアップで生成されメモリに書き込まれたジャーナル・データを読み取り、それらの変更をデジャーナル・ジョブによってデジャーナルするためにキューイングします。
Mirror Dejour (ミラー・デジャーナル) ：これは、バックアップ・フェイルオーバー・メンバでのデジャーナル・ジョブであり、受信したジャーナル・データからミラーリングされるデータベースに set および kill を発行します。
Mirror Prefet* (ミラー事前フェッチ) ：これらのプロセスは、デジャーナル・ジョブが実際にディスク・ブロックを使用しようとする前に、デジャーナル・ジョブで必要なディスク・ブロックをメモリに事前フェッチします。これは、デジャーナル・プロセスを高速化するために実行されます。通常、システムには複数のミラー事前フェッチ・ジョブが構成されます。Mirror Backup (ミラー・バックアップ) ：このプロセスは、プライマリから受信したジャーナル・レコードをバックアップのミラー・ジャーナル・ファイルに書き込み、応答をプライマリに送信する双方向チャンネルとなります。

ミラー・メンバのネットワーク・アドレスの更新

1 つ以上のミラー・メンバ (プライマリを含む) の 1 つ以上のネットワーク・アドレスを更新する必要がある場合 ("フェイルオーバー・メンバの編集または削除" を参照)、この情報は、一般にプライマリで変更されます。変更を保存すると、プライマリは接続されているすべてのミラー・メンバに、その変更を伝播します (接続されていないメンバには、再接続されたときに変更を伝播します)。接続されているバックアップまたは非同期メンバでは、いずれのミラー・メンバのネットワーク・アドレスも変更できません。ミラー・メンバは、このような情報をすべてプライマリから受信する必要があるためです。この一般的なケースには、以下に示すように、いくつかの例外があります。

Caché インスタンスのスーパーサーバ・ポートは、汎用構成の一部であるため、ローカルに変更する必要があります。そのため、ミラー・メンバのスーパーサーバ・ポートは、常にメンバ自体で更新されるミラー・ネットワーク情報になります。プライマリのスーパーサーバ・ポートを変更する場合はプライマリの [ミラーの編集] ページに移動して、バックアップの場合はバックアップの [ミラーの編集] ページに移動します。その他についても同様にします。

Note:

[ネットワーク・アドレスの編集] ダイアログで、ローカル・メンバのスーパーサーバ・ポートに対応する [ポートの編集] リンクをクリックすると、管理ポータルの [メモリと開始設定] ページが含まれているダイアログが表示され、ポート番号を変更できます。ただし、ミラー・メンバのスーパーサーバ・ポートを変更するために、このページに直接移動しないでください。[ミラーの編集] ページまたは [非同期構成の編集] ページと [ネットワーク・アドレスの編集] ダイアログを必ず使用して、この変更を実施してください。
フェイルオーバー・メンバまたは非同期メンバが切断されているときに、プライマリのネットワーク・アドレスが変更された場合、まず、すべてのミラーのネットワーク・アドレスが現在のプライマリ上で正しいことを確認してから、切断されているメンバでプライマリのネットワーク・アドレスを更新する必要があります ("フェイルオーバー・メンバの編集または削除" または "非同期メンバの編集または削除" を参照)。プライマリのネットワーク情報の更新後に、メンバがミラーに再接続できるようにするために、切断されているそのメンバの再起動が必要な場合があります。
どちらのフェイルオーバー・メンバもプライマリとしては動作していないなどの場合に、いずれかのフェイルオーバー・メンバがプライマリになれるようにするために、そのフェイルオーバー・メンバ上でネットワーク・アドレスを更新する必要があることがあります。プライマリになると、接続時に他のメンバにこれらのアドレスが伝播されます。ネットワーク・アドレスの更新後に、メンバがプライマリになれるようにするために、そのメンバの再起動が必要な場合があります。

Note:

"非同期ミラー・メンバを構成する" で説明しているように、非同期メンバをミラーに追加するときに指定する [非同期メンバ・アドレス] が、その非同期のスーパーサーバ・アドレスおよびミラー・プライベート・アドレスになります ("ミラー・メンバのネットワーク・アドレス" を参照)。例えば、DR 非同期のミラー・プライベート・アドレスをミラー・プライベート・ネットワークに配置し、そのスーパーサーバ・アドレスは外部ネットワークに置いたままにするなど、ここで説明しているように、ミラーに非同期を追加した後で、その非同期のアドレスを変更できます。

X.509 DN 更新の承認 (SSL/TLS のみ)

SSL/TLS を使用するようにミラーを構成する場合は、新しく追加した第 2 のフェイルオーバー・メンバと、第 1 フェイルオーバー・メンバの新しい各非同期メンバをミラーに参加させるには、まずそれらを承認する必要があります ("第 2 のフェイルオーバー・メンバまたは非同期メンバを承認する (SSL/TLS のみ)" を参照)。同様の理由から、SSL/TLS を使用するミラーのメンバーを X.509 証明書と DN で更新する場合、この更新は、以下のいずれかの方法で、他のメンバに伝達され、承認される必要があります。

プライマリの X.509 DN 更新は、更新が行われた時点で、プライマリに接続された他のミラー・メンバに自動的に伝達され、承認されます。
プライマリの X.509 DN 更新時に、バックアップまたは非同期メンバがプライマリに接続されていない場合、その更新はプライマリへの次回の接続時に、そのメンバの [保留中の DN 更新の承認] リストに追加されます。メンバが引き続きミラーの一部にできるようにするには、[ミラーの編集] ページ (バックアップ) または [非同期構成の編集] ページ (非同期) の [保留中の DN 更新の承認] リンクをクリックして、更新を承認する必要があります。バックアップまたは非同期メンバは、プライマリからの X.509 DN 更新を拒否できません。
バックアップまたは非同期の X.509 DN 更新は、メンバがプライマリに接続されたとき、または次回メンバがプライマリに接続したときに、プライマリの [保留中の DN 更新の承認/拒否] リストにすぐに表示されます。メンバが引き続きミラーの一部にできるようにするには、プライマリの [ミラーの編集] ページで [保留中の DN 更新の承認/拒否] リンクをクリックし、[承認] を選択することで、更新を承認する必要があります。

Note:

^MIRROR ルーチンの [ミラー構成] メニューにある [保留中の DN 更新の承認/拒否] オプション (プライマリ) または [保留中の DN 更新の承認] オプション (バックアップまたは非同期) も、X.509 DN 更新の承認に使用できます。

バージョン 2015.2 よりも前の Caché の非同期メンバが、ミラーに 1つ以上含まれていると、X.509 更新は、前述したように伝達できないため、以下に示す特別な手順を実行する必要があります。

可能であれば、X.509 証明書更新を実行する前に、非同期を 2015.2 にアップグレードして、以下の手順の必要性をなくしてください。これが不可能な場合は、以下の手順に従って、2015.2 より前の非同期メンバの X.509 DN を更新してください。
1. プライマリの [ミラーの編集] ページにある [他のミラー・メンバを削除する] ボタン使用して、プライマリのミラー構成から非同期を削除します。
2. 2015.2 より前の非同期メンバの x.509 証明書を更新します。
3. プライマリの [ミラーの編集] ページにある [新規非同期メンバの追加] ボタンを使用して、非同期を元のミラーに追加します。詳細は、"フェイルオーバー・メンバの編集または削除" を参照してください。(また、^MIRROR ルーチンの [ミラー構成] メニューにある [保留リストにない非同期メンバの追加] オプションも、この目的に使用できます)。
4. 非同期のミラーリングされるデータベースを有効化してキャッチアップします。詳細は、"ミラーリングされるデータベースの有効化とキャッチアップ" を参照してください。
Caché バージョン 2015.2 以降のプライマリの X.509 DN を更新すると、2015.2 より前の非同期メンバは、プライマリへの接続を失います。これを回避するために、プライマリの X.509 証明書を更新する前に、2015.2 より前の非同期メンバをバージョン 2015.2 以降にアップグレードしてください。2015.2 より前の非同期をアップグレードできない場合は、該当する非同期でプライマリの X.509 DN を更新するための Config.MapMirrorsOpens in a new tab クラスの使用法について、インターシステムズのサポート窓口Opens in a new tabまでお問い合わせください。

DR 非同期メンバのフェイルオーバー・メンバへの昇格

災害復旧 (DR) 非同期ミラー・メンバはフェイルオーバー・メンバに昇格することができ、2 メンバ構成の場合は現在のフェイルオーバー・メンバに取って代わり、1 メンバ構成の場合は、現在のメンバに結合します。例えば、フェイルオーバー・メンバのいずれかが、計画的メンテナンスもしくは障害の結果により、長期間ダウンすることになる場合、一時的に DR 非同期を昇格させて、代替させることができます ("昇格した DR 非同期によるフェイルオーバー・メンバの一時的置き換え" を参照)。実際の災害復旧の間、両フェイルオーバー・メンバに障害が発生してしまった場合、DR を昇格させることで、ある程度のデータ損失のリスクは許容しつつ、DR がプライマリ・フェイルオーバー・メンバとしてプロダクションを引き継ぐことが可能になります。詳細は、"災害復旧時の昇格した DR 非同期への手動フェイルオーバー" を参照してください。

DR 非同期がフェイルオーバー・メンバに昇格すると、可能な場合、フェイルオーバー・パートナーとして最新プライマリとペアになります。これを自動で行うことができない場合、フェイルオーバー・パートナー選択のオプションが用意されます。昇格の後、フェイルオーバー・メンバが起動時にするように、昇格したメンバはフェイルオーバー・パートナーの ISCAgent と通信してまず直近ジャーナル・データを取得した後、フェイルオーバー・パートナーがプライマリでない場合はプライマリとなり、フェイルオーバー・パートナーがプライマリである場合はバックアップとなります。昇格したメンバは、フェイルオーバー・パートナーとの通信による直近ジャーナル・データ取得ができない限り、自動的にプライマリとなることはできません。

DR 非同期をフェイルオーバー・メンバに昇格する際、留意する必要のある以下の重要な考慮事項があります。

DR 非同期の位置によっては、フェイルオーバー・パートナーとの間におけるネットワーク遅延が受け入れられないほど長くなる場合があります。フェイルオーバー・メンバ間における遅延要件に関する詳細は、"ネットワーク遅延に関する考慮事項" を参照してください。
DR 非同期がフェイルオーバー・メンバになるときには、フェイルオーバー・メンバの圧縮設定が適用されます。昇格前と同じ、非同期メンバの圧縮が適用されるわけではありません (この設定の詳細は、"ジャーナル・データの圧縮" を参照してください)。ネットワーク構成によっては、フェイルオーバー・メンバの圧縮設定に調整が必要になることがあります。最適なミラー機能についての詳細は、"フェイルオーバー・メンバの編集または削除" を参照してください。
ミラー・プライベート・ネットワークを、フェイルオーバー・メンバのミラー・プライベート・アドレスの接続に使用しているときは、"ミラーリング・アーキテクチャとネットワーク構成のサンプル" で説明しているように、このネットワークに接続されていない DR 非同期の昇格は、プライマリとして機能することを目的とし、ほかに動作中のフェイルオーバー・メンバがない場合にのみ実行する必要があります。プライマリが動作中だがプライマリのミラー・プライベート・アドレスにアクセスできないときに DR 非同期を昇格する場合、バックアップになることはできません。ただし、プライマリのエージェントからジャーナル・データを取得できるため、プライマリがシャットダウンされたときには最新ジャーナル・データを使用してプライマリになることができます。
ミラー VIP が使用中であり、昇格された DR 非同期が VIP のサブネット上にない場合にこの DR がプライマリになるときは、何らかの代替方法を使用してユーザの接続を昇格された DR にリダイレクトする必要があります。例えば、VIP ではなく、DR 非同期の IP をポイントするように DNS 名を手動で更新するか、"フェイルオーバーまたは災害復旧後のアプリケーション接続のリダイレクト" で説明したメカニズムのいずれかを構成します。

ただし、障害復旧の状況によっては、昇格された DR 非同期が既存のフェイルオーバー・メンバのエージェントに通信できない場合があります。このような場合は、フェイルオーバー・パートナーなしで DR を昇格するオプションがあります。このセクションの "Promotion With Partner Selected by User" の説明を参照してください。つまり、DR は、既に受け取っているジャーナル・データと、その他の接続されているミラー・メンバで使用可能な最新のジャーナル・データ (存在する場合) のみで、プライマリに昇格できるということです。この場合、新しいプライマリがミラーにより生成されたジャーナル・データすべてを所有しているとは限らないので、アプリケーション・データが一部損失することがあります。このように昇格された DR 非同期がプライマリとして機能している間、以前のフェイルオーバー・パートナーを再起動する場合、その再構築が必要なことがあります。詳細は、"ミラー・メンバの再構築" を参照してください。このセクションで後述する DR の昇格手順で、詳細を必ず確認してください。

Note:

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

自動選択されたパートナーでの昇格

可能である場合、昇格した DR 非同期のフェイルオーバー・パートナーは、以下のように自動で選択されます。

動作中のプライマリ・フェイルオーバー・メンバがある場合、そのプライマリがフェイルオーバー・パートナーとして自動で選択されます。昇格したメンバはそのパートナーより直近ジャーナル・データを取得して、バックアップとなります。Caché が現在のバックアップ上で動作している場合、メンバは直ちに DR 非同期に降格されます。動作していない場合、Caché の再起動時に、メンバは DR 非同期に降格されます。
Caché がいずれのフェイルオーバー・メンバ上でも動作していないが、両フェイルオーバー・メンバ (1 つのみの場合は 1 つ) 上の ISCAgents に通信可能である場合、直近のプライマリがフェイルオーバー・パートナーとして自動選択され、昇格したメンバはそのパートナーより直近ジャーナル・データを取得して、プライマリとなります。Caché が以前のプライマリで再起動した場合、そのプライマリは自動的にバックアップとなります。Caché が以前のバックアップで再起動した場合、そのバックアップは自動的に DR 非同期となります。

ユーザが選択したパートナーでの昇格

Caché がいずれのフェイルオーバー・メンバでも動作しておらず、少なくとも 1 つの ISCAgent に通信不可能である場合、昇格プロシージャが通信不可能なエージェントを通知して、フェイルオーバー・パートナーの選択オプションを提示します。データ損失の可能性を避けるため、エージェントに通信不可能である場合でも、最後にプライマリだったフェイルオーバー・メンバを選択する必要があります。ユーザの選択および ISCAgent の利用可能性により、以下のように結果が異なります。

ユーザの選択したパートナーのエージェントに通信可能である場合、昇格した DR 非同期がそのエージェントより直近ジャーナル・データを取得した後、プライマリとなります。Caché がそのパートナーで再起動されると、そのパートナーは自動的にバックアップとなります。
ユーザの選択したパートナーのエージェントが通信不可能である場合、そのパートナーのエージェントに通信して、直近ジャーナル・データを取得できるまで、昇格した DR 非同期はプライマリにはなりません。パートナーのエージェントが使用可能になる前であればいつでも、直近のジャーナル・データを取得せずに、昇格したメンバを強制的にプライマリ化することができます ("災害復旧時の昇格した DR 非同期への手動フェイルオーバー" を参照)。ただし、結果として、アプリケーション・データが一部損失するおそれがあります。
フェイルオーバー・パートナーを選択しない場合、昇格される DR 非同期は、プライマリになる前に、接続されている非同期ミラー・メンバのすべてから最新の使用可能なジャーナル・データを取得しようとします。昇格される DR 非同期よりも新しいジャーナル・データを保持している接続されたメンバが存在しないことがあるため、一部のアプリケーション・データが失われる可能性があります。
これを選択するときに、昇格される DR 非同期でフェイルオーバーなしの状態を設定するオプションがあります。このオプションを選択すると、接続されている別のメンバからのジャーナル・データの取得を含め、プライマリになるための準備は行われますが、フェイルオーバーなしを取り消すまでプライマリになることはありません。これにより、必要とする追加の検証を実行して、可能であれば追加のメンバをオンラインにして、昇格される DR 非同期をプライマリにする前に、より新しい潜在的なジャーナル・データを使用できるようにします。

Note:

ジャーナル・データを確認するためにミラー・メンバとの通信を試行したときの成功および失敗のメッセージと、最新データが識別された場合にデータ取得を試行したときの成功および失敗のメッセージは、コンソール・ログに格納されます。

Caution:

DR 非同期が昇格されたときに ISCAgent がダウンしていた旧フェイルオーバー・メンバでは、Caché インスタンスの Caché パラメータ・ファイルの [MirrorMember] セクションで ValidatedMember=0 を設定するまで、Caché を再起動しないでください。これについては、以下の DR の昇格手順で説明します。

フェイルオーバー・パートナーが自動で選択されない場合、以下のルールが適用されます。

パートナーとして選択されないフェイルオーバー・メンバはいずれも、Caché の再起動時に DR 非同期メンバとなります。
Cach インスタンス再起動前のできるだけ早い段階において、DR 非同期の昇格時に自身のエージェントが通信不可能であった任意のフェイルオーバー・メンバ上で、Cach インスタンス用 Caché パラメータ・ファイルの [MirrorMember] セクションで ValidatedMember=0 を設定する必要があります ("Caché パラメータ・ファイル・リファレンス" の "[MirrorMember]" を参照)。これにより、Caché インスタンスに対して、以前のロールでのミラーへの再接続ではなく、昇格した DR 非同期からのミラー内での新規ロール取得が指示されます。^MIRROR ルーチンにより、この変更が必要なフェイルオーバー・メンバがリストされます。

Caution:

直近ジャーナル・データの取得なしで、昇格した DR 非同期がプライマリになるか強制的にプライマリになった場合、グローバル更新処理の一部が失われることがあり、他のミラー・メンバの再構築が必要になることがあります ("ミラー・メンバの再構築" に記載のとおり)。しかし、一部の災害復旧シナリオでは、直近ジャーナル・データの取得なしで、DR 非同期がプライマリに昇格するための代替手段がないことがあります。昇格プロシージャの機能について不明な点がある場合、インターシステムズのサポート窓口Opens in a new tabに問い合わせることをお勧めします。

DR 非同期メンバをフェイルオーバー・メンバに昇格させるには、以下の手順を実行します。

フェイルオーバー・メンバに昇格させる DR 非同期メンバで、システム, ミラー・モニタページに移動して、ミラー・モニタを表示します。
ページ上部の [フェイルオーバー・メンバに昇格] ボタンをクリックします。
その結果表示されるダイアログ・ボックスの指示に従ってください。最も単純な例では、昇格処理を続行するかの確認のみがこの指示に含まれますが、このセクションで前述したとおり、それにはフェイルオーバー・パートナーを選択するかしないかが含まれる場合があります。
ミラーに VIP が構成されている場合、昇格された DR 非同期は、プライマリになるときに (手動フェイルオーバーにより、またはバックアップとして動作中にプライマリが後で停止したことにより) VIP を取得できるように、VIP のサブネット上にネットワーク・インタフェースを有している必要があります。
- この DR 非同期が VIP のサブネット上にインタフェースを 1 つだけ有している場合、プロシージャによってこのインタフェースが自動的に選択されます。
- この DR 非同期が VIP のサブネット上に複数のインタフェースを有している場合、プロシージャからインタフェースの選択を求められます。
- この DR 非同期が VIP のサブネット上にインタフェースを有していない場合、昇格プロシージャからこの事実が警告され、続行する前に確認を求められます。このプロシージャを使用して続行し、DR 非同期を昇格する場合、ユーザとアプリケーションが新しいプライマリに接続できるように、例えば、VIP ではなく DR 非同期の IP をポイントするように DNS 名を更新するなど、手動ステップを実行する必要があります。
DR 非同期の昇格時に、以前のフェイルオーバー・メンバのエージェントが有効である場合、Caché インスタンス用 Caché パラメータ・ファイルの [MirrorMember] セクションで ValidatedMember=0 が自動設定されます ("Caché パラメータ・ファイル・リファレンス" の "[MirrorMember]" を参照)。これにより、Caché インスタンスに対して、以前のロールでのミラーへの再接続ではなく、昇格した DR 非同期からのミラー内での新規ロール取得が指示されます。
昇格時に以前のフェイルオーバー・メンバのエージェントと通信できない場合、この変更は自動では行われません。したがって、昇格時にエージェントが通信不可能であった以前のフェイルオーバー・メンバで、Caché インスタンスが再起動する前のできるだけ早い段階において、Caché インスタンス用 Caché パラメータ・ファイル編集により、手動で ValidatedMember=0 を設定する必要があります。この指示により、この変更が必要な以前のフェイルオーバー・メンバがリストされます。

Caution:

DR 非同期の昇格時に自身のエージェントがダウンしたミラー・メンバ上で、最初に ValidatedMember=0 を設定せずに Caché を再起動すると、両方のフェイルオーバー・メンバが同時にプライマリとして動作してしまうことがあります。

Note:

SYS.Mirror.Promote()Opens in a new tab、SYS.Mirror.PromoteWithPartner()Opens in a new tab、SYS.Mirror.PromoteWithNoPartner()Opens in a new tab、および SYS.Mirror.PromoteWithSelectedPartner()Opens in a new tab の各ミラーリング API メソッドは、DR 非同期をフェイルオーバー・メンバに昇格させるための代替手段を提供します。

バックアップの DR 非同期への降格

DR 非同期をフェイルオーバー・メンバに昇格させる以外に、その逆も行うことができます。つまり、現在のプライマリではないフェイルオーバー・メンバを DR 非同期に降格させて、ミラーに 1 つのフェイルオーバー・ミラーを残すことができます。これは、計画的停止の際に、ミラーの構成を一時的に変更してもフェイルオーバー・メンバを反応させたくない場合に便利です。次に例を示します。

メンテナンスのためにバックアップ・フェイルオーバー・メンバとそのホスト・システムをシャットダウンして、プライマリ上の Caché インスタンスを (理由にかかわらず) 再起動した場合、そのメンバは再起動後にプライマリになることはできません。バックアップ・インスタンスまたはその ISCAgent に接続できないため、自身が最新のプライマリであったかどうかを判断できないからです。ただし、"バックアップ・フェイルオーバー・メンバのメンテナンス" の説明に従って、ダウン状態にする前にバックアップを DR 非同期に降格しておくと、プライマリは、現在のバックアップがないため再起動後に自身がプライマリになることができることがわかるので、このリスクを避けることができます。続いて、再起動後に、降格した DR 非同期をバックアップに昇格できます ("DR 非同期メンバのフェイルオーバー・メンバへの昇格" を参照してください)。
"昇格した DR 非同期への計画的フェイルオーバー" で説明されているように、意図的に DR 非同期にフェイルオーバーして災害復旧機能をテストしており、プライマリ・インスタンスをシャットダウンしてフェイルオーバーをトリガする場合、プライマリ・インスタンスを自動的にバックアップにせずに再起動して同期状態を維持できます (実際の災害時には、プライマリ・インスタンスが利用できない可能性があるためです)。この場合、再起動前に (ISCAgent を使用して) DR 非同期に降格させておき、後で準備が整った時点でフェイルオーバー・メンバに昇格させることができます。

フェイルオーバー・メンバを降格させるには、"ミラー・モニタの使用" で説明しているように、いずれかのフェイルオーバー・メンバで、[ミラー・モニタ] ページ ([ホーム]→[システム処理]→[ミラー・モニタ]) に移動します。次に、以下の手順を実行します。

バックアップで、[DR メンバに降格] ボタンを使用して、バックアップを DR 非同期に降格させます (この方法は、前の例の最初の部分で使用します)。
プライマリで、[他のメンバを降格] ボタンを使用して、バックアップを DR 非同期に降格させます (この方法は、前の例の 2 番目の部分で使用します)。現在のメンバがプライマリで、バックアップ・インスタンスまたはその ISCAgent が到達可能な場合にのみ、降格に成功します。

Note:

^MIRROR ルーチンの [ミラー管理] メニューの [バックアップ・メンバから非同期 DR メンバへの降格] オプション、および SYS.Mirror.Demote()Opens in a new tab と SYS.Mirror.DemotePartner()Opens in a new tab のミラーリング API メソッドは、バックアップを DR 非同期に降格させる代替手段を提供します。

ミラー・メンバの再構築

状況によっては、停止または障害の発生後に、特に手動手順を使用してミラーを稼働状態に戻した場合、メンバのミラーリングされるデータベースがミラーと同期しなくなっていることがあります。例えば、プライマリの停止後に自動的には引き継がなかったバックアップを、最新のジャーナル・データなしに強制的にプライマリにすると ("バックアップがアクティブでない場合の手動フェイルオーバー" を参照)、前のプライマリ上の 1 つ以上のミラーリングされるデータベースが、新しいプライマリのデータベースと一致しない場合があります。

ミラーがその不一致を調整できる場合もありますが、調整できない場合もあります。ミラー・メンバのデータの不一致が調整不可能なミラー・メンバを再起動して、ミラーに再参加させようとすると、そのプロセスは停止し、次のような深刻度 2 のメッセージがコンソール・ログに書き込まれます。

This member has detected that its data is inconsistent with the mirror MIRRORNAME. If the primary is
running and has the correct mirrored data, this member, including its mirrored databases, must be 
rebuilt.

このメッセージの前に、不一致の詳細を示した深刻度 1 のメッセージが書き込まれます。

このメッセージがコンソール・ログに表示された場合は、以下のステップを実行します。

機能しているミラーが有しているデータのバージョンが目的のものであること、また不一致を報告しているメンバを再構築する必要があることを確認します。これは、例えば、すべての最新ジャーナル・データなしに手動で別のメンバをプライマリにすることを選択した後に、前のプライマリを再起動しているときにこのメッセージが表示された場合に当てはまることが多いです。この場合、以下のステップを使用して、不一致メンバを再構築します。
代わりに、不一致を報告しているメンバには目的のバージョンのデータがあると結論付けた場合、この手順を採用して、他のメンバを再構築できます。
使用するデータのバージョンが不明であったり、不一致メンバの再構築が適切であるかどうかわからない場合、最善策を判断できるように、インターシステムズのサポート窓口Opens in a new tabまでお問い合わせください。
機能しているミラー内の 1 つのメンバの、ミラーリングされるデータベースをバックアップします。以下のことを確信している場合は、ミラー内の 1 つのメンバで作成した既存のバックアップを使用することもできます。
- バックアップは、データの不一致をまねいた停止または障害が発生する前に作成された。
- 現在のプライマリには、バックアップが作成された時点のすべてのジャーナル・ファイルが含まれている。
"ミラー構成の編集または削除" の説明に従って、不一致メンバをミラーから削除し、ミラーリングされるデータベースの、ミラーリングされる DB 属性を保持します。
"第 2 のフェイルオーバー・メンバを構成する" または "非同期ミラー・メンバを構成する" の説明に従い、適切な手順を使用してメンバをミラーに追加します。
"ミラーへ既存データベースを追加する" の説明に従って、作成または選択したバックアップから、ミラーリングされるデータベースをメンバにリストアします。

バックアップおよび非同期メンバのミラーリングの停止

バックアップまたは非同期メンバのミラーリングは、一時的に停止できます。例えば、メンテナンスや再構成を行うための短い時間や、プライマリのデータベース・メンテナンスを行っている間は、プライマリのバックアップ・メンバのミラーリングを停止することが必要になる場合があります。また、ネットワークの使用率を下げるために、レポート非同期メンバのミラーリングを一時的に停止することがあるかもしれません。そのためには、以下の操作を実行します。

ミラーリングを停止するメンバのシステム, ミラー・モニタページに移動します。
そのメンバが、バックアップ・フェイルオーバー・メンバの場合は、[このメンバのミラーリングを停止] ボタンをクリックします。
そのメンバが非同期の場合は、ミラーリングを停止する非同期メンバのミラーの行にある [このメンバのミラーリングを停止] リンクをクリックします。(1 つのミラーのミラーリングを停止しても、レポート非同期が属しているその他のミラーには影響しません。)

この処理には、数秒かかります。[ミラー・モニタ] を更新すると、[このメンバのミラーリングを停止] は [このメンバのミラーリングを開始] に置き換えられています。これは、ミラーリングの再開に使用できます。

Important:

あるメンバでミラーリングを停止すると、前述したように、ミラーリングは明示的に再開するまで停止したままになります。ミラーの再初期化やメンバの再開始によって、そのメンバのミラーリングが開始されることはありません。

Note:

また、ミラーリングの SYS.Mirror.StopMirror()Opens in a new tab および SYS.Mirror.StartMirror()Opens in a new tab API メソッド、あるいは ^MIRROR ルーチン ("^MIRROR ルーチンの使用法" を参照) を使用して、これらのタスクを実行することもできます。

データベース・デジャーナリングの管理

"ミラー同期" で説明されているように、デジャーナリングとは、プライマリ・フェイルオーバー・メンバのジャーナル・データを他のミラーメンバのミラーリングされるデータベースに適用することにより、ミラーリングされるデータベースを同期させるプロセスのことです。デジャーナリングは、ルーチン・ミラー処理中の自動プロセスですが、ある状況下では、^MIRROR ルーチン ("^MIRROR ルーチンの使用法" を参照) で用意されているオプションを使用したデジャーナリングの管理が必要になる場合があります。バックアップ・フェイルオーバー・メンバ、DR 非同期メンバ、およびレポート非同期メンバのそれぞれの目的の違いにより、デジャーナリングとデジャーナリング管理でも違いがあります。特に、意図的なものであれ、エラーによるものであれ、デジャーナリングにおける中断に違いがあります。さらに、レポート非同期が属する 1 つ以上のミラーに向けたデジャーナリングに、ユーザ定義のフィルタを適用することもできます。

Note:

1 つまたはすべてのミラーされたデータベースのデジャーナリングが一時停止している場合でも、すべてのタイプのミラー・メンバはジャーナル・データの受信を続けます。

デジャーナリングの管理には、SYS.Mirror.AsyncDejournalStatus()Opens in a new tab、SYS.Mirror.AsyncDejournalStart()Opens in a new tab、SYS.Mirror.AsyncDejournalStop()Opens in a new tab、および SYS.Mirror.DejournalPauseDatabase()Opens in a new tab ミラーリング API メソッドを使用することもできます。

バックアップまたは DR 非同期でのデジャーナリング管理

バックアップ・フェイルオーバー・メンバおよび DR 非同期メンバ上のミラーリングされるデータベースは常にできる限りキャッチアップされて、プライマリとして引き継ぐ可能性や災害復旧での使用の可能性に備える必要があるため、エラーによるデジャーナリングの一時停止は、影響を受けたミラーリングされるデータベースに対してのみ行われ、それ以外に対してはデジャーナリングは続行されます。

例えば、バックアップまたは DR 非同期メンバで <FILEFULL> などのデータベース書き込みエラーが発生した場合、書き込みエラーが発生したデータベースのデジャーナリングは自動的に一時停止されますが、他のミラーリングされるデータベースのデジャーナリングは続行されます。エラーのデータベースをディスマウントし、エラーを修正したら、データベースを再マウントします。さらに、^MIRROR ルーチンの [ミラー管理] メニューにより [ミラーリングされるデータベースの有効化/キャッチアップ] オプションを選択してデジャーナリングを再開するか、管理ポータルの使用によりデータベースのキャッチアップを再開します ("ミラーリングされるデータベースの有効化とキャッチアップ" を参照)。

DR 非同期では、^MIRROR ルーチンの [ミラー管理] メニューにある [非同期メンバ上でのミラー・デジャーナリングの管理] オプションを使用して、メンバ上のミラーリングされるデータベースすべてに対してデジャーナリングを一時停止するオプションもあります。(このオプションは、バックアップ・メンバでは無効になっています。)これは、デジャーナリング・エラーの後や、メンテナンスを目的として使用できます。例えば、デジャーナリング・エラーによって、1 つのデータベースに対してのみデジャーナリングが一時停止した場合に、ミラー内のすべてのデータベースに対してデジャーナリングを一時停止するときは、以下を実行できます。

^MIRROR ルーチンの [ミラー管理] メニューから [非同期メンバ上でのミラー・デジャーナリングの管理] オプションを選択して、すべてのデータベースに対してデジャーナリングを一時停止します。
問題の発生しているデータベースをディスマウントして、エラーを修正し、データベースを再マウントします。
^MIRROR ルーチンの [ミラー管理] メニューから [非同期メンバ上でのミラー・デジャーナリングの管理] オプションを選択して、すべてのデータベースに対するデジャーナリングを再開始します。 (このオプションによって、エラーが生じたデータベースが自動的に有効化され、ミラー内の最新のデータベースと同じポイントまでキャッチアップされます。)

Note:

[非同期メンバ上でのミラー・デジャーナリングの管理] オプションを使用して、DR 非同期メンバ上のデジャーナリングを一時停止している場合、再度このオプションを使用して再開するまで、デジャーナリングは再開しません。

レポート非同期でのデジャーナリング管理

"非同期ミラー・メンバ" で説明するように、レポート非同期メンバは複数のミラーに属することができます。それら各ミラーに対して、データベースの使われ方により、データベース・デジャーナリングを継続的に実施することも、定期的に実施することもできます。例えば、指定されたミラーに対して、深夜から午前 4 時にかけてのデジャーナリングを行い、残りの時間帯には安定的なレポート生成のためデータベースに静的な状態を維持させることができます。

また、メンテナンスまたはデジャーナリング中のエラー発生のため、データベースをディスマウントする場合に、各種ミラーに対して異なる動作をさせることもできます。例えば、あるミラーでは、デジャーナリング一時停止中のデータベースが、ミラー内の他のデータベースから後れを取らないようにすることが最も重要なため、ミラー全体でデジャーナリングを一時停止することが望ましくなります。また別のミラーでは、ミラー内のデータベースができるだけ最新を保つことが最も重要なため、関与するデータベースのみを一時停止させることが最も重要となります。

レポート非同期上の 1 つ以上のミラーに対するデジャーナリングを、1 回限りの処理として、または定期的に一時停止する場合、^MIRROR ルーチンの [ミラー管理] メニューから [非同期メンバ上でのミラー・デジャーナリングの管理] オプションを選択して、目的のミラーですべてのデータベースに対してデジャーナリングを一時停止できます。デジャーナリングを再開するには、[非同期メンバ上でのミラー・デジャーナリングの管理] オプションを再度使用します。(このオプションは、バックアップ・メンバでは使用できません。)

バックアップや DR 非同期メンバとは異なり、レポート非同期メンバ上のデータベースのデジャーナリング中にエラーが生じた場合、そのミラー内のデータベースすべてに対して、デジャーナリングが自動的に一時停止します。ユーザの要望や方針に応じて、以下のいずれかができます。

エラーが発生したデータベースをディスマウントし、^MIRROR ルーチンの [ミラー管理] メニューから [非同期メンバ上でのミラー・デジャーナリングの管理] オプションを選択して、ミラー内のその他すべてのデータベースに対してデジャーナリングを再開し、エラーを修正して、データベースをマウントします。その後、^MIRROR ルーチンの [ミラー管理] メニューから [ミラーリングされるデータベースの有効化/キャッチアップ] オプションを選択して、そのデータベースに対するデジャーナリングを再開するか、または、管理ポータルの使用により、データベースのキャッチアップを再開します ("ミラーリングされるデータベースの有効化とキャッチアップ" を参照)。
エラーを修正し、データベースを再マウントする間は、ミラー全体に対してデジャーナリングを一時停止したままにし、その後、[非同期メンバ上でのミラー・デジャーナリングの管理] オプションを使用してミラー全体に対してデジャーナリングを再開します (このオプションによって、エラーが発生したデータベースが自動的に有効化され、ミラー内の最新のデータベースと同じポイントまでキャッチアップされます)。

レポート非同期メンバ上のミラーリングされるデータベースにメンテナンスを実行する場合、単にデータベースをディスマウントして、メンテナンスの後にデータベースをマウントし、[ミラーリングされるデータベースの有効化/キャッチアップ] オプションまたは管理ポータルを使用して、データベースをキャッチアップできます。(メンテナンスにこのようなデータベースが複数関係する場合は、"ミラーリングされるデータベースの有効化とキャッチアップ" の説明に従い、ミラー・モニタを使用して、一度にそれらのデータベースすべてに対して処理を実行します。これは、データベースを個々にキャッチアップするよりも、効率的で、かかる時間の短縮になります。)

Note:

エラーにより、レポート非同期メンバ上のミラーに対して、デジャーナリングが一時停止している場合、メンバはプライマリとの接続が次に再構築されたときに、そのミラーに対するデジャーナリングの再開を試みます。[非同期メンバ上でのミラー・デジャーナリングの管理] オプションを使用して、非同期メンバ上のミラーのデジャーナリングを一時停止している場合、再度このオプションを使用して再開するまで、そのミラーでのデジャーナリングは再開しません。

レポート非同期に対するデジャーナル・フィルタの使用

レポート非同期に限り、特定のミラーにユーザ定義のデジャーナル・フィルタを設定できます。これにより、ジャーナル・レコードごとにユーザ独自のコードを実行して、そのミラー内の読み書き可能のデータベースに適用するレコードを決定できます。フィルタをいったん定義しておけば、任意の数のミラーに設定することができます。また、フィルタは、いつでも設定、変更、および削除できます。

Note:

この機能は、きわめて特殊なケースおよび、同等のシャドウイング機能を使用するシャドウイング構成の変換に向けられたものです。その他の使用方法には、十分な注意が必要です。ミラー・メンバに複製するグローバルを制御する場合は、ミラーリングされないデータベースへのグローバルのマッピングにより、さらに簡単で軽量なソリューションが得られます。アプリケーション・データベースへの更新を監視する場合、アプリケーション・レベルで構築されたソリューションは、一般に高い柔軟性があります。

デジャーナル・フィルタにより、レポート非同期は、プライマリから受信したジャーナル・ファイルに含まれる一部のレコードのデジャーナリングをスキップできるようになります。ただし、これは、読み取り書き込み可能のデータベース (最初に読み書き可能のレポート非同期のミラーに追加されたデータベース、または読み取り専用としてミラーに追加されたときから [FailoverDB] フラグがクリアされているデータベース) にのみ当てはまることです。( レポート非同期のミラーリングされるデータベースのマウント・ステータスおよび [FailoverDB] フラグの詳細は、"レポート非同期ミラー・メンバの FailoverDB フラグのクリア" を参照してください。)FailoverDB フラグがデータベースに設定されている場合は、データベースが読み取り専用としてマウントされたことを意味します。それでもデジャーナル・フィルタのコードは実行されますが、フィルタコードの返す内容にかかわらず、そのデータベースには、常にすべてのレコードがデジャーナルされます。

Important:

デジャーナル・フィルタを設定すると、フィルタが設定されたミラーのデジャーナリングが遅くなります。この影響は、フィルタの内容によっては重大なものになることがあります。

デジャーナル・フィルタを作成するには、スーパークラス SYS.MirrorDejournalOpens in a new tab を拡張して、ミラー・デジャーナル・フィルタ・クラスを作成します。クラス名は、Z または z で始める必要があります。これにより、Caché のアップグレード時に、そのクラスが保持されます。

レポート非同期のミラーにデジャーナル・フィルタを設定するには、管理ポータルのシステム, 構成, 非同期の編集ページに移動して、[この非同期メンバの所属先のミラー] リストに示された目的のミラーの横にある [デジャーナル・フィルタの編集] リンクをクリックし、ミラー・デジャーナル・フィルタ・クラスの名前を入力して、[保存] をクリックします。フィルタを削除する場合は、同じ手順を実行しますが、入力ボックスをクリアしてから、[保存] をクリックします。ミラーのジャーナル・フィルタを追加、変更、または削除すると、そのミラーに対するデジャーナリングが自動的に再開され、フィルタが適用できるようになります。ただし、ミラー・デジャーナル・フィルタ・クラスに変更を加えてリコンパイルする場合は、^MIRROR ルーチンの [ミラー管理] メニューにある [非同期メンバ上でのミラー・デジャーナリングの管理] オプションを使用して、フィルタを設定したすべてのミラーのデジャーナリングを手動で停止および再開する必要があります。

一般的なミラーリングに関する考慮事項

このセクションでは、ミラーリングに関する考慮事項、推奨事項、および最善の方法のガイドラインを示します。このセクションには、以下のサブセクションがあります。

ミラーの API

SYS.MirrorOpens in a new tab クラスには、管理ポータルおよび ^MIRROR ルーチン ("^MIRROR ルーチンの使用法" を参照) で使用可能なミラー処理をプログラムで呼び出すためのメソッドと、多数のクエリが用意されています。例えば、SYS.Mirror.CreateNewMirrorSet()Opens in a new tab メソッドを使用することで、ミラーを作成し、第 1 のフェイルオーバー・メンバを構成することができます。その一方で、SYS.Mirror.MemberStatusList()Opens in a new tab クエリは、ミラー・メンバのリストと、それぞれのジャーナル遅延ステータスを返します。これらのメソッドの詳細は、SYS.MirrorOpens in a new tab のクラス・ドキュメントを参照してください。

バックアップを実行するために外部スクリプトを使用する場合は、%SYSTEM.MirrorOpens in a new tab クラスを使用すると、システムがミラーの一部であるかどうかを検証し、一部である場合はそのロールが何かを検証できます。

$System.Mirror.IsMember() 
$System.Mirror.IsPrimary()
$System.Mirror.IsBackup()
$System.Mirror.IsAsyncMember()
$System.Mirror.MirrorName()

$SYSTEM.Mirror.IsMember()Opens in a new tab は、このシステムがフェイルオーバー・メンバである場合は 1 を返し、非同期ミラー・メンバである場合は 2 を返し、ミラー・メンバではない場合は 0 を返します。$SYSTEM.Mirror.IsPrimary()Opens in a new tab は、このシステムがプライマリ・フェイルオーバー・メンバである場合は 1 を返し、そうでない場合は 0 を返します。$SYSTEM.Mirror.IsBackup()Opens in a new tab は、このシステムがバックアップ・フェイルオーバー・メンバである場合は 1 を返し、そうでない場合は 0 を返します。$SYSTEM.Mirror.IsAsyncMember()Opens in a new tab は、このシステムが非同期メンバである場合は 1 を返し、そうでない場合は 0 を返します。$SYSTEM.Mirror.MirrorName()Opens in a new tab は、このインスタンスがフェイルオーバー・ミラー・メンバとして構成されている場合はミラー名を返し、そうでない場合は NULL を返します。

また、%SYSTEM.Mirror.GetMemberType()Opens in a new tab および %SYSTEM.Mirror.GetMemberStatus()Opens in a new tab を使用して、Caché の現行インスタンスのミラー・メンバシップ (存在する場合) およびそのロールにおけるステータスについての情報を取得できます。詳細は、"ミラー・メンバのジャーナル転送およびデジャーナリングのステータス" を参照してください。

プライマリ・フェイルオーバー・メンバの外部バックアップ

Backup.General.ExternalFreeze()Opens in a new tab メソッドの使用により、プライマリ・フェイルオーバー・メンバのデータベースへの書き込みをフリーズして、"Caché データ整合性ガイド" の “バックアップとリストア” の章の説明どおりに、外部バックアップを実行できるようにするには、Backup.General.ExternalFreeze()Opens in a new tab の ExternalFreezeTimeOut パラメータの指定より長く、外部フリーズが更新を中断しないようにします。指定時間より長い中断が起こると、ミラーがバックアップ・フェイルオーバー・メンバをフェイルオーバーし、その結果、進行中のバックアップ操作が終了されてしまいます。

ミラー・メンバにおける Caché のアップグレード

ミラー・メンバーの Caché をアップグレードするときの考慮事項の詳細は、"Caché インストール・ガイド" の “Caché のアップグレード” の章にある "ミラーリングを使用した最小ダウンタイムのアップグレード" を参照してください。

ミラーリングにおけるデータベースの考慮事項

このセクションでは、ミラーリングされるデータベースを構成および管理する際に考慮する点について説明します。

Caché インスタンスの互換性

ミラーの各 Caché インスタンスは以下のようにいくつかの方法で互換性がある必要があります。

ミラー・メンバのシステムは、複数の異なるオペレーティング・システムまたはエンディアン、あるいはその両方に存在させることができますが、ミラーのすべてのメンバ上の Caché インスタンスは、以下の条件を満たしている必要があります。
- 同じ文字幅 (8 ビットまたは Unicode) の設定でインストールされている必要があります ("Caché インストール・ガイド" の "Caché の文字幅" を参照)。
- 同じロケールを使用している必要があります ("Caché システム管理ガイド" の “Caché の構成” の章の "管理ポータルの NLS ページの使用法" を参照)。
Note:

文字幅とロケールの要件には 1 つの例外があります。ISO 8859 Latin-1 文字セットに基づくロケールを使用している 8 ビットのインスタンスには、それに一致する幅の文字ロケールを使用している Unicode のインスタンスとの互換性があります。例えば、enu8 ロケールを使用する 8 ビットのプライマリ・インスタンスには、enuw ロケールを使用する Unicode バックアップ・インスタンスと互換性があります。ただし、heb8 ロケールを使用する 8 ビットのプライマリ・インスタンスは ISO 8859 Latin-1 に基づくロケールではないので、hebw ロケールを使用する Unicode バックアップ・インスタンスとの互換性はありません。
各フェイルオーバー・メンバは、同じデータベース・ブロック・サイズが有効化されている必要があります ("Caché システム管理ガイド" の“Caché の構成” の章にある "ラージ・ブロック・サイズに関する考慮事項" を参照)。また、フェイルオーバー・メンバで有効になっているサイズを非同期メンバで有効にする必要があります。プライマリに追加されるミラーリングされるデータベースのブロック・サイズが別のメンバで有効になっていないと、そのデータベースはそのメンバのミラーに追加できません。
フェイルオーバー・メンバとすべての DR 非同期メンバの Caché バージョンが同じである必要があります。"Caché インストール・ガイド" の “Caché のアップグレード” の章の "ミラーリングを使用した最小ダウンタイムのアップグレード" で説明されているいずれかのアップグレード手順の間のみ、異なっていてもかまいません。アップグレードされるメンバがプライマリになったら、このアップグレードが完了するまで、他方のフェイルオーバー・メンバおよびすべての DR 非同期メンバを使用できません (これらはプライマリにはなれないことに特に注意)。
ミラーリングでは、レポート非同期メンバがフェイルオーバー・メンバと同じ Caché バージョンである必要はありませんが、アプリケーションの機能でこれが必要な場合があります。
フェイルオーバー/DR 非同期メンバとレポート非同期メンバ間のバージョン相違の許容範囲、およびアップグレード中におけるフェイルオーバー・メンバと DR 非同期メンバ間のバージョン相違の許容範囲に関する詳細は、このリリース用のオンライン・ドキュメント "インターシステムズでサポートされるプラットフォームOpens in a new tab" の “サポート対象バージョン間の相互運用性” を参照してください。

メンバのエンディアンに関する考慮事項

ミラーリングされるデータベースの作成時または既存のデータベースのミラーへの追加時に、バックアップ・フェイルオーバー・メンバまたは非同期メンバのエンディアンがプライマリ・フェイルオーバー・メンバのエンディアンと異なる場合は、"ミラーへ既存データベースを追加する" で説明しているバックアップおよびリストアの手順は使用できません。その代わりに、データベースの CACHE.DAT ファイルをコピーする操作を含めて、そのセクションの手順を使用する必要があります。それに加えて、その手順を使用するときには、すべての非プライマリ・メンバに CACHE.DAT ファイルをコピーした後で、それらのメンバにデータベースをマウントする前に以下の手順を挿入します。

バックアップ・フェイルオーバー・メンバおよび各非同期メンバ上で、CACHE.DAT ファイルのコピーを変換します。"Caché 専用のシステム/ツールおよびユーティリティ" の “移行と変換ユーティリティ” の章にある "cvendian を使用したビッグ・エンディアン・システムとリトル・エンディアン・システム間の変換" の説明に従ってください。

Note:

コピーしているデータベースをプライマリで暗号化する場合、暗号化に使用したキーをバックアップ (および非同期 (存在する場合)) で有効化するか、cvencrypt ユーティリティを使用して宛先システムで有効化されたキーを使用するようデータベースを変換する必要があります (これについては、"Caché セキュリティ管理ガイド" の “cvencrypt ユーティリティの使用” の章にある "新しいキーを使用するように暗号化データベースを変換する" セクションで説明しています)。

^DATABASE ルーチンを使用したミラーリングされるデータベースの作成

ミラーリングされるデータベース (ミラーリング・データベース) をミラー・メンバに作成するには、^DATABASE ルーチンを使用します (このルーチンの詳細は、"Caché セキュリティ管理ガイド" の “文字ベースのセキュリティ管理ルーチンの使用” の章の "^DATABASE" を参照)。他のミラー・メンバに新規ミラーリング・データベースを作成する前に、プライマリ・メンバにそれを作成する必要があります。ミラーリングされるデータベースを作成するには：

^DATABASE ルーチンを実行し、[1) データベースの作成] オプションを選択します。
[データベースディレクトリ ?] プロンプトでディレクトリ・パスを入力します。
[既定のデータベースプロパティを変更?] プロンプトで [はい] を入力します。
[フィールド番号を変えますか?] プロンプトで 3 ([ミラーDB名:]) を入力し、[ミラーDB名は?] プロンプトでミラーリングされるデータベースのミラー名を入力します。

Note:

作成しているミラーリング・データベースのメンバが複数ミラーのメンバで、かつ既定のリストのミラーと異なるミラーでミラーリング・データベースを作成している場合、[フィールド番号を変えますか?] プロンプトで ([ミラーセット名:]) を入力し、リストから適切なミラー名を選択します。ルーチンを実行しているメンバが唯一のミラーのメンバである場合、このフィールドは変更できません。
ユーザのデータベースの必要に応じて、他のフィールドを変更し、変更が終了したら、[フィールド番号を変えますか?] プロンプトで、オプションを指定せずに Enter を押します。
[構成中データベースのデータセット名:] プロンプトで、データベースのデータセット名を入力します。これは管理ポータルで表示される名前です。
ミラーリングされるデータベースが作成されるまで、残りのプロンプトに返答を入力してください。

バックアップおよび非同期メンバにミラーリングされるデータベースを作成する場合、プライマリ・メンバに作成したデータベースに対するキャッチアップが自動的に行われます。

Note:

^DATABASE ルーチンの使用によって、既存のミラーリングされないデータベースをミラーに追加することはできません。必要なプロシージャの詳細は、"ミラーへのデータベースの追加" を参照してください。

^DATABASE ルーチンを使用した既存のミラーリングされるデータベースの再作成

^DATABASE ルーチンの [10) データベースの再作成] オプションを使用すると、データベースの名前やサイズを変更することなく、既存のデータベースのデータをクリアできます (このルーチンの詳細は、"Caché セキュリティ管理ガイド" の “文字ベースのセキュリティ管理ルーチンの使用” の章の "^DATABASE" を参照)。このオプションは、ミラーリングされるデータベースに使用できますが、そのデータベースを認識するすべてのミラー・メンバで使用する必要があり、新しいミラーリングされるデータベースの作成に [データベースの作成] オプションを使用した順序 (最初にプライマリ、次にバックアップ、その次にミラーに含まれるデータベースの非同期) で使用する必要があります。

Caution:

[10) データベースの再作成] オプションを使用してプライマリにデータベースを再作成する場合、バックアップとミラーの DR 非同期にも、この操作を繰り返す必要があります。このようにしないと、フェイルオーバー時または災害復旧時に、そのデータベースは破棄されることがあります。再作成操作は、レポート非同期にも繰り返すことを強くお勧めします。

ミラーリングされるデータベースのマウント/ディスマウント

ミラーリングされるデータベースは、どちらのフェイルオーバー・メンバ上でもマウントおよびディスマウントできます。ただし、バックアップ・フェイルオーバー・メンバ上でディスマウントされた場合、そのデータベースは、再マウントされた後でミラーリングによって自動的にデータベースのキャッチアップが試みられるまで “古い” 状態のままになります。必要なジャーナル・ファイルがプライマリ・フェイルオーバー・メンバ上で使用可能な場合は、自動アップデートが正常に実行されます。ただし、プライマリ・メンバ上の必要なジャーナル・ファイルのいずれかが削除されている場合は、プライマリ・メンバ上の最新のバックアップからデータベースをリストアする必要があります。

ミラーリングされないシステムへのミラーリングされるデータベースのコピー

以下のようにして、ミラーリングされるデータベースを、ミラーリングされないシステムにコピーし、そのシステム上での読み書き可能としてマウントできます。

プライマリまたはバックアップ・フェイルオーバー・メンバ上のミラーリングされたデータベースをバックアップし、"ミラーへ既存データベースを追加する" で説明されている手順で、ミラーリングされていないシステムにバックアップ内容をリストアします (外部バックアップ・リストアまたはコールド・バックアップ・リストアに続くデータベースの手動での有効化とキャッチアップの手順は省略します)。リストアしても、データベースは引き続きミラーリングされているとマークされており、読み取り専用です。
ミラーリングされないシステム上では、^MIRROR ルーチン ("^MIRROR ルーチンの使用法" を参照) を使用して、[1 つ以上のミラーリングされるデータベースの削除] を選択し、手順に従ってミラーからデータベースを削除します。この手順に従うと、データベースは読み取り/書き込みモードでマウントされます。

ミラーリングにおける Ensemble の考慮事項

このセクションでは、Ensemble に適用するその他の考慮事項について説明します。内容は以下のとおりです。

ミラーリングされるデータを使用した Ensemble ネームスペースの作成

Ensemble ネームスペースの作成には、Ensemble を新しいネームスペースで使用できるようにするためのデータベース書き込みが必要であるため、1 つ以上のミラーリングされるデータベースからのマッピングが設定された Ensemble ネームスペースを現在のプライマリ・ミラー・メンバに作成する必要があります。ミラーリングされるデータベースが読み取り専用であるバックアップには作成できません。

Ensemble における、ミラーリングされるデータでのネームスペースの扱い方

Ensemble では、ネームスペースのマッピングを検査し、ミラーリングされるデータベースからのマッピングがネームスペースに含まれているか判断します。

Ensemble の起動時またはアップグレード時、次のように、プライマリ・ミラー・メンバの扱いが他のミラー・メンバとは異なっています。

起動時に、プライマリ・ミラー・メンバ上のプロダクションのみが起動されます。
Ensemble のアップグレード時に、特定のタスクにはデータベースへの書き込みアクセス権が必要です。Ensemble では、これらのタスクはプライマリ・ミラー・メンバでのみ実行されます。
フェイルオーバーが発生して、メンバがプライマリ・ミラー・メンバになると、Ensemble では、アップグレード時とプロダクションの起動時にはスキップされていたタスクすべてが実行されます。

Ensemble の推奨ミラーリング構成

ミラーリングには高可用性ソリューションとなることが意図されており、よって、ミラー・インスタンスのいずれにおいても無関係なアクティビティを最小限とすることが必要です。すなわち、ミラーリングされるあらゆるインスタンスのデータベースすべてをミラーリングする必要があります。

ユーザには、いずれのノードにおいてもデータのミラーリングなしで実行される、“より危険の少ない”プロダクションが選ばれてしまうことがあります。しかし、そのような構成では処理が複雑になり、維持が困難になる可能性があります。よって、そのような構成は避けて、代わりにすべてのデータベースをミラーリングすることを強く推奨します。

ミラーリング環境における Ensemble の自動開始の機能

ミラー・システムの起動時に (この時点では、まだいずれのメンバもプライマリ・フェイルオーバー・メンバになっていません)、以下のようになります。

Ensemble では、ミラーリングされるデータにアクセスするプロダクションは、^Ens.AutoStart で指定されている場合でも起動されることはありません。メンバがプライマリ・インスタンスになると、その時点でこれらのプロダクションは起動されます。
Ensemble により、ミラーリングされるデータにアクセスしないネームスペースがインスタンス上にあるかどうかが判別されます。前述のとおり、ミラー・メンバにはミラーリングされるプロダクションのみをインストールすることをお勧めしています。それでも、ミラーリングされないデータベースと共にプロダクションがインストールされている場合、Ensemble によりそのプロダクションは ^Ens.AutoStart で指定して起動されます(このロジックによって、ミラーリングされないネームスペースがミラー・メンバ上にインストールされている場合、Ensemble 起動時に起動されます)。

後で、メンバがプライマリ・フェイルオーバー・メンバになったとき、Ensemble は、ミラーリングされるデータを参照するネームスペースを検索し、それらのネームスペースでプロダクションを起動できるようにします。インターシステムズの推奨設定に従っていれば、インスタンスがプライマリ・ミラー・メンバになる前に、ミラーリングされるデータにアクセスするプロダクションは実行しません。Ensemble ではまず、起動前にプロダクションが実行中でないかどうかが確認されます。具体的には以下の処理が実行されます。

Ensemble により、ネームスペースで _Ensemble ユーザとして実行されているジョブを数えることによって、プロダクションが既に実行中でないかどうかが判別されます。そのようなジョブが 3 個以上ある場合、これはプロダクションが既に実行中であることを示しており、Ensemble によりコンソール・ログに警告が記録され、そのプロダクションの起動は試行されません。
予想どおりにプロダクションが実行中でない場合、Ensemble により、プロダクションは ^Ens.AutoStart で指定して自動的に起動されます。

Ensemble プロダクションの起動と停止の詳細は、"Ensemble の管理" の “プロダクションの開始と停止” の章を参照してください。

ミラー停止の手順

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

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

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

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

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

このセクションでは、以下のトピックについて説明します。

計画的停止の手順

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

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

Note:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ミラー内 Caché インスタンスのアップグレード

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

計画外停止の手順

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

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

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

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

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

Note:

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

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

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

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

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

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

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

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

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

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

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

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

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

Caution:

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

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

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

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

Caché インスタンスと Caché A 上の ISCAgent の両方が実際にダウンしていることを確認します (そしてこの手動フェイルオーバーの手順全体を通して、ダウンしたままであることを確認します)。
Caché B 上で、Caché ターミナルの %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\MyCache\mgr\journal\MIRROR-GFS-20140815.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 ルーチンによって、バックアップがプライマリになったことが確認されたら、Caché A を再起動できるときにそのようにします。Caché A は、Caché インスタンス再起動時にバックアップとしてミラーに参加します。

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

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

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

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

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

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

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

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

Caution:

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

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

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

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

Caution:

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

災害復旧の手順

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

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

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

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

Caution:

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

Note:

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

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

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

Note:

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

Caution:

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

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

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

Caution:

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

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

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

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

Note:

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

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

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

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

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

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

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

Note:

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

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

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

Note:

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

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

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

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

Note:

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

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

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

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

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

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

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