redis持続化スキームの紹介


基本的な紹介


今回のプレゼンテーションで使用したredisバージョンは3.2.100で、オペレーティングシステムはwin 10です.
redisは、RDBおよびAOFの2つの永続化スキームをサポートし、前者はデフォルトで開き、後者は手動で開く必要がある.プロファイルを使用してこれを検証します.
RDBデフォルトオープン
save 900 1
save 300 10
save 60 10000

この3つの構成は、RDSがスナップショットをトリガする条件であり、それらの意味はそれぞれ:
  • ,900秒以内に1つの書き込みがある場合、スナップショット
  • が生成される.
  • ,300秒以内に1000回書き込みがある場合、スナップショット
  • が生成される.
  • 60秒以内に10000回書き込みがある場合、スナップショット
  • が生成される.
    もちろん、rdbスナップショットをトリガする条件はこれだけではありません.以下で説明します.
    AOFデフォルトオフ
    appendonly no

    RDB紹介


    RDBの方式は、トリガ条件を満たす場合、メモリ内のデータをディスクにバイナリで書き込む保存であり、デフォルトで保存するファイルをdumpと呼ぶ.rdb(変更可能)は、redisが再起動されると、ファイルを読み出してデータ復旧を行う.

    スナップショットファイルの情報の表示

    127.0.0.1:6379> config get dbfilename
    1) "dbfilename"
    2) "dump.rdb"
    127.0.0.1:6379> config get dir
    1) "dir"
    2) "C:\\redis-6379"
    127.0.0.1:6379>

    RDBスナップショット条件のトリガ


    上記の指定時間内に書き込み回数トリガを指定することに加えて、redisがRDBスナップショットを実行するようにトリガする場合もいくつかあります.
  • 手動でsave(同期ブロック)またはbgsave(非同期ブロック)コマンド
  • を実行する.
  • flushallコマンド
  • を実行
  • redisは終了し、shutdownコマンド
  • を実行する.
    次に、最初のケースを示します.ここではinfo Persistenceコマンドを使用して、永続化情報を表示します.
    127.0.0.1:6379> info persistence
    # Persistence
    loading:0
    rdb_changes_since_last_save:0
    rdb_bgsave_in_progress:0
    rdb_last_save_time:1561595205
    ...    
    127.0.0.1:6379> save
    OK
    127.0.0.1:6379> info persistence
    # Persistence
    loading:0
    rdb_changes_since_last_save:0
    rdb_bgsave_in_progress:0
    rdb_last_save_time:1561595940
    ...    
    127.0.0.1:6379>

    注意rdb_last_save_timeフィールドは、saveコマンドが永続化をトリガーしたことを示します.

    AOF紹介


    AOFを実証するために、AOFスイッチを手動でオンにし、redisを再起動する必要があります.
    AOFは、Redisが実行する書き込みコマンドをディスクファイル(appendonly.aof)に追加し、AOFが開いている場合は、redis起動時にAOFファイルからデータを復元することを優先します.

    関連構成


    スイッチに加えて、AOFに関する構成は以下の通りです.
    appendfilename "appendonly.aof"   #      
    # appendfsync always    #         
    appendfsync everysec    #   1 
    # appendfsync no        #          ,            ,     aof
    
    no-appendfsync-on-rewrite  yes:   #    rdb      ,      aof
    auto-aof-rewrite-percentage 100   #aof              ,   100% ,  
    auto-aof-rewrite-min-size 64mb    #aof  ,    64M ,   

    書き換えメカニズム


    先に述べたAOFの過程を通じて、賢いあなたは1つの問題を考えるかもしれません.AOFは絶えずファイルに命令を追加して、そのファイルはますます大きくなるのではないでしょうか.時間が長くなるとディスク空間にも負担になります.
    redisの作者が思わなかったと思いますか?redisはこの問題を解決するために書き換えメカニズムを導入した.上の配置の最後の2つは実は書き換えのトリガ条件で、はっきり言って意味は:
    AOFファイルサイズが前回rewrite以降のサイズの倍であり、ファイルサイズが64 Mより大きい場合にトリガーされる
    上記の条件トリガに加えて、AOFは手動トリガ(bgrewriteaofコマンド)もサポートしています.以下、このコマンドで書き換えを実証します.
    λ redis-cli.exe
    127.0.0.1:6379> bgrewriteaof
    Background append only file rewriting started
    127.0.0.1:6379>

    起動ログ:
    [18268] 27 Jun 09:23:41.282 # Server started, Redis version 3.2.100
    [18268] 27 Jun 09:23:41.282 * The server is now ready to accept connections on port 6379
    [18268] 27 Jun 09:24:03.236 * Background append only file rewriting started by pid 18740
    [18268] 27 Jun 09:24:03.388 * AOF rewrite child asks to stop sending diffs.
    [18268] 27 Jun 09:24:03.488 # fork operation complete
    [18268] 27 Jun 09:24:03.489 * Background AOF rewrite terminated with success
    [18268] 27 Jun 09:24:03.491 * Residual parent diff successfully flushed to the rewritten AOF (0.00 MB)
    [18268] 27 Jun 09:24:03.496 * Background AOF rewrite finished successfully

    まとめ

  • 持続化を使用する場合は、RDBとAOFの両方がオンになり、二重保障されることを推奨します.AOFは優先的に実行され、実行に失敗した場合はRDB
  • もある
  • RDBは大規模なデータ・リカバリに適していますが、最後のバックアップで
  • ダウンタイムが発生する可能性があるため、AOFには適していません.
  • RDB相対AOF比較占有メモリ
  • 注目公衆番号:サイ飼育員の技術ノート
    個人ブログ:http://www.machengyu.net
    csdnブログ:https://blog.csdn.net/pony_ma...
    思No:https://segmentfault.com/u/ma...