問題タブ [journaling]

おそらくmongodumpを使用して、単一のmongodbデータベースを毎日バックアップしたいと考えています。データを失わないように、これをインクリメンタルにしたいので、その日の途中で何か問題が発生した場合、mongorestore を実行した後、障害が発生するまでその日の変更を再生できる必要があります。

これには oplog を使用する必要があることを正しく理解していますか? それともジャーナリングが答えですか？私は次のことを試しました：

1. 私のmongoデータベースを1つのレプリカセットに変えて、oplogを作成します。（これはかなりハックな気がします）
2. --oplog オプションを使用して mongod を再起動する
3. oplog に記録する必要がある変更の実行

ただし、oplog には何も保存されません。このような増分バックアップを行う最善の方法は何ですか? 私は基本的に、mysql binlog を再生するための同様のアプローチを探しています。

ありがとう

ライトバック モードでは、inode データのみがジャーナルに書き込まれ、ファイル データがいつ書き込まれるかは制御されません。

この行は、通常の場合にデータがデバイスに書き込まれるタイミングと、データが失われるタイミングを考えさせられました。

Writeback モードでは、ジャーナリングの直後にデータをデバイスに強制的に書き込むオプションはありますか?

また、ライトバックモードとオーダーモードはこれだけで区別されるのでしょうか?

ローカルデバイスのテストから、iOSファイルシステムにファイルを書き込むと（使用する呼び出しのレベルがどれほど低いかに関係なく）、ファイルがフラッシュに完全にコミットされる前に成功が返されることがよくあります。つまり、デバイスをハードリセットしてから再起動すると、ファイルがロールバックされるか（書き込みが完了したか、アトミックであった場合）、破損する可能性があります。この遅延の原因は何ですか（ドキュメントはありがたいですが、何も見つかりませんでした）。実際のファイルシステムの書き込みが完了したときにフィードバックを得る方法はありますか。たとえば、リモートサーバーからのデータの受信と保存を確認したいのですが、書き込みの「レポート」の成功後に確認すると、ハードクラッシュや電源障害が発生した場合にデータが失われる可能性があります。

ユーザーがアップロードしたファイルに基づいて一連のタスクを実行する ac# アプリケーションを開発します。これには数秒から数日かかる場合があります。プロセスが中断された場合に作業を再開するために、何らかのログ システムを実装する予定です。この中断/再開のログは何と呼ばれ、既存の実装についてどこで詳しく知ることができますか?

編集：

これまでに見つけた便利なもの：

ジャーナリングされたファイル システムは、同じ基本的な手順を使用し、いくつかの追加手順を使用します。何かのようなもの：

• ジャーナル項目: A から B へのファイルの移動
  • 古いファイルを新しい場所に物理的にコピーする
  • 新しいドライブのディレクトリ エントリを更新する
  • 古いドライブからディレクトリ エントリを削除する
  • 古いドライブの空き容量
• 仕訳入力: ファイルを A から B に移動しました

https://serverfault.com/questions/173176/what-is-a-journaling-file-systemから

チェックポイント: ジャーナル化されたメタデータとデータを固定の場所に書き込むプロセスは、チェックポイントと呼ばれます。チェックポイントは、さまざまなしきい値を超えたときにトリガーされます。たとえば、ファイル システムのバッファー スペースが少ない場合、ジャーナルに空きスペースがほとんど残っていない場合、またはタイマーが期限切れになった場合です。

クラッシュ リカバリ: ext3 でのクラッシュ リカバリは簡単です (多くのジャーナリング ファイル システムと同様)。REDO ロギングの基本的な形式が使用されます。新しい更新 (データまたはメタデータのみ) はログに書き込まれるため、ファイル システム構造をインプレースに復元するプロセスは簡単です。リカバリ中、ファイル システムはログをスキャンして、コミットされた完全なトランザクションを探します。不完全なトランザクションは破棄されます。完了したトランザクションの各更新は、単純に固定位置の ext2 構造に再生されます。

http://research.cs.wisc.edu/adsl/Publications/sba-usenix05.pdf (5 ページ)から

編集2：

この質問を最初に投稿したときよりも、耐障害性について多くのことを知っているようには感じませんが、実装したものの概要を次に示します。

ジョブ マネージャーが既存の保存された状態をファイルからロードすることを最初に試みるか、新しい空のマネージャーを作成します。

JobManager クラスは次のようになります。

注意事項:

• 誰かがこれをコピーしようとした場合に備えて、これは不完全なコードです (基本クラスやものが欠落しています)
• 通常の (バイナリ) シリアル化と XML シリアル化はまったく正しく機能しなかったため、オブジェクトを XML として保存するカスタム シリアル化を実装しました。これがメソッドであり、引数ToXElement()を取るコンストラクタです。XElement
• シリアル化の最上位 (JobManager) にチェックサム (SHA-256) が含まれています。新しいオブジェクトが からインスタンス化されるXElementと、保存されたシリアル化オブジェクトのチェックサムがファイル内のチェックサムと比較されます。
• .Load(file)ファイルを読み取って内容をデシリアライズしようとすることで、新しい JobManager オブジェクトを返す静的メソッドがあります。
• カスタム ConcurrentQueue クラスはここには示されていません。これは MSDN ConcurrentQueueクラスのラッパーですが、キューが変更されたときに通知するイベントが追加されています。
• この JobManager クラスは、前述の ConcurrentQueue を持つ基本クラスを実装します。これらのキュー変更イベントは、コンストラクター ヘルパーにフックされます
• イベントが発生すると、JobManager はフラグを設定します。_isDirty
• JobManager はインスタンス化時にスレッドを開始し、_isDirtyフラグを監視します。ほとんどの時間はスリープに費やされますが、少なくとも_minTimeToSave経過した場合、JobManager の内容はディスクにシリアライズされます。これにより、JobManager が頻繁にディスクに書き込むことがなくなります。

対処されていない注意事項:

• スレッドは本当に_isDirtyフラグを監視するための正しい解決策ですか?
• JobManager (単一のスレッド) は、タスクを含むジョブ (一度に 1 つずつ、ただし別のスレッド) を管理します。シリアル化中に状態をロックするためのクラスからベースクラスへの同期はありません
• 完了した古いジョブはディスクにシリアル化されてから再ロードされます

背景: CentOS 6.3(Final) 64bits と Ext4 ファイル システムに以下の 2 つの rpm パッケージをインストールしました -

• mongo-10gen-2.2.1-mongodb_1.x86_64.rpm
• mongo-10gen-server-2.2.1-mongodb_1.x86_64.rpm

以前の動作: mongod の初回起動時に、指定したフォルダーに事前に割り当てられたジャーナル ファイルが作成されません。余談ですが、ジャーナル オプションはデフォルトで有効になっています。

質問: 通常のケースですか? MongoDBのマニュアルをレビューします。それは主張する

ジャーナル ファイルが存在しない場合、mongod の起動時に、新しいジャーナル ファイルを事前に割り当てる必要があります。

以下にmongod関連のmongo.confを投稿しました-

構成:

前もって感謝します。

プログラマーの皆さん、こんにちは。

WinIoCtl関数を使用して、 NTFSパーティションのUSNジャーナルの内容をダンプしようとしています。* USN_JOURNAL_DATA *構造体があり、最大サイズが512MBであることを示しています。私はそれをfsutilがそれについて言わなければならないことと比較しました、そしてそれは同じ値です。

次に、各エントリを*USN_RECORD*構造体に読み込む必要があります。これは、0から始まり、ジャーナルの最大サイズ（4096（クラスターサイズ）単位）に達するforループで行います。同じサイズのバッファ内の各4096バイトを読み取り、そこからすべてのUSN_RECORD構造体を読み取りました。

最近のレコードが欠落しているように見えることを除いて、すべてが順調に進んでおり、ファイル名も正しく、タイムスタンプも、理由もすべてです。パーティションに新しいファイルを作成し、そこに何かを書き込んでから、ファイルを削除します。アプリを再度実行しましたが、レコードが表示されません。ジャーナルの最大サイズを超えて読み続けた場合にのみ、レコードが表示されることがわかりました。どうしてそれができるのでしょうか？

現時点では、ジャーナルのデータの先頭から最大サイズ+割り当てデルタ（どちらも* USN_JOURNAL_DATA *構造に格納されている値）まで読んでいますが、これは正しいとは思わず、徹底的に見つけるのに苦労しています。これに関連する情報。

誰かがこれを説明できますか？USNジャーナルの周りにMFTの動作と同様のバッファがありますか（他のファイルにディスクスペースが必要な場合はサイズが半分になることを意味します）？

私は何が間違っているのですか？

私の状況: 私は、ジャーナルを作成しない方法で IBM-i でファイルを作成した多くの RPG プログラマーと仕事をしています。db2 jdbc ドライバーを使用してファイルに接続し、更新、挿入などを行う Grails アプリを作成しました。次のエラーが表示されます。

STRJRNPF を使用してファイルのジャーナリングを開始できることはわかっていますが、それについていくのはやめておきます (叱らないでください)。コミットしようとしないことを知らせるために設定できるdb2 jdbc接続URLのパラメーターはありますか?

現在の接続情報は次のとおりです。

編集：これが私が試したことです：

私はAccessデータベースを使用していて、フォームを介して行われた変更を追跡するツールを見つけました。テーブルを介して直接行われた変更を追跡することはできないことは理解していますが、SQL更新ステートメントを介して行われた変更を追跡できるかどうかを確認するのに苦労しましたか？不可能だと思いますが、どうしたらいいか考えていただければ幸いです。多分マクロを通して？

ありがとう！

MongoDB のフォールト トレランスに関する記事をいくつか読んでいますが、MongoDB では実現できないと不満を言う人もいます (この記事のように: http://hackingdistributed.com/2013/01/29/mongo-ft/ )。これは混乱しました。

ドライバーによって成功と報告された書き込みの 100% が永続的に書き込まれ、そうでないことを確認するには、書き込み懸念 "Journal + Majority" を使用するだけで十分であることを誰かが確認できますか (可能であれば適切なドキュメントを見せてください)。書き込み直後にレプリカに障害が発生した場合でも失われますか?

私は3つのレプリカのセットアップについて話しています。障害が発生した場合にシステムが書き込みを受け入れなくなっても問題ありませんが、ドライバーによって書き込みが成功したと報告された場合は、永続的にコミットする必要があります (その後失敗したレプリカの数に関係なく)。

If I set journal_size_limit = 67110000 (64 MiB) will I be able to:

1. work with / commit transactions over that value (somewhat unlikely)
2. be able to successfully perform a VACUUM (even if the database has like 3 GiB or more)

The VACUUM command works by copying the contents of the database into a temporary database file and then overwriting the original with the contents of the temporary file. When overwriting the original, a rollback journal or write-ahead log WAL file is used just as it would be for any other database transaction. This means that when VACUUMing a database, as much as twice the size of the original database file is required in free disk space.

It's not entirely clear in the documentation, and I would appreciate if someone could tell me for sure.