メインコンテンツまでスキップ
バージョン: 21 R5 BETA

論理ミラー

4D Server では論理ミラーを使用したバックアップシステムの設定を可能とする統合されたソリューションを提供します。

論理ミラーとは​

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

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

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

なぜ論理ミラーによるバックアップを選択するのか​

論理ミラーの使用は特定のニーズに応えるものです。定期的なバックアップとログファイルの使用に基づく標準の方法は、ほとんどの場合簡単で信頼性があり、コストのかからない方法です。データベースは定期的 (通常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-0001].journal ファイルを統合。ミラーのミラーを使用している場合、ステップ3とほぼ同様のプロシージャをミラーマシンで実行します(これはログが統合されるたびに繰り返します)。
5マシン上で事故発生。データファイルが利用不可になる。ミラーマシンへの移行を決定。
MyDatabase.journal カレントログファイルをミラーマシンのいつもの送信先フォルダーにコピー。
6事故を分析して、修復。統合待ちのファイルを検知。 INTEGRATE MIRROR LOG FILE コマンドを含むメソッドを実行して MyDatabase.journal ファイルを統合。
アプリケーションを実行。
7マシンが復旧。データベースファイルをミラーデータベースのものと入れ替える。アプリケーションを開始。 4D Serverがログファイルを要求。ミラーデータベースから転送したログファイルを選択する。アプリケーションを終了。ステップ2 に戻る。