4D では、データをバックアップする方法を複数ビルトインで提供しています: 4Dバックアップとミラーサーバーの使用です。4D v20 では、データストアをロックする内部コマンドを公開し、4D の実行中にデータをコピーできるようになりました。
まず、4D でデータをバックアップするためのさまざまな手段について説明します。
自動バックアップと復元
ビルトインのバックアップ機能は、データファイルの完全なコピーを自動的に作成するだけでなく、データに対しておこなわれた全操作を含むログファイルを管理します。これは、仕事を保護するための最良の方法です。停電、ハードディスクの損傷、システムのクラッシュなどが起こった場合、次の起動時に 4D は自動的に障害を検知し、必要に応じて、失われた操作をログから統合するか、完全復元とログ統合を実行します。そのため、ほとんどのユースケースで 4Dバックアップの使用を推奨しています。
詳細については、バックアップと復元 を参照ください。
ミラーサーバー
フルバックアップのためにデータファイルをロックすることができない 24時間365日稼働し続けるような運用環境や、復元にかかる時間が最短でなくてはならない場合は、ミラーサーバーを使う必要があります。ミラーサーバーには自動的に全操作が複製されるため、メインサーバーに障害が生じた場合、ミラーサーバーに切り替えるのに必要な時間はほんの数秒です。
ミラーサーバーの設定は、バックアップを使用するよりも手間がかかり、より複雑です。私たちは、この構成を導入する多くのお客様をサポートしてきました。疑問点や相談などは、4D のプロフェッショナルサービスチームにご連絡ください。
Windows ボリュームシャドウコピー
特に仮想環境では、システム管理者はボリュームシャドウコピー (VSS) のスナップショットを使用することを好みます。4D は、独自の 4D VSS ライターでこれをサポートしています。詳しくは、こちらのブログ記事 を参照ください。
スナップショットには特定の瞬間のデータしか含まれないため、4Dバックアップの代わりにはならない点に注意が必要です。スナップショット後におこなわれた操作は、ジャーナルとログファイルがないため、取得することができません。
4Dバックアップの仕組み
バックアップとVSSの仕組み
ミラーリングについてはデータの保存方法が全く異なるためここでは除外し、4Dバックアップと 4D VSS の仕組みについて見ていきます。
まず考慮すべき点は、4D はすべての変更をリアルタイムで (つまり即座に) データファイルに適用するわけではないことです。これをおこなうと、ディスクアクセスが多くなり、アプリケーションのパフォーマンスに大きな影響を与えます。4D はメモリ上のキャッシュを使用し、すべての変更はまずそこに適用されます。4D は定期的にキャッシュをフラッシュして、蓄積した変更をデータファイルに一括で適用します。そのため、バックアップ開始や VSS 呼び出しの際には、4D はまずキャッシュをフラッシュし、データファイルが最新のデータを含むようにします。
次の重要な点は、使用中のデータファイルをコピーしても、うまくいかないということです。コピー処理中にデータファイルが変更されると、せっかくコピーしたデータファイルが破損していたり、データファイルとジャーナルやインデックスとの間に差異が生じたりする可能性があります。そこで、第2ステップとして、コピー処理中の書き込み操作を禁止して、データファイルをロックします。読み取り操作は引き続き可能ですが、書き込み操作をおこなおうとするプロセスはすべて、バックアップ / VSSスナップショットが終了するまでブロックされます。
最後に、ジャーナルについて説明します。ジャーナルには、前回のバックアップ以降におこなったすべての操作が記録されています。これは、主に 2つのケースで使用されます: データファイルが破損した場合、またはユーザーによる操作を元に戻したい場合です。データファイルの変更を 1つも失いたくない場合、このファイルは非常に重要です。
キャッシュがフラッシュされ、データファイルがロックされると、4Dバックアップは新しいジャーナルファイルを作成します (VSS はしません)。そして、データファイル、インデックスファイル、ジャーナルのコピーが済めば、データのロックを解除することができます。
このように、操作は非常に複雑です。そのため、全自動で安全な 4Dバックアップの利用を強くお勧めしています。しかし、中には独自のスナップショット機構を構築するデベロッパーもいらっしゃいます。そのような方々のために、4D の実行中にデータストアをロックする機能を提供します!
新機能: データストアのロック
ds.flushAndLock(), ds.locked(), ds.unlock() という、3つの新しいコマンドを追加しました。
ds.flushAndLock() は、キャッシュをフラッシュした後、他のプロセスに対してデータストアをロックします。データストアがロックされている間は、他のプロセスから来るすべての書き込み操作は、ロックが解除されるまで保留されます。つまり、データファイル、インデックスファイル、ジャーナルのいずれも変更されることがないため、これらが同期されているか、破損していないかを心配せずに、自由にコピーできます。
コピーが終わったら、同じプロセスで ds.unlock() を呼び出します。すると、データストアのロックが解除され、再び書き込み操作ができるようになります。
ds.locked() コマンドは、データストアが現在ロックされているかどうかを知るのに使います。
この 3つのコマンドで、4Dバックアップと VSS がコピーの前にデータストアをロックするのを再現することができるようになりました。
データフォルダーをアーカイブするコード
この新機能を説明するため、サンプルコードを紹介します。このコードは、データフォルダー (およびデータファイルとインデックスファイル) とジャーナルのアーカイブを実行します:
$destination:=Folder(fk documents folder).folder("Archive")
$destination.create() // アーカイブ先のフォルダー
ds.flushAndLock() // まずデータストアをロックし、他プロセスからの書き込み操作をブロックします
$dataFolder:=Folder(fk data folder)
$dataFolder.copyTo($destination) // データフォルダーをコピーします
$oldJournalPath:=New log file() // 新しいジャーナルを作成し、
$oldJournal:=File($oldJournalPath; fk platform path)
$oldJournal.moveTo($destination) // 古いジャーナルを移動します
ds.unlock() // コピー後、データストアのロックを解除します
短いサンプルコードですが、アーカイブが破損しないよう、いくつかの重要なステップを踏んでいます。キャッシュのフラッシュとデータストアのロックをおこない、新しいジャーナルを作成して古いジャーナルを保存し、そして操作終了とともにデータストアのロックを解除します。重要なステップを忘れないよう、このサンプルコードをベースに独自のスナップショット機構を構築することをお勧めします。
このブログ記事が、4Dバックアップの内部機能をよりよく理解するのに役立つことを願っています。
もちろん、質問やコメントがあれば、遠慮なくフォーラムにお寄せください。