論理ミラーの設定

4D v20 R7

論理ミラーの設定

4D Serverでは論理ミラーを使用したバックアップシステムの設定を可能とするソリューションを提供します。このソリューションでは新しい2つのコマンドNew log fileとINTEGRATE MIRROR LOG FILEを使用します。

論理ミラーとは

論理ミラーは洗練されたバックアップモードで、クリティカルあるいはハイロードのデータベースで主に使用されます。

論理ミラーは、あるマシンで動作中のデータベースのコピーを別のマシン上に作成し、定期的に更新することで構成されます。両マシンはネットワークを経由して通信を行い、動作中のマシンはデータに対して行われたすべての更新を、ログファイルの形で定期的にミラーマシンに送信します。

動作中のデータベースに影響する事故が発生した場合、ミラーデータベースを使用して素早くまたデータを失うことなく、元に戻すことができます。さらに、動作中のデータベースはバックアップによりブロックされることはありません。

論理ミラーの使用は特定のニーズに応えるものです。定期的なバックアップとログファイルの使用に基づく標準の方法は、ほとんどの場合簡単で信頼性があり、コストのかからない方法です。データベースは定期的 (通常24時間ごと) にバックアップされます。バックアップ中は、全てのプロセスがフリーズされます。この一時的な書き込み不可の時間は、2GBを超えるような大きなデータベースであってもとても短いもので、5分もかかりません。この動作を、データベースが利用されていない時間帯に行うよう設定することも可能です。

にもかかわらず、特定の種類の組織、例えば病院などでは、クリティカルなデータベースを24時間完全に動作させなければなりません。データベースをたとえ短時間でも"バックアップ中"(で結果的にアクセス不可)にすることはできません。この場合、論理ミラーの設定が適切なソリューションとなります。

Note: ミラーデータベースはデータに対して行われた変更のみを反映します。このバックアップモードは開発途中のデータベースには適しません。しばしばストラクチャに対する変更が行われ、それはミラーを無効なものとし、ミラーデータベースストラクチャの交換を必要としてしまいます。

どのように動作するか

論理ミラーを使用したバックアップシステムの設定は、2つの新しいコマンドNew log fileとINTEGRATE MIRROR LOG FILEを使用して行います。これらのコマンドは4D Language Referenceマニュアルで説明しています。

以下の実装を行います:

データベースはメインの4D Serverマシン (動作マシン) にインストールされ、その全く同じコピーが4D Serverミラーマシンにインストールされます。
起動時にアプリケーションのテストを行い (例えば4D Serverアプリケーションのサブフォルダ内で特定のファイルが存在するかどうかをチェックする)、動作マシンかミラーマシンかの区別をして、適切な動作を実行します。
動作マシンの4D ServerでNew log fileコマンドを使用して、定期的にログファイルを分割します。メインサーバ上ではバックアップを行いませんので、データベースは常に読み書き可能です。
分割されたログファイルをミラーマシンに送信して、INTEGRATE MIRROR LOG FILEコマンドを使用してミラーデータベースに統合します。

このシステムの設定には、コードのプログラムが必要です。特に:

メインサーバ上でNew log fileコマンドの実行を管理するタイマー。
分割されたログファイルを動作マシンからミラーマシンに送信するシステム (4D Internet CommandsによるFTP 、メッセージシステム、Webサービス等)。
ミラーマシン上で、分割されたログファイルの到着を検知し、INTEGRATE MIRROR LOG FILEコマンドを使用してそれを統合するプロセス。
メインサーバとミラーサーバとの間の通信とエラー処理システム。

警告: 論理ミラーを使用したバックアップシステムを使用するときは、動作マシン中のマシン上で標準のバックアップを行うことはできません。これら2つのバックアップモードを両方使用すると、動作中のデータベースとミラーデータベースの間で非同期が発生します。動作データベースでは自動マニュアル問わず、バックアップが実行されないようにしてください。他方、ミラーデータベースのバックアップ、またはミラーデータベースのミラーを設定することは可能です (後述参照)。

ミラーデータベースのバックアップとミラーのミラー

ミラーマシン上の4D Serverで、データベースのバックアップを実行できます。

ミラーマシン上では、どのような方法でもバックアップを実行できます。ファイルメニューのコマンドを使用した手動によるバックアップ、データベース設定で設定した定期的なバックアップ、ランゲージコマンドを使用したプログラムによるバックアップなど。

注: ミラー・マシンでログファイルを有効にすることはできません。さらに、このマシンでログファイルを使用オプションを選択していないことを確認してください。

動作マシンとの非同期のリスクを避けるため、動作マシンからのログファイルの統合時とミラーデータベースのバックアップ、どちらかの基本的な処理を行うとき、4Dは自動でミラーマシンをロックします。

ログファイルの統合処理中、バックアップを行うことはできません。BACKUPコマンドを使用すると、エラー1417が生成されます (4Dランゲージリファレンスのバックアップマネージャエラー (1401 -> 1421)参照)。
バックアップの実行中は、すべてのプロセスが停止され、ログファイルの統合を起動することはできません。

4D v14以降、カレントのログファイルをミラーマシンでも有効化することが出来るようになりました。これはつまり"ミラーのミラー"(またはそれのさらならミラー)や、"ハブ&スポーク"型のミラーアーキテクチャ(一つのオペレーショナルデータベースに対して複数のミラーを立てる構造)を設定できるようになった、という事です。前者の場合、ミラーのカレントログファイルは順番に次のミラー(ミラーのミラー)へと送られ統合され、それ以降のミラーを使用していた場合に関しても同様に送られます。後者の場合、複数の同一のミラーに対してカレントログファイルが直接送付されます。この予備を用意する方法を使用すれば、サーバーとメインのミラーが同時に落ちた場合でも、サーバーを継続して利用する事ができます。

論理ミラーのオペレーションシナリオ

それぞれの4D Serverマシンの視点から見た以下のシナリオで、ミラーを使用したバックアップシステムの設定とオペレーションを示します:

Step	本番環境	ミラーマシン
1	アプリケーションを開始。データファイルをバックアップ。ログファイルはデフォルトで有効化されています。より安全性を求める場合、このファイルは他のハードディスクに保存しましょう。
	4DはMyDatabase.journalファイルを作成。
	アプリケーションを終了。
	(ログファイルを含む) すべてのデータベースファイルをミラーマシンにコピー。
2	アプリケーションを再起動 (フルバックアップがプログラムされていないことを検証)。実行を開始。	ミラーアプリケーションを開始。4D Serverはカレントログファイルを要求: 本番環境から転送したMyDatabase.journalファイルを選択。このファイルはミラーのミラーを設定するときに使用されます。
3	ミラーの更新を決定する (例えば特定の時間経過後)。
	New log fileコマンドを含むメソッドを実行。保存されるファイル名は MyDatabase[0001-0001].journal。
	(4DICやWebサービスなど) プログラムを使用してMyDatabase[0001-0001].journalファイルをミラーマシンに送信。
	データベース実行。
4		統合待ちのファイルを検知。INTEGRATE MIRROR LOG FILEコマンドを含むメソッドを実行してMyDatabase[0001-0000].journalファイルを統合。ミラーのミラーを使用している場合、ステップ3とほぼ同様のプロシージャをミラーマシンで実行します(これはログが統合されるたびに繰り返します)。
5	マシン上で事故発生。データファイルが利用不可になる。ミラーマシンへの移行を決定。
	MyDatabase.journalカレントログファイルをミラーマシンのいつもの送信先フォルダにコピー。
6	事故を分析して、修復。	統合待ちのファイルを検知。INTEGRATE MIRROR LOG FILEコマンドを含むメソッドを実行してMyDatabase[0001-0001].journalファイルを統合。
		データベースが動作。
7	マシンが復旧。データベースファイルをミラーデータベースのものと入れ替える。アプリケーションを開始。4D Serverがログファイルを要求。ミラーデータベースから転送したログファイルを選択する。	データベースを終了。Step2に戻る。