- RDB の永続性
RDB (Redis データベース) は、データをスナップショットの形式でディスクに保存します。いわゆるスナップショットは、特定の時点でデータセットの写真を撮り、保存することと理解できます。このように、Redis は指定された時間間隔で、または特定のコマンドが実行されたときに、現在のシステムのデータを保存およびバックアップし、バイナリ形式でディスクに書き込むことができます. デフォルトのファイル名は dump.rdb.
RDB トリガーには、save コマンドの実行、bgsave コマンドの実行、redis.config での自動化の構成の 3 つのメカニズムがあります。
トリガーを保存
Redis is a single-threaded program. このスレッドは、複数のクライアント ソケットの同時読み取りおよび書き込み操作と、メモリ構造の論理読み取りおよび書き込みを担当します。The save command will block the current Redis server. このコマンドの実行中、Redis は RDB プロセス全体が完了するまで他のコマンドを処理できません。この方法は、新しいマシンでのデータ バックアップには適していますが、本番環境で使用する場合、データ量が多すぎて、ブロック時間が長すぎて、大変なことになります。この方法はお勧めできません
bgsave トリガー
オンライン ビジネスを妨げないようにするために、Redis はクライアントの要求に応答している間も持続する必要があります。したがって、bgsave を実行すると、子プロセスを fork し、この子プロセスを使用して後続のすべての保存作業を処理できます。親プロセスは、I/O 操作を気にせずに要求に応答し続けることができます。
redis.config 構成
上記の 2 つの方法の両方とも、クライアントで save または bgsave コマンドを実行する必要があります. 本番環境では、自動トリガー メカニズムが必要なので、Redis はこのメカニズムを提供します. 設定のために redus.config で設定できます Persistence
RDB の長所と短所
アドバンテージ：
RDB は非常にコンパクトな (コンパクトな) ファイル (バイナリ データを保存する) であり、特定の時点での Redis のデータ セットを保存します。この種のファイルはバックアップに非常に適しています。たとえば、RDB ファイルを過去 24 時間ごとに 1 時間ごとにバックアップしたり、毎月 RDB ファイルをバックアップしたりできます。このようにして、問題が発生した場合でも、いつでもデータ セットを別のバージョンに復元できます。
RDB は Redis のパフォーマンスを最大化できます: RDB ファイルを保存するときに親プロセスがしなければならないことは、子プロセスを fork することだけです。その後、子プロセスは次のすべての保存作業を処理し、親プロセスはそれを行う必要はありません。ディスク I/O 操作を実行します。大規模なデータ セットを復元する場合、RDB は AOF よりも高速です。
短所:
サーバーに障害が発生した場合のデータ損失を回避する必要がある場合、RDB は適していません。Redis では、さまざまなセーブ ポイント (セーブ ポイント) を設定して RDB ファイルを保存する頻度を制御できますが、RDB ファイルはデータ セット全体の状態を保存する必要があるため、このプロセスは高速ではなく、保存に少なくとも 5 分かかる場合があります。 RDB ファイルの保存を完了します。この場合、障害が発生した場合に数分間のデータが失われる可能性があります。
2 つの AOF 永続性
AOF (Append Only-file) 永続化スキームは、その動作原理を簡単に説明しています。AOF ログは Redis サーバーの命令シーケンスを保存し、AOF はメモリを変更するための命令レコードのみを記録します。
サーバーが再起動すると、Redis は AOF ログに記録されたこれらの操作を使用して、元のデータ セットを再構築します。
Redis はクライアントから変更コマンドを受け取った後、パラメータを変更して論理的な処理を行い、問題がなければコマンドのテキストをすぐに AOF ログに保存する、つまりログを保存する前にコマンドを実行します。これは、最初にログを保存してから論理処理を行う leveldb や hbase などのストレージ エンジンとは異なります。
AOF トリガー構成
AOF にはさまざまなトリガー スキームもあります。次の 3 つのトリガー スキームについて簡単に説明します。
always: データの変更が発生するたびに、それはすぐにディスク ファイルに記録されます. この方式は完全性は良好ですが、IO オーバーヘッドが大きく、パフォーマンスが低下します。
everysec: 毎秒同期し、速度が向上しました。ただし、1 秒以内にダウンすると、この 1 秒以内のデータが失われる可能性があります。
no: デフォルトの構成、つまり AOF 持続性スキームは使用されません。
AOF書き換えの仕組み
Redisの運用に伴い、AOFのログがどんどん長くなっていきます.インスタンスがダウンして再起動すると、AOF全体を再生するのに非常に時間がかかります.ログの記録には、myデータを 1000 回インクリメントすると、これらの 1000 回の変更を記録する必要はなくなり、最後の値のみを記録する必要があります。そのため、AOF の書き換えが必要です。
Redis には、AOF ログを書き換える bgrewriteaof コマンドが用意されています. コマンドを実行すると、サブプロセスが開かれ、メモリを走査し、一連の Redis 操作命令に変換され、ログ ファイルにシリアル化されます。完成後、元のAOFファイルを差し替えて完成です。
AOF の長所と短所
アドバンテージ
AOF ファイルは、追加操作のみを実行するログ ファイル (追加のみのログ) であるため、何らかの理由でログに不完全なコマンドが含まれている場合でも (ディスクがいっぱいになった場合など)、AOF ファイルへの書き込みを求める必要はありません。 、途中で書くのをやめるなど）、 redis-check-aof ツールはこの種の問題を簡単に修正できます。
AOF ファイルのサイズが大きくなりすぎると、Redis はバックグラウンドで AOF を自動的に書き換えることができます。書き換えられた新しい AOF ファイルには、現在のデータセットを復元するために必要なコマンドの最小限のセットが含まれています。Redis は、新しい AOF ファイルを作成するプロセス中に、既存の AOF ファイルにコマンドを追加し続けるため、書き換え操作全体が完全に安全です. 書き換えプロセス中にシャットダウンが発生しても、既存の AOF ファイルは失われません. . 新しい AOF ファイルが作成されると、Redis は古い AOF ファイルから新しい AOF ファイルに切り替え、新しい AOF ファイルへの追加を開始します。
不利益
通常、AOF ファイルのボリュームは、RDB ファイルのボリュームよりも大きくなります。データの復元には時間がかかります。
トリプル ハイブリッド パーシステンス
Redis の再起動時に、RDB を使用してメモリの状態を復元すると、大量のデータが失われます。また、AOF ログ再生のみを使用すると、効率が低すぎます。Redis 4.0 は、RDB ファイルの内容と増分 AOF ログ ファイルを一緒に保存するハイブリッド永続化ソリューションを提供します。ここでの AOF ログは、もはや完全な量のログではなく、RDB 永続化の開始から永続化の終了までの期間に発生する増分 AOF ログであり、通常、ログのこの部分は非常に小さいです。
したがって、Redis の再起動時に、最初に RDB のコンテンツをロードしてから、増分 AOF ログを再生できます。これにより、以前の AOF の完全な再生が完全に置き換えられ、再起動の効率が大幅に向上します。