4

目的：

X回ごとにdump.rdbとY回ごとにappendonly.aofの両方のバックアップコピーを作成しようとしているので、何らかの理由でファイルが破損した場合（またはAOFのappendonly.aofファイルだけでも）、ダンプからデータを復元できます。 rdb.backup スナップショットと、私が持っている appendonly.aof.backup の最新のコピー以降に変更されたもの。

状況：

dump.rdb を 5 分ごとにバックアップし、appendonly.aof を 1 秒ごとにバックアップします。

問題:

1) dump.rdb はバックグラウンドで子プロセスによって一時ファイルに書き込まれているため、子プロセスが新しいイメージを作成している間に発生したキーの変更はどうなりますか? バックグラウンド書き込みに関係なく、AOF ファイルが追加され続けることはわかっていますが、新しい dump.rdb ファイルにも重要な変更が含まれていますか?

2) dump.rdb にキーの変更が含まれていない場合、子プロセスがフォークされている正確なポイントを特定する方法はありますか? そうすれば、AOF ファイルに最新の情報が含まれる時点を追跡できます。

ありがとう！

4

1 に答える 1

2

通常、永続化戦略として RDB または AOF のいずれかを使用します。両方持つと結構な値段になります。5 分ごとにダンプを実行し、1 秒ごとに aof ファイルをコピーすると、非常に頻繁に聞こえます。Redis インスタンスが少量のデータしか保存しない場合を除いて、ボックスの I/O サブシステムを強制終了する可能性があります。

さて、あなたの質問に関して：

1) RDBメカニズムのセマンティック

ダンプ メカニズムは、クローン/フォーク プロセス時に最新の OS カーネルによって実装されたコピー オン ライト メカニズムを利用します。フォークが完了すると、システムはページ テーブルをコピーしてバックグラウンド プロセスを作成するだけです。ページ自体は 2 つのプロセス間で共有されます。Redis プロセスによってページで書き込み操作が行われた場合、OS は透過的にページを複製します (Redis インスタンスが独自のバージョンを持ち、バックグラウンド プロセスが以前のバージョンを持っているため)。したがって、バックグラウンド プロセスでは、メモリ構造が一定に保たれる (したがって一貫性がある) ことが保証されます。

その結果、フォーク後に開始された書き込み操作はダンプに取り込まれません。ダンプは、フォーク時に取得された一貫性のあるスナップショットです。

2) 分岐点の追跡

INFO 永続化コマンドを実行し、rdb_last_save_time - rdb_last_bgsave_time_sec を計算することで、フォークのタイムスタンプを推定できますが、あまり正確ではありません (秒のみ)。

もう少し正確 (ミリ秒) にするために、Redis ログ ファイルを解析して次の行を抽出できます。

[3813] 11 Apr 10:59:23.132 * Background saving started by pid 3816

これらの行を表示するには、少なくとも「通知」ログ レベルが必要です。

私の知る限り、AOF の特定のエントリを RDB の fork 操作に関連付ける方法はありません (つまり、100% 正確にすることはできません)。

于 2013-04-11T09:05:03.623 に答える