redis(17):持続化-RDB方式

5024 ワード

Redisの強力なパフォーマンスは、すべてのデータがメモリに格納されているためですが、Redisが再起動すると、メモリに格納されているすべてのデータが失われます.
場合によっては、Redisが再起動後にデータが失われないことを保証することを望んでいます.たとえば、次のようにします.
  • Redisをデータベースとして使用する場合.
  • Redisはキャッシュサーバとして使用されますが、キャッシュが貫通するとパフォーマンスに大きな影響を及ぼし、すべてのキャッシュが同時に失効するとキャッシュ雪崩が発生し、サービスが応答できなくなります.

  • このとき、Redisはメモリから何らかの形でハードディスクにデータを同期させ、再起動後にハードディスクの記録に基づいてデータを復元できるようにしたいと考えています.この過程は持続化である.
    Redisは、RDB方式とAOF方式の2つの方式の持続化をサポートする.前者は、指定されたルール“ ” に従い、後者は にある.2つの永続化方式はいずれかを単独で使用することができるが、より多くの場合、両者を組み合わせて使用する.
    一、概説
    RDB方式の永続化はスナップショットによって行われ、`が一定の条件を満たすとRedisはメモリ内のすべてのデータのコピーを自動的に生成してハードディスクに格納し、このプロセスは「スナップショット」である.
    Redisは、次のような状況でデータをスナップショットします.
  • は構成規則に従って自動スナップショットを行う.
  • ユーザーはSAVEまたはBGSAVEコマンドを実行する.
  • FLUSHALLコマンドを実行します.
  • がレプリケーションを実行する場合.
  • save 900 1 
    save 300 10 
    save 60 10000
    

    各スナップショット条件は1行を占め、saveパラメータで始まります.同時に複数の条件が存在し、条件間は「または」の関係である.この例では、save 900 1は、15分(900秒)以内に1つ以上のキーが変更された場合にスナップショットを行うことを意味する.同様に、save 300 10は、300秒以内に少なくとも10個のキーが変更された場合にスナップショットを行うことを示す.
    二、構成規則による自動スナップショット
    Redisでは、スナップショットの条件をカスタマイズできます.スナップショットの条件に一致すると、Redisはスナップショット操作を自動的に実行します.
    スナップショットを行う条件は、 M Nの2つのパラメータから構成され得る.時刻Mにおいて変更されるキーの個数がNより大きい場合、自動スナップショット条件に合致する.たとえば、Redisインストールディレクトリに含まれているサンプルプロファイルにあらかじめ設定されている3つの条件:
    三、ユーザーはSAVE或いはBGSAVEコマンドを実行する
    Redisにスナップショットを自動的に実行させるほか、サービスの再起動、手動移行、バックアップを行う場合にも、スナップショット操作を手動で実行する必要があります.Redisはこのタスクを完了するために2つのコマンドを提供した.
  • SAVEコマンドSAVEコマンドSAVEコマンドを実行すると、Redisは同期してスナップショット操作を行い、スナップショット実行中にクライアントからの要求をすべてブロックする.このプロセスは、データベース内のデータが比較的多い場合にRedis , になります.
  • BGSAVEコマンドでスナップショットを手動で実行する必要がある場合は、BGSAVEコマンドを推奨します.BGSAVE , .BGSAVEを実行すると、RedisはすぐにOKに戻り、スナップショットの実行を開始することを示します.スナップショットが完了したかどうかを知りたい場合は、LASTSAVE を使用して、
  • などのUnixタイムスタンプを返すことができます.
    redis> LASTSAVE 
    (integer) 1423537869
    

    四、FLUSHALLコマンドを実行する FLUSHALL ,Redis .データベースを空にするプロセスが自動スナップショット条件をトリガーしたかどうかにかかわらず、 ,Redis であることに注意してください.
    たとえば、定義されたスナップショット条件が1秒以内に10,000個のキーを変更したときに自動スナップショットを実行し、データベースに1つのキーしかない場合、FLUSHALLコマンドを実行してもスナップショットがトリガーされます.このプロセスで実際に1つのキーだけが変更されても.
    自動スナップショット条件が定義されていない場合、FLUSHALLを実行してもスナップショットは行われません.
    五、複製を実行する時 ,Redis が設定されると、自動スナップショットが行われる.
    ここでは、レプリケーション操作を使用する場合、自動スナップショット条件が定義されておらず、手動でスナップショット操作が実行されていない場合でも、RDBスナップショットファイルが生成されることを理解する必要があります.
    六、スナップショットの原理
    Redisがスナップショットを実装するプロセスを整理することは、スナップショットファイルの特性を理解するのに役立ちます.Redisのデフォルトでは、スナップショットファイルはRedisの現在のプロセスの作業ディレクトリにあるdumpに格納されます.rdbファイルでは、dir dbfilenameの2つのパラメータを構成して、スナップショットファイルの格納パスとファイル名をそれぞれ指定できます.
    スナップショットの手順は次のとおりです.
  • Redisはfork関数を使用して現在のプロセス(親プロセス)のコピー(サブプロセス)をコピーします.
  • 親プロセスはクライアントからのコマンドを受信し、処理し続け、サブプロセスはメモリ内のデータをハードディスク(HDD)の一時ファイルに書き込むことを開始する.
  • サブプロセスがすべてのデータを書き込むと、古いRDBファイルが一時ファイルに置き換えられ、このスナップショット操作が完了します.

  • ヒントforkが実行されると、オペレーティングシステム(クラスUnixオペレーティングシステム)は書き込み時レプリケーション(copy-on-write)ポリシーを使用します.すなわち、fork関数が発生した瞬間の親子プロセスは同じメモリデータを共有し、親プロセスが書き込みコマンドを実行するなどのデータを変更すると、オペレーティングシステムはサブプロセスのデータが影響を受けないようにコピーします.したがって、新しいRDBファイルはforkを実行する瞬間のメモリデータを格納します.
    書き込み時のレプリケーションポリシーは、forkの時点で2つのメモリコピーが生成されているように見えますが、実際にはメモリの使用量が2倍にならないことを保証します.これは、システムメモリが2 GBしかなく、Redisデータベースのメモリが1.5 GBである場合、forkを実行してもメモリ使用量が3 GB(物理メモリを超える)に増加しないことを意味します.このため、Linuxシステムは、/etc/sy sctl.conf vm.overcommit_memory = 1でシステムを再起動するかsysctl vmを実行する方法で、アプリケーションが利用可能なメモリ(物理メモリと交換パーティション)を超える空間を申請できることを確保する必要がある.overcommit_memory=1設定が有効であることを確認します.
    また、スナップショットの実行中に書き込み操作が多いとfork前後のデータ差が大きくなり、メモリの使用量が実際のデータサイズを著しく上回ることに注意してください.メモリには現在のデータベースデータだけでなく、fork時刻のメモリデータも保存されているからです.メモリ使用量の推定では、この問題を無視しやすく、メモリ使用量が限界を超えています.
    上記の手順により、Redis RDB は、スナップショットが終了してから古いファイルを新しい、すなわち RDB に置き換えることができる.これにより、RDBファイルを定期的にバックアップすることで、Redisデータベースのバックアップを実現できます.RDBファイルは圧縮(rdbcompressionパラメータを構成して圧縮を無効にしてCPU占有を節約できる)されたバイナリ形式であるため、メモリ内のデータサイズよりも消費されるスペースが小さく、伝送に有利である.
    Redisが起動するとRDBスナップショットファイルが読み込まれ、ハードディスク(HDD)からメモリにデータがロードされます.この時間は、データ量の大きさや構造、サーバのパフォーマンスによって異なります.通常、1000万個の文字列タイプキーを記録し、1 GBサイズのスナップショットファイルをメモリにロードするのに20~30秒かかります.RDB方式で永続化を実現し、Redisが異常終了すると、最後のスナップショット以降に変更されたすべてのデータが失われます.これは,開発者が具体的な応用場面に応じて,自動スナップショット条件を組み合わせて設定することで発生する可能性のあるデータ損失を許容できる範囲に制御する必要がある.たとえば、Redisを使用してキャッシュ・データを格納する場合、最近数秒のデータが失われたり、最近更新された数十個のキーが失われたりしても、大きな影響はありません.データが相対的に重要である場合、損失を最小限に抑えることが望ましい場合、AOF方式を用いて永続化することができる.