1.RDB AOF の違い
RDB 永続性とは、指定された時間間隔内でデータ セットのスナップショットをメモリにディスクに書き込むことを指します。 、子プロセスをフォークし、最初にデータ セットを一時ファイルに書き込みます。書き込みが成功すると、前のファイルが置き換えられ、バイナリ圧縮を使用して保存されます。
具体的な操作: ハッシュ テーブルをスキャンし、コピー オン ライトを使用して、DB ダンプ全体を保存します。
save、shutdown、slave コマンドがこの操作をトリガーします。
特徴: 粒度が比較的大きいため、以前に保存、シャットダウン、スレーブクラッシュが発生すると、途中の操作を復元できません。
AOF 永続性は、サーバーによって処理されたすべての書き込みおよび削除操作をログ形式で記録します。クエリ操作は記録されませんが、テキストで記録されます。ファイルを開いて詳細な操作記録を確認できます。 Redis は、AOF ファイルのサイズがデータ セットの状態を保存するために必要な実際のサイズを超えないように、バックグラウンドで AOF ファイルを書き換えることもできます。 Redis は、AOF 永続性と RDB 永続性を同時に使用することもできます。この場合、Redis が再起動すると、AOF ファイルを使用してデータセットを復元することが優先されます。これは、AOF ファイルによって保存されたデータセットは、通常、RDB ファイルによって保存されたデータセットよりも完全であるためです。永続性をオフにして、サーバーの実行中にのみデータが存在するようにすることもできます。
特徴: 粒度が小さく、クラッシュ後は、クラッシュ前にログを記録する時間がなかった操作のみを回復できません。
選択基準は、キャッシュ一貫性 (aof) を高める代わりにシステムがある程度のパフォーマンスを犠牲にするかどうか、または書き込み操作が頻繁に行われる場合はパフォーマンスを上げる代わりにバックアップを有効にしない意思があるかどうかを確認することです。 . 手動になります 保存を実行する際は、バックアップ(rdb)を作成してください。 RDB には、より結果的に一貫した意味があります。
2. AOF RDB の長所と短所
AOF:
長所: AOF 永続性を使用すると、Redis の耐久性が非常に高くなります (耐久性が大幅に向上): さまざまな fsync 戦略を設定できます。 fsync なし、1 秒に 1 回の fsync、書き込みコマンドが実行されるたびに fsync など。 AOF のデフォルト ポリシーは、fsync を 1 秒に 1 回実行することですが、この構成でも Redis は良好なパフォーマンスを維持でき、障害が発生した場合でも、失われるデータは最大 1 秒だけです (fsync はバックグラウンド スレッドで実行されます)。そのため、メインスレッドはコマンド要求の処理に懸命に取り組み続けることができます)。 AOF ファイルは追加操作のみを実行するログ ファイル (追加のみのログ) であるため、何らかの理由 (ディスクへの書き込みがいっぱいである場合など) でログに不完全なコマンドが含まれている場合でも、AOF ファイルへの書き込みにシークは必要ありません。 、書き込みが途中で停止するなど）、redis-check-aof ツールでもこの問題を簡単に解決できます。
Redis は、AOF ファイルのサイズが大きくなりすぎると、バックグラウンドで AOF を自動的に書き換えることができます。書き換え後の新しい AOF ファイルには、現在のデータ セットを復元するために必要な最小限のコマンド セットが含まれています。 Redis は新しい AOF ファイルの作成プロセス中に既存の AOF ファイルにコマンドを追加し続けるため、書き換え操作全体は完全に安全です。書き換えプロセス中にシャットダウンが発生した場合でも、既存の AOF ファイルは失われません。 。新しい AOF ファイルが作成されると、Redis は古い AOF ファイルから新しい AOF ファイルに切り替えて、新しい AOF ファイルへの追加を開始します。 AOF ファイルには、データベースに対して実行されたすべての書き込み操作が順序どおりに保存されます。これらの書き込み操作は、Redis プロトコルの形式で保存されます。そのため、AOF ファイルの内容は非常に読みやすく、ファイルの分析も簡単です。 （解析）。 AOF ファイルのエクスポート (エクスポート) も非常に簡単です。たとえば、誤って FLUSHALL コマンドを実行した場合でも、AOF ファイルが上書きされていなければ、サーバーを停止し、AOF の最後にある FLUSHALL コマンドを削除するだけです。ファイルを削除し、Redis を再起動すると、データセットを FLUSHALL が実行される前の状態に復元できます。
欠点:
同じデータ セットの場合、通常、AOF ファイルのサイズは RDB ファイルのサイズよりも大きくなります。 使用する fsync 戦略によっては、AOF は RDB よりも遅くなる可能性があります。通常の状況では、1 秒あたりの fsync のパフォーマンスは依然として非常に高く、 あり、fsync をオフにすると、高負荷下でも AOF が RDB と同じくらい高速になります。 ただし、RDB は、巨大な書き込み負荷を処理する場合に、より保証された最大レイテンシを提供できます。 AOF には過去にこのようなバグがありました。個別のコマンドのせいで、AOF ファイルをリロードすると、データ セットを保存時の元の状態に復元できなくなりました。 (たとえば、ブロッキング コマンド BRPOPLPUSH はかつてそのようなバグを引き起こしました。) この状況に備えてテストがテスト スイートに追加されました。ランダムで複雑なデータ セットを自動的に生成し、これらのデータをリロードして、すべてが正常であることを確認します。この種のバグは AOF ファイルでは一般的ではありませんが、それに比べて、RDB でこの種のバグが発生することはほとんどありません。
RDB の利点:
RDB は、特定の時点での Redis データ セットを保存する非常にコンパクトなファイルです。 この種類のファイルはバックアップに非常に適しています。たとえば、過去 24 時間の 1 時間ごとに RDB ファイルをバックアップしたり、毎月毎日 RDB ファイルをバックアップしたりできます。こうすることで、問題が発生した場合でも、いつでもデータ セットを別のバージョンに復元できます。 RDB は災害復旧に最適です。ファイルは 1 つだけで、内容は非常にコンパクトで、(暗号化後に) 他のデータセンターや Amazon S3 に転送できます。 RDB は Redis のパフォーマンスを最大化できます。RDB ファイルを保存するときに親プロセスが行う必要があるのは、子プロセスをフォークアウトすることだけです。その後、子プロセスが後続の保存作業をすべて処理し、親プロセスはこれを行う必要はありません。ディスク I/O 操作を実行します。大規模なデータ セットを復元する場合、RDB は AOF よりも高速です。
欠点:
サーバー障害時のデータ損失を回避する必要がある場合、RDB は適していません。 Redis では、さまざまなセーブポイントを設定して RDB ファイルを保存する頻度を制御できますが、RDB ファイルはデータセット全体の状態を保存する必要があるため、これは簡単な操作ではありません。したがって、少なくとも 5 分に 1 回は RDB ファイルを保存できます。この場合、障害が発生すると、数分間のデータが失われる可能性があります。 RDB が保存されるたびに、Redis は子プロセスを fork() する必要があり、子プロセスが実際の永続化作業を実行します。データ セットが大きい場合、fork() は非常に時間がかかり、サーバーが特定のミリ秒以内にクライアントの処理を停止する可能性があります。データ セットが非常に大きく、CPU 時間が非常に厳しい場合は、この停止時間が長くなる可能性があります。もっと長くても、まるまる1秒間。 AOF書き換えにもfork()が必要ですが、AOF書き換えの実行間隔がどれだけ長くてもデータの耐久性が損なわれることはありません。