Redisの持続化について詳しく説明する。
1、概要
Redisはメモリデータベースであり、メモリ中のデータをディスクに保存できないとサーバプロセスが終了すると、サーバのデータベースデータも消えてしまうので、Redisは耐久化機能を提供しています。以下のいくつかの特徴があります。
1.RDB耐久化方式は、指定された時間間隔であなたのデータをスナップショットで保存することができます。
2.AOF耐久化方式はサーバに書いた操作ごとに記録し、サーバーが再起動するとこれらのコマンドを実行して元のデータを復元し、AOFコマンドはRedisプロトコルで追加保存します。毎回書いた操作はファイルの最後まで保存します。RedisはAOFファイルのバックグラウンドにも書き換えられます。AOFファイルの体積はそれほど大きくないです。
3.もしあなたがサーバでデータを実行する時だけ存在することを望むならば、あなたもいかなる持久化の方式を使わなくてもいいです。
4.あなたも同時に二つの長期化方式を開けてもいいです。この場合、redisが再起動されると、優先的にAOFファイルをロードして元のデータを復元します。通常の場合、AOFファイルに保存されているデータセットは、RDBファイルに保存されているデータセットよりも完全です。
2、RDB
1、概念
指定された時間間隔でメモリ中のデータセットをディスクにスナップショットで書き込み、復元するときはスナップショット中のファイルを直接メモリに読み込む。
2、持久化メカニズム-BGS AVE
通常、すぐにOKに戻ります。Redisプロセスはfork操作でサブプロセスを作成します。Redisはforkの時、親プロセスはクライアントにサービスを提供し続けます。子プロセスはデータをハードディスクに永続化してから終了します。保存をバックグラウンドで実行していたり、バックグラウンドで保存されていない他のプロセスを実行していたり、AOF書き込みを行っていたりすると、エラーが発生します。bgsaveタスクを使用してAOF書き込みを行っている場合、このコマンドはすぐにokに戻り、次の機会にはバックグラウンドで保存する予定です。渋滞はfork段階だけです。
クライアントは、lastsaveコマンドを使用して操作が成功したかどうかを確認することができます。
3、持久化メカニズム-SAVE
クライアントからの操作コマンドは受け付けません。耐久化作業が完了すると、古いファイルに新しいファイルを置換します。
4、持久化メカニズム-自動トリガ
私たちのredis起動ディレクトリにrdbファイルを置くだけでいいです。redis起動時に自動的にファイルをチェックして、データを復元します。
6、長所 RDBは非常にコンパクトなファイルで、ある時点でデータセットを保存しています。データセットのバックアップにとても適しています。例えば、毎時新聞に過去24時間のデータを保存して、毎日30日間のデータを保存してください。問題があっても、必要に応じて異なるバージョンのデータセットに戻すことができます。 RDBはコンパクトな単一ファイルで、他のリモートデータセンターやアマゾンのS 3(暗号化可能)に転送しやすく、非常に災難回復に適しています。 RDBファイルを保存する時、父プロセスが唯一しなければならないのはforkである。次の仕事は全部子プロセスでやり、父プロセスは他のIO操作をする必要がないので、RDB耐久化方式はredisの性能を最大化することができる。 は、AOFと比べて、大きなデータセットを復元するときには、RDDB方式がより速くなります。 7、欠点レディスが不意に仕事を停止したい場合(例えば電源が切れている場合)、紛失したデータが一番少ないとRDBはあなたに合わないです。別のセーブポイントを設定できますが(例えば5分ごとにデータセットに100個の書き込みがあります)、Redisはデータセット全体を完全に保存するのが大変です。通常は5分ごとかそれとももっと長い間ごとに完全に保存します。もしRedisの意外なあたまであれば、数分間のデータを失うかもしれません。 RDBは常にforkサブルーチンをハードディスクに保存する必要があり、データセットが大きい場合、forkのプロセスは非常に時間がかかり、一部のミリ秒以内にクライアントの要求に応答できなくなる可能性がある。データセットが巨大でCPUの性能がよくない場合は、この場合は1秒、AOFもforkが必要ですが、ログファイルを書き換える頻度を調節してデータセットの耐久度を高めることができます。 3、AOF
1、概念
ログの形式で各書き込み操作を記録し、Redisが実行したすべてのコマンドを記録し(読み取り操作は記録しない)、ファイルを追加してもファイルを書き換えてはいけないので、Redis起動の最初にこのファイルを読み込み、データを再構築します。つまり、Redisを再起動するとログファイルの内容に応じて書き込みのコマンドを前から後まで一回実行してデータの復旧作業を完了します。
2、持久化の原理
すべての操作のコマンドがファイルに追加されます。
3、AOFの持続化を開く always 同期の耐久性は、データ変更が発生するたびにすぐにハードディスクに耐久化され、性能は悪いが、データの完全性は良い。 everrysec 非同期動作は、毎秒の耐久化データをハードディスクに一回、一秒のデータを失うことがあります。 no ハードディスクに耐久化しません。
5、AOFファイルの破損
aofファイルが破壊されたら、redisサービスは起動できません。redis自体は修復ツールを提供しています。は構成によって異なる戦略に従って、恒久化の方式を選択させます。 AOFファイルは一つの追加のログファイルですので、seekに書き込む必要はありません。いくつかの理由で(ディスクの空き領域がいっぱいで、書いている間にあたごなど)書き込みコマンドが完全に実行されていなくても、redis-check-aofツールを使ってこれらの問題を修復することができます。 Redisは、AOFファイルの体積が大きすぎると、自動的にバックグラウンドでAOFを書き換えることができる。書き換えた新しいAOFファイルは、現在のデータセットを復元するために必要な最小コマンドセットを含む。書き込み全体は絶対安全です。Redisは新しいAOFファイルを作成する過程で、既存のAOFファイルにコマンドを追加し続けます。書き換え中に停止が発生しても、既存のAOFファイルは失われません。新しいAOFファイルの作成が完了すると、Redisは古いAOFファイルから新しいAOFファイルに切り替わり、新しいAOFファイルの追加操作を開始します。 AOFファイルはデータベースに対して実行されたすべての書き込み操作を規則的に保存しています。これらの書き込み操作はRedisプロトコルの形式で保存されていますので、AOFファイルの内容は非常に読みやすく、ファイルを分析するのも楽です。エクスポート(export)AOFファイルも非常に簡単です。例を挙げると、FLUSHALLコマンドを不用意に実行しましたが、AOFファイルが書き換えられていない限り、サーバーを停止し、AOFファイルの末尾にあるFLUSHALLコマンドを削除し、Redisを再開することで、FLUSHALL実行前の状態に戻すことができます。 6、欠点は、同じデータセットに対して、AOFファイルの体積は、通常、RDBファイルの体積より大きい。 使用するfsyncポリシーにより、AOFの速度がRDBより遅くなる可能性があります。一般的には、毎秒fsyncの性能は非常に高く、fsyncをオフにすることで、AOFの速度をRDBと同じように速くすることができ、高負荷下でもこのようにすることができる。ただし、巨大な書き込みを処理してロードする場合、RDBはより保証された最大遅延時間を提供することができる。 4、どのように恒久化機構を選ぶか
二つの持久化方式をオープンして、自分の業務ニーズに応じてredisに対して配置の調整を行います。
ここでは、Redisの永続化について詳しく解説した文章を紹介します。これまでの記事を検索したり、下記の関連記事を見たりしてください。これからもよろしくお願いします。
Redisはメモリデータベースであり、メモリ中のデータをディスクに保存できないとサーバプロセスが終了すると、サーバのデータベースデータも消えてしまうので、Redisは耐久化機能を提供しています。以下のいくつかの特徴があります。
1.RDB耐久化方式は、指定された時間間隔であなたのデータをスナップショットで保存することができます。
2.AOF耐久化方式はサーバに書いた操作ごとに記録し、サーバーが再起動するとこれらのコマンドを実行して元のデータを復元し、AOFコマンドはRedisプロトコルで追加保存します。毎回書いた操作はファイルの最後まで保存します。RedisはAOFファイルのバックグラウンドにも書き換えられます。AOFファイルの体積はそれほど大きくないです。
3.もしあなたがサーバでデータを実行する時だけ存在することを望むならば、あなたもいかなる持久化の方式を使わなくてもいいです。
4.あなたも同時に二つの長期化方式を開けてもいいです。この場合、redisが再起動されると、優先的にAOFファイルをロードして元のデータを復元します。通常の場合、AOFファイルに保存されているデータセットは、RDBファイルに保存されているデータセットよりも完全です。
2、RDB
1、概念
指定された時間間隔でメモリ中のデータセットをディスクにスナップショットで書き込み、復元するときはスナップショット中のファイルを直接メモリに読み込む。
2、持久化メカニズム-BGS AVE
通常、すぐにOKに戻ります。Redisプロセスはfork操作でサブプロセスを作成します。Redisはforkの時、親プロセスはクライアントにサービスを提供し続けます。子プロセスはデータをハードディスクに永続化してから終了します。保存をバックグラウンドで実行していたり、バックグラウンドで保存されていない他のプロセスを実行していたり、AOF書き込みを行っていたりすると、エラーが発生します。bgsaveタスクを使用してAOF書き込みを行っている場合、このコマンドはすぐにokに戻り、次の機会にはバックグラウンドで保存する予定です。渋滞はfork段階だけです。
クライアントは、lastsaveコマンドを使用して操作が成功したかどうかを確認することができます。
3、持久化メカニズム-SAVE
クライアントからの操作コマンドは受け付けません。耐久化作業が完了すると、古いファイルに新しいファイルを置換します。
4、持久化メカニズム-自動トリガ
redis.conf
では、ユーザがsave
属性をカスタマイズして、サーバに時間ごとにbgsave
操作を実行させるように構成することができる。
# 900 , 1
save 900 1
# 300 , 10
save 300 10
# 60 , 10000
save 60 10000
# bgsave , yes
stop-writes-on-bgsave-error yes
# LZF ?
rdbcompression yes
# rdb , yes
rdbchecksum yes
# RDB
dbfilename dump.rdb
#
dir ./
5、データ構造を復元する私たちのredis起動ディレクトリにrdbファイルを置くだけでいいです。redis起動時に自動的にファイルをチェックして、データを復元します。
6、長所
1、概念
ログの形式で各書き込み操作を記録し、Redisが実行したすべてのコマンドを記録し(読み取り操作は記録しない)、ファイルを追加してもファイルを書き換えてはいけないので、Redis起動の最初にこのファイルを読み込み、データを再構築します。つまり、Redisを再起動するとログファイルの内容に応じて書き込みのコマンドを前から後まで一回実行してデータの復旧作業を完了します。
2、持久化の原理
すべての操作のコマンドがファイルに追加されます。
3、AOFの持続化を開く
# aof , no
appendonly no
# aof
appendfilename "appendonly.aof"
#
# appendfsync always
appendfsync everysec
# appendfsync no
4、3つのトリガー耐久化メカニズム5、AOFファイルの破損
aofファイルが破壊されたら、redisサービスは起動できません。redis自体は修復ツールを提供しています。
redis-check-aof --fix appendonly.aof
5、長所二つの持久化方式をオープンして、自分の業務ニーズに応じてredisに対して配置の調整を行います。
ここでは、Redisの永続化について詳しく解説した文章を紹介します。これまでの記事を検索したり、下記の関連記事を見たりしてください。これからもよろしくお願いします。