Redis での AOF 永続性の分析例

1. AOF の概要

RDB は、キーと値のペアをデータベースに保存することでデータベースのステータスを記録できる永続化メソッドです。 AOF は、Redis サーバーによって実行された書き込みコマンドを記録することによってデータベースの状態を保存する永続化メソッドです。

たとえば、次のコマンドの場合:

RDB の永続化方法では、str1、str2、str3 の 3 つのキーと値のペアをRDB ファイル、および AOF 永続化により、実行された set、sadd、および lpush コマンドが AOF ファイルに保存されます。

2. AOF 設定

redis.conf 設定ファイルの APPEND ONLY MODE の下:

①、appendonly: デフォルト値は no です。これは、redis がデフォルトで rdb 永続性を使用することを意味します。AOF 永続性を有効にしたい場合は、appendonly を yes に変更する必要があります。

②、appendfilename：aof ファイル名、デフォルトは「appendonly.aof」です。

③、appendfsync：aof 永続化戦略の設定。

no は fsync を実行しないことを意味し、オペレーティング システムはデータがディスクに同期されることを保証します。これは最も高速ですが、あまり安全ではありません。

は常に fsync が実行されることを意味します。ディスクへのデータ同期を確保するために毎回書き込みを行うため、効率は非常に低くなります。

fsync を 1 秒に 1 回実行するオプション「everysec」では、この 1 秒以内にデータが失われる可能性があります。通常は、セキュリティと効率のバランスをとるために、毎秒を選択します。

④. no-appendfsync-on-rewrite: aof が書き換えられるか、rdb ファイルに書き込まれると、大量の IO が実行されます。このとき、everysec および always aof モードでは、fsync を実行すると、あまりにも長い間、no-appendfsync-on-rewrite フィールドはデフォルトで no に設定されます。アプリケーションに高い遅延要件がある場合は、このフィールドを [はい] に設定できます。そうでない場合は、永続化機能にとってより安全な選択である [いいえ] に設定します。これを「yes」に設定すると、再書き込み中に新しい書き込み操作が fsyncd されず、一時的にメモリーに保管され、再書き込みが完了した後に書き込まれます。デフォルトは「no」で、「yes」を推奨します。 Linux のデフォルトの fsync ポリシーは 30 秒です。 30 秒間のデータが失われる可能性があります。デフォルト値は「いいえ」です。

auto-aof-rewrite-percentage のデフォルト値は 100 です。 aof 自動書き換え設定では、現在の aof ファイル サイズが最後に書き換えられた aof ファイル サイズのパーセンテージを超えると、書き換えられます。つまり、aof ファイルが特定のサイズに増加すると、Redis は bgrewriteaof を呼び出してログ ファイルを書き換えることができます。 AOF ファイルのサイズが最後のログ書き換えのサイズ (100 に設定) の 2 倍に達すると、新しいログ書き換えプロセスが自動的に開始されます。

auto-aof-rewrite-min-size は 64MB に設定されています。合意されたパーセンテージに達したときに書き換える必要を避けるために、ファイルの最小サイズを設定できます。

⑦. aof-load-truncated: aof ファイルは最後に不完全である可能性があります redis が起動すると、aof ファイルのデータがメモリにロードされます。 Redis が配置されているホスト オペレーティング システムがダウンした後に、特に ext4 ファイル システムに data=owned オプションが追加されていない場合、再起動が発生することがあります。この現象は発生します。Redis のダウンタイムや異常終了によってテールが不完全になることはありません。 Redis を終了させるか、可能な限り多くのデータをインポートするかを選択します。 「はい」オプションを選択すると、ログは自動的にクライアントに送信され、切り詰められた aof ファイルがインポートされるときにロードされます。答えが「いいえ」の場合、ユーザーは redis-check-aof コマンドを手動で実行して AOF ファイルを修復する必要があります。デフォルト値は「はい」です。

3. AOF をオンにする

redis.conf の appendonly 設定を yes に変更します。

AOF がファイルを保存する場所は、RDB がファイルを保存する場所と同じであり、redis.conf 設定ファイルの dir を通じて設定されます:

config getを渡すことができます dirコマンドは保存されたパスを取得します。

4. AOF ファイルの回復

Redis を再起動すると、AOF ファイルがロードされます。

例外修復コマンド: redis-check-aof --fix を修復します

5. AOF の書き換え

AOF の永続化とは、Redis がファイル内の AOF への書き込みコマンドを継続的に記録することを意味するためです。 Redis が進化し続けるにつれて、AOF ファイルはますます大きくなり、ファイルが大きくなるほど、占有されるサーバー メモリも大きくなり、AOF の回復に必要な時間も長くなります。この問題を解決するために、Redis は新しい書き換えメカニズムを追加し、AOF ファイルのサイズが設定されたしきい値を超えると、Redis はデータを復元できる最小限の命令セットのみを保持して AOF ファイルのコンテンツ圧縮を開始します。コマンド bgrewriteaof を使用して書き換えることができます。

たとえば、次のコマンドの場合:

AOF ファイルが書き換えられない場合、AOF ファイルには 4 つの SADD コマンドが保存されます。使用すると、次のコマンドのみが AOF ファイルに保持されます:

1	悲しい動物 「犬」 「トラ」 「 「パンダ」 「ライオン」 「猫」

# #つまり、AOF ファイルの書き換えは元のファイルを再編成するのではなく、サーバーの既存のキーと値のペアを直接読み取り、その後 1 つのコマンドを使用して、以前にキーと値のペアを記録した複数のコマンドを置き換えて、次に、元の AOF ファイルを新しいファイルに置き換えます。

AOF ファイル書き換えトリガー メカニズム: redis.conf 構成ファイルの auto-aof-rewrite-percentage 経由: デフォルト値は 100、auto-aof-rewrite-min-size: 64mb 構成、つまり、デフォルトでは、Redis は最後に書き換えられたときに AOF サイズを記録します。

デフォルトの構成は、AOF ファイルのサイズが最後の書き換え後のサイズの 2 倍になり、ファイルが 64M より大きい場合にトリガーされます。

もう一度言いますが、Redis はシングルスレッドのジョブであることがわかっています。AOF の書き換えに時間がかかる場合、AOF の書き換え中に Redis他のコマンドを扱う場合、これは明らかに耐えられません。この問題を解決するために、Redis の解決策は、AOF 書き換えプログラムをサブルーチンに組み込むことであり、これには 2 つの利点があります:

① 子プロセスの AOF 書き換え中、サーバー プロセス (親プロセス) は続行できます。他のコマンドを処理しています。

子プロセスには親プロセスのデータのコピーがあるため、スレッドの代わりに子プロセスを使用すると、ロックの使用を回避し、データのセキュリティを確保できます。

サブプロセスを使用すると、上記の問題は解決されますが、新しい問題も発生します。サーバー プロセスは、サブプロセスの AOF 書き換えプロセス中に他のコマンドを処理しているため、この新しいコマンドは、サブプロセスに対する操作も実行する可能性があります。変更操作により、現在のデータベースのステータスと書き換えられた AOF ファイルのステータスが不一致になります。

データ状態の不一致の問題を解決するために、Redis サーバーは AOF 書き換えバッファーを設定します。このバッファーは子プロセスの作成後に使用されます。Redis サーバーが書き込みコマンドを実行すると、これが行われます。書き込みコマンドも AOF 書き換えバッファに送信されます。子プロセスは AOF 書き換えが完了すると親プロセスにシグナルを送信し、親プロセスがシグナルを受信すると、AOF 書き換えバッファーの内容を新しい AOF ファイルに書き込む関数を呼び出します。

これにより、サーバーに対する AOF 書き換えの影響が最小限に抑えられます。

6. AOF の長所と短所

利点:

①. AOF 永続化方式では、同期にデフォルトの同期頻度が使用される場合でも、さまざまな同期頻度が提供されます。 1 秒ごと Redis が一度に失うデータは最大でも 1 秒だけです。

②. AOF ファイルは Redis コマンドの append を使用して構築されるため、Redis が AOF ファイルにコマンドのフラグメントしか書き込めない場合でも、redis-check-aof ツールを使用して AOF ファイルを修正するのは簡単です。

AOF ファイルの形式は読みやすいため、ユーザーはファイルをより柔軟に処理できます。たとえば、誤って FLUSHALL コマンドを使用した場合、再書き込みが進行する前に、最後の FLUSHALL コマンドを手動で削除し、AOF を使用してデータを回復できます。

デメリット:

① 同じデータを持つ Redis の場合、通常、AOF ファイルは RDF ファイルよりも大きくなります。

AOF のデフォルトの同期頻度は 1 秒に 1 回ですが、さまざまな同期頻度オプションが提供されていますが、パフォーマンスは依然として高いです。 Redis の負荷が高い場合、RDB は AOF よりも優れたパフォーマンス保証を提供します。

③. RDB はスナップショットを使用して Redis データ全体を永続化しますが、AOF は実行された各コマンドを AOF ファイルに追加するだけであるため、理論的には RDB の方が AOF よりも堅牢です。公式ドキュメントによると、AOF には RDB にはないバグがいくつかあります。

それでは、AOF と RDB の永続化方法のどちらをどのように選択すればよいでしょうか?

短期間でのデータ損失を許容できる場合は、RDB を使用するのが最適であることに疑いの余地はありません。RDB スナップショットを定期的に生成すると、データベースのバックアップに非常に便利であり、RDB はデータセットをより高速に復元します。 AOF の回復速度は速く、RDB を使用すると AOF の隠れたバグも回避できます。そうでない場合は、AOF の書き換えを使用してください。ただし、通常は、特定の永続化メカニズムを単独で使用するのではなく、両方を一緒に使用することをお勧めします。この場合、redis が再起動されると、通常の状況ではデータセットが保存されるため、AOF ファイルが最初にロードされて元のデータが復元されます。 AOF ファイル内のデータ セットは、RDB ファイルに保存されたデータ セットよりも完全です。おそらく将来、Redis 担当者は 2 つの永続化メソッドを 1 つの永続化モードに統合するでしょう。

以上がRedis での AOF 永続性の分析例の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。