Redis持続化RDB&AOF
4302 ワード
1.なぜ永続化が必要なのか。
Redisの読み書きと応答速度はなぜこんなに速いのか.従来のリレーショナル・データベースとは異なり、Redisのデータベースはすべてリアルタイム・メモリにロードされており、読み書き操作はメモリで直接行うことができ、多くのIO操作を省くことができるため、パフォーマンスが非常に優れています.しかし、メモリに依存するすべてのサービスには、デバイスの障害(ブレークポイントなど)が発生すると、メモリ内のすべてのリアルタイムデータが失われる最大のリブがあります.この問題を解決するために、Redisでは、RDBとAOFの2つの持続的なスキームが提供されています.そのメカニズムは、実際には、メモリ内のデータをファイル形式でディスクにバックアップし、電源オフなどの機械的な障害によるデータ損失の問題を解決するために工夫されています.
2. RDB (Redis DataBase)
実装メカニズム:Redisは単独でサブプロセスを作成して永続化し、データを一時ファイルに書き込み、永続化プロセスが終了した後、最後に永続化されたファイル(dump.rdb)をこの一時ファイルに置き換えます.プロセス全体において、メインプロセスはIO操作を一切行わないので、Redisメインプロセスの持続的な高性能を保証することができる.データを復元すると、再起動するとRedisは作業ディレクトリの下のdumpを自動的にロードする.rdbファイルはメモリにデータを復元する
関連パラメータ:
## RDB dump , , , dump.rdb Redis , 。 save RDB
save
save 900 1 ## for
save 300 10 ## for
save 60 10000 ## for
## RDB ,Redis , yes
stop-writes-on-bgsave-error yes
## RDB LZF dump.rdb , yes
rdbcompression yes
## dump.rdb , CRC64 , RDB CPU 10%,
rdbchecksum yes
## , dump.rdb
dbfilename dump.rdb
## dump.rdb ,
dir ./
メリット:
劣勢:
PLUS:最後に永続化されたデータが失われる可能性があるのはなぜですか.
RDBはsave条件を設定することによりdumpをトリガし、いずれかのsave条件を満たした後にその条件を書き換える仕組みとなっているが、実際には最後のdumpで修正回数要求に達したものの、時間がまだ到達していないうちにredisプロセスが中止すると、この段階のデータが失われる可能性がある。 例えばsave 300 10という条件では、Redisの300 s内での修正操作回数が10回を超えるため、持続化条件がトリガーされ、システムは300 sが満期になった後にブラシ書きを行うが、満期の数秒前にデバイスが異常にシャットダウンする可能性があり、300 s内で発生したデータ修正情報はすべて失われる
3. AOF(Append Only File)
実装メカニズム:RDBの直接書き込み元データとは異なり、AOFはRedisの起動中のすべての書き込み操作を記録し、ログに類似しており、書き込み方式は末尾に追加することしか許されず、変更前に書き込む内容は許されず、デフォルトではappendonlyとして保存されている.aofファイル.データを復元すると、RedisはAOFをメモリにロードし、データの復元を実行します.
関連パラメータ:
## --
appendonly no
##
appendfilename "appendonly.aof"
##
appendfsync always ## , ,
appendfsync everysec ## , , , ,
append no ## , Redis
メリット:
劣勢:
Rewriteメカニズム:appendonly.aofファイルはますます大きくなる危険性があり、AOFはRewriteメカニズムを設定し、デフォルトはappendonlyである.aofファイルサイズが前回のRewriteに達した後appendonly.aofファイルのサイズが小さい場合、ファイルのサイズが64 Mを超えると、AOFはRewriteを起動し、forkは新しいプロセスを出して一時ファイルを作成し、データベース全体を遍歴し、各key、valueペアをRedisコマンドの形式で一時ファイルに出力します.このプロセスでは、複数のキー値のペアがセットされ、最終ファイルのサイズを小さくするために1つのコマンドで表現されます.rewrite期間中の書き込み操作はメモリのrewrite bufferに保存され、rewriteが成功するとこれらの操作も一時ファイルにappendされ、rewriteが完了するとappendonlyに代わる一時ファイルになる.aofファイル
## Rewrite -- and --
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
## appendfsync ? no,
no-appendfsync-on-rewrite no
4.まとめ
シーンを使用:
共存性:AOF機能をデフォルトでオフにするが、実質的にRDBとAOFは共存可能であり、Redisが同時にAOFとRDBの永続化をオンにすると、Redisが再起動するとAOFファイルを優先的に読み取り、データ復旧を行う.AOFはRDBよりもデータ整合性を保証するためである.さらに、Redisデータの復元には、AOFファイルまたはRDBファイルを読み込む必要があるため、これら2つのファイルが破損したり、悪意のある変更を受けたりすることを防止するために、Redisは2つの修復スクリプトを提供し、この2つのファイルを修復する
## AOF
redis-check-aof --fix appendonly.aof
## RDB
redis-check-dump --fix dump.rdb
安全性の拡張:実際の生産では、AOFでもRDBでも生成するappendonlyが必要である....rdbファイルをオフサイトでバックアップすることで、単一マシンの完全な破損によるデータのリカバリ不可能な問題を回避できます.