論理ミラー
4D Server では論理ミラーを使⽤したバックアップシステムの設定を可能とする統合されたソリューションを提供します。 このソリューションは2つのコマンドに基づいています: New log file よび INTEGRATE MIRROR LOG FILE です。
論理ミラーとは
論理ミラーは洗練されたバックアップモードで、クリティカルあるいはハイロードのデータベースで主に使⽤されます。
論理ミラーは、あるマシンで動作中のデータベースのコピーを別のマシン上に作成し、定期的に更新することで構成されます。 両マシンはネットワークを経由して通信を⾏い、動作中のマシンはデータに対して⾏われたすべての更新を、ログファイルの形で定期的にミラーマシンに送信します。
この方法であれば、動作中のデータベースに影響する事故が発⽣しても、ミラーデータベースを使⽤して素早く、またデータを失うことなく元に戻すことができます。 さらに、動作中のデータベースはバックアップにより"ブロック"されることはありません。
なぜ論理ミラーによるバックアップを選択するのか
論理ミラーの使⽤は特定のニーズに応えるものです。 定期的なバックアップとログファイルの使⽤に基づく標準の⽅法は、ほとんどの場合簡単で信頼性があり、コストのかからない⽅法です。 データベースは定期的 (通常24時間ごと) にバックアップされます。 バックアップ中は、全てのプロセスがフリーズされます。 この⼀時的な書き込み不可の時間は、(2GBを超えるような)⼤きなデータベースであってもとても短いもので、5分もかかりません。 この動作を、データベースが利⽤されていない時間帯に⾏うよう設定することも可能です。
にもかかわらず、特定の種類の組織、例えば病院などでは、クリティカルなデータベースを24時間完全に動作させなければなりません。 データベースをたとえ短時間でも"バックアップ中"(で結果的にアクセス不可)にすることはできません。 この場合、論理ミラーの設定が適切なソリューションとなります。
ミラーデータベースはデータに対して⾏われた変更のみを反映します。 このバックアップモードは開発途中のデータベースには適しません。しばしばストラクチャに対する変更が⾏われ、それはミラーを無効なものとし、ミラーデータベースストラクチャの交換を必要としてしまいます。
動作
論理ミラーを使⽤したバックアップシステムの設定は、2つの新しいコマンド New log file および INTEGRATE MIRROR LOG FILE を使⽤して⾏います。
以下のような原則が実装されています:
- アプリケーションはメインの4D Server マシン(動作マシン) にインストールされ、その全く同じコピーが4D Server ミラーマシンにインストールされます。
- 起動時にアプリケーションのテストを⾏い (例えば4D Server アプリケーションのサブフォルダ内で特定のファイルが存在するかどうかをチェックするなど)、動作マシンかミラーマシンかの区別をして、適切な動作を実⾏します。
- 動作マシンの4D Server では
New log fileコマンドによって、定期的にログファイルは"分割"されます。 メインサーバ上ではバックアップを⾏いませんので、データベースは常に読み書き可能です。 - 分割されたログファイルをミラーマシンに送信して、
INTEGRATE MIRROR LOG FILEコマンドを使⽤してミラーデータベースに統合します。
このシステムの設定には、コードのプログラムが必要です。具体的には以下の様なものが必要です:
- メインサーバ上で
New log fileコマンドの実⾏を管理するタイマー。 - "分割" されたログファイルを動作マシンからミラーマシンに送信するシステム (HTTP、Web サービス等)。
- ミラーマシン上で、ログファイルのセグメントの到着を検知し、
INTEGRATE MIRROR LOG FILEコマンドを使⽤してそれを統合するプロセス。 - メインサーバとミラーサーバとの間の通信とエラー処理システム。
論理ミラーを使⽤したバックアップシステムを使⽤するときは、動作マシン中のマシン上で標準のバックアップ を⾏うことはできません。これら2つのバックアップモードを両⽅使⽤すると、動作中のデータベースとミラーデータベースの間で同期のズレが発⽣します。 動作データベースでは⾃動マニュアル問わず、バックアップが実⾏されないようにしてください。 他⽅、ミラーデータベースのバックアップ、またはミラーデータベースのミラーを設定することは可能です。
ミラーデータベースのバックアップとミラーのミラー
ミラーマシン上の4D Serverで、データベースのバックアップを実⾏できます。
ミラーマシン上では、どのような⽅法でもバックアップを実⾏できます 。ファイルメニューのコマンドを使⽤した⼿動によるバックアップ、データベース設定で設定した定期的なバックアップ 、ランゲージコマンドを使⽤したプログラムによるバックアップなど。
動作マシンとの⾮同期のリスクを避けるため、動作マシンからのログファイルの統合時とミラーデータベースのバックアップ、どちらかの基本的な処理を⾏うとき、4Dは⾃動でミラーマシンをロックします。
- ログファイルの統合処理中、バックアップを⾏うことはできません。
BACKUPコマンドを使⽤すると、エラー1417 が⽣成されます。 - バックアップの実⾏中は、すべてのプロセスが停⽌され、ログファイルの統合を開始することはできません。
カレントのログファイルをミラーマシンでも有効化することも出来ます。これはつまり"ミラーのミラー"(またはそれのさらならミラー)や、"ハブ&スポーク"型のミラーアーキテクチャ(⼀つのオペレーショナルデータベースに対して複数のミラーを⽴てる構造)を設定できる、という事です。 前者の場合、ミラーのカレントログファイルは順番に次のミラー(ミラーのミラー)へと送られ統合され、それ以降のミラーを使⽤していた場合に関しても同様に送られます。 後者の場合、複数の同⼀のミラーに対してカレントログファイルが直接送付されます。 この予備を⽤意する⽅法を使⽤すれば、サーバーとメインのミラーが同時に落ちた場合でも、サーバーを継続して利⽤する事ができます。
論理ミラーのオペレーションシナリオ
それぞれの4D Serverマシンの視点から⾒た以下のシナリオは、ミラーを使⽤したバックアップシステムの設定とオペレーションを⽰します:
| ステップ | 本番環境 | ミラーマシン |
|---|---|---|
| 1 | アプリケーションを開始。データファイルをバックアップ。 ログファイルはデフォルトで有効化されています。より安全性を求める場合、このファイルは他のハードディスクに保存しましょう。 | |
| 4D はMyDatabase.journal ファイルを作成。 | ||
| アプリケーションを終了。 | ||
| (ログファイルを含む) すべてのデータベースファイルをミラーマシンにコピー。 | ||
| 2 | アプリケーションを再起動 (フルバックアップがプログラムされていないことを確認)。 | ミラーアプリケーションを開始。 4D Server はカレントログファイルを要求: 本番環境から転送したMyDatabase.journal ファイルを選択します。 このファイルはミラーのミラーを設定するときに使⽤されます。 |
| 3 | ミラーの更新を決定する (例えば特定の時間経過後、など)。 | |
New log file コマンドを含むメソッドを実⾏。 保存されるファイル名は MyDatabase[0001-0001].journal 。 | ||
| プログラムを使用して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がログファイルを要求。ミラーデータベースから転送したログファイルを選択する。 | アプリケーションを終了。 ステップ2 に戻る。 |