5

ファイルがリモートディスクに保持され、VMware キャッシュ、NAS キャッシュなどを通過していることを確認するための「トリック」または「ハック」を探しています。

FileOutputStream をフラッシュして閉じるだけでは不十分です。Channel.force(true) はどちらでもないと思います。

私は次のようなことを考えています：

  • ファイルに書き込み、ファイルを読み戻す
  • ファイルの書き込み、タイムスタンプの確認、ファイルの名前変更、別のタイムスタンプの確認
  • 「間違った内容」でファイルを書き込み、元の内容で上書きし、読み返し、内容を確認する

誰かが同じ問題を抱えていて、解決策を見つけたのかもしれません。

私の要件は、データを失わないことです。Java アプリケーションは次のように動作します。

  1. リモート ソースからファイルを受け入れる
  2. デジタル署名と認定されたタイムスタンプを追加して、新しいファイルを作成します。このファイルが失われると、どのような方法でも再作成できなくなります。
  3. このファイルをストレージに書き込む
  4. ファイルをデータベース上で署名済みとしてマークする
  5. すべてが問題ないことをリモート側に伝えます

今夜、クラッシュが発生し、ステップ 5 の後、データが実際にリモート ストアにフラッシュされる前に 3 つのトランザクションが失敗しました。したがって、データベースはすべて問題ないと言います。リモート側にも同じことが伝えられましたが、15 秒間の署名付きデータが失われました。そして、これは良くありません。

正しい解決策は、リモート ファイル システムの「同期マウント」を実行することです。しかし、これは短期間で実現するものではありません。この場合でも、アプリが VMWare サーバー上で実行されていることを考えると、このシナリオを完全に信頼することはできません。

ですから、このようなインシデントを防止 (軽減) するための「ベスト エフォート ハック」が必要です。

4

1 に答える 1

2

1 つの仮定から始めましょう。単一のディスクへの単一の書き込みを保証することはできません。書き込みとディスク プラッターの間には、ソフトウェアとハ​​ードウェアのレイヤーが多すぎます。また、書き込みを保証できたとしても、データが読み取り可能であることを保証することはできません。書き込みと読み取りの間にディスクがクラッシュする可能性があります。

唯一の解決策は、フレームワーク (RDMS など) またはアプリによって提供される冗長性です。

ファイルを受信して​​署名したら、異なる物理ホスト上の複数の送信先に送信し、ファイルを保存したという返信を待つ必要があります。そのうちの 1 つがクラッシュする可能性があります。そのうちの 2 つがクラッシュする可能性があります。データの重要性によって、必要なリモート ホストの数が決まります。

ちなみに、冗長性はデータベースにも適用されます。トランザクションがコミットされたという事実は、データベースがクラッシュした後にそれを回復できるという意味ではありません (DBMS エンジニアは、書き込みを確実にすることに関して、あなたや私よりも多くの経験を持っていますが、すべてを理解しているシステム管理者に依存しています) 「ログとデータファイルは別々の物理ドライブに存在する必要があります。データベースエントリを再構築できるように、ファイルとともに十分なメタデータを (冗長的に) 保存することを強くお勧めします。

于 2012-10-02T16:28:55.880 に答える