Redisデータ永続化技術解説

RDB (レディス・データベース)

1. RDBとは
メモリ上のデータセットを指定した間隔でディスクに書き込み、スナップショットとも呼ばれ、スナップショットファイルを直接メモリに読み込むことで復旧する。
Redisは永続化のために別の子プロセスを作成（フォーク）し、一時ファイルにデータを書き込み、永続化プロセスがすべて終了した時点で、最後に永続化したファイルをこの一時ファイルに置き換えます。大規模なデータ復旧が必要で、データ復旧の完全性があまり重視されない場合、RDBアプローチはAOFアプローチよりも効率的です。RDBの欠点は、最後の永続化の後にデータが失われる可能性があることです。

2. Forkの役割。
Forkの役割は、現在のプロセスと同じプロセスをコピーすることです。新しいプロセスは、元のプロセスと同じデータ（変数、環境変数、プログラムカウンタなど）の値をすべて持っていますが、完全に新しいプロセスであり、元のプロセスの子として動作します。

3. Rdbはdump.rdbファイルを保存します。

4. RDB スナップショットを起動する方法
(1) 設定ファイルのデフォルトのスナップショット設定：コールドコピー後の再利用（cp dump.rdb dump_new.rdbでOK)。
(2) コマンドセーブまたはbgsave。保存は、ちょうど関係なく、すべてのブロッキング残りを保存します。bgsaveは、redisは非同期にバックグラウンドでスナップショット操作を行います、スナップショットは、同時にクライアントのリクエストに応答することができます。lastsaveコマンドで最後にスナップショット実行が成功した時刻を取得することができます。
(3) flushallコマンドを実行してもdump.rdbファイルは生成されるが、空っぽで意味がない。

5. 復元する方法 バックアップファイル（dump.rdb）をredisのインストールディレクトリに移動し、サービスを開始するだけです。

6、メリット 大規模なデータ復旧に適している。高いデータ整合性と一貫性を必要としない。

7, デメリット 一定時間ごとにバックアップを取るため、redisが突然ダウンした場合、最後のスナップショット以降のすべての変更が失われる。 フォークがメモリ内のデータのコピーでクローンされるため、およそ2倍の肥大化を考慮する必要がある。

8. 停止方法 Dynamic all stop RDB save rule method: redis-cli config set save ""。

概要

1. RDBは非常にコンパクトなファイルです。
2、RDBがRDBファイルを保存する時に親プロセスがすべきことは、子プロセスをフォークアウトすることだけで、次の作業はすべて子プロセスが行い、親プロセスは他のIO操作をする必要がないので、RDB永続化方式はredisの性能を最大化させることができます。
3. AOFと比較して、RDBアプローチは大規模なデータセットを再度復元する際に高速になります。
4、データ消失のリスクが高い。
5, RDBはデータセットをハードディスクに保存するために、頻繁にフォークサブプロセスが必要です。データセットが大きい場合、フォーク処理は非常に時間がかかり、あるミリ秒レベルでRedisがクライアントのリクエストに応答できなくなる可能性があります。

AOF (アペンド・オンリー・ファイル)

1. AOFとは：Redisが行った全ての書き込み操作のログです（読み込み操作はログに残りません）。ファイルの追記のみ可能で、ファイルの書き換えはできず、redisの先頭のファイルを読み込んでデータを再構築することが可能です。その

2. rewriteとは。AOFはファイルアペンディングを採用しており、ファイルがどんどん大きくなっていきます。これを避けるため、新たに書き換えの仕組みを追加し、AOFファイルのサイズが設定した閾値を超えると、RedisはAOFファイルの内容の圧縮を開始し、データを復元できる最小限の命令セットだけを残し、これはbgrewriteaofコマンドで実行できるようになりました。

3. 書き換えの原理：AOFファイルが大きくなりすぎた状態が続くと、ファイルを書き換えるために新しいプロセスがフォークされ（最初に一時ファイルを書き、最後に名前を変えることも）、新しいプロセスのメモリ内のデータを、1レコードにつき1つのセット文でトラバースしていきます。aofファイルの書き換えは、古いaofファイルを読み込まず、メモリ内のデータベースの内容を全て新しいaofファイルにコマンドで書き換えるので、スナップショットポイントに似ている。

4. 書き換えのトリガー機構。Redisは前回の書き換え時のAOFのサイズを記録しており、デフォルトの設定ではAOFのファイルサイズが前回の書き換え時の2倍、ファイルサイズが64MBを超えるとトリガーがかかるようになっています。

5. メリット
(1）秒単位の同期：appendfsyncは常にデータの変更が発生するたびに永続性を同期させ、すぐにディスクに記録され、パフォーマンスが低下していますが、データの整合性が向上しています。
(2) 変更ごとの同期：appendfsync everysec 非同期動作、1秒ごとのロギング 1秒以内にダウンした場合、データ損失がある。
(3) 同期しない：appendfsync no 同期されない。

6. デメリット
(1) aofファイルは、同じデータセットのデータに対してrdbファイルよりはるかに大きく、リカバリ速度がrdbより遅い。
(2) AOFの動作はrdbより遅く、秒単位の同期化ポリシーはより効率的で、非同期化もrdbと同程度に効率的です。

概要

1. AOFファイルは、アペンド・オンリーのログファイルです。
2. Redisは、AOFファイルが大きくなりすぎた場合、バックグラウンドで自動的に書き換えることができます。
3. AOFファイルには、データベースへの書き込みがすべて整理して保存され、これらの書き込みはRedisプロトコル形式で保存されるため、AOFファイルの内容は非常に読みやすく、分析しやすくなっています。
4. 同じデータセットであれば、通常、AOFファイルのサイズはRDBファイルのサイズより大きくなります。
5, 使用するfsyncポリシーによっては、AOFはRDBより遅くなることがあります。

2つのアプローチのまとめ

1. RDB永続化アプローチでは、指定された間隔でデータのスナップショット保存が可能です。
2. AOF永続化方式は、サーバーに書き込まれたすべての操作を記録し、サーバーの再起動時にこれらのコマンドを再実行して元のデータを復元するため、AOFファイルはバックグラウンドで書き換えられ、サイズが大きくなることはない。
3. キャッシュのみ：サーバーが動作している間だけデータを存在させたい場合、永続化メソッドを使用しないことも可能です。

<リンク