Redisの永続性の物語の背後にあります

Redisの持続性

Redisのは、別の永続性オプションを提供しています。

• RDBの永続データの時のスナップショットにそのポイントを保存するには、指定した時間間隔で。
• AOFの永続化方法は、各サーバーのレコードを受け取るに書き込みます。サーバーが起動すると、元のデータを復元するように、これらの操作の記録は、一つ一つ実行されます。保存するその他の方法にRedisの契約と一致して書き込みコマンド記録フォーマット。
• Redisのはあなただけでは、サーバーの稼働中に存在しているライフサイクルのデータを作ることができることを、時に永続的な無効にすることができます。
• Redisの再起動、AOFファイルがされたときに同時に存在することができますが、持続性の二つの方法优先のデータを再構築するために使用。

最も重要なことは、異なるAOFのRDBと持続性の違いを理解することです。

RDBの永続性

ファイルにRDBを作成し、ロード

RedisのRDBファイルを生成するために使用することができる2つのコマンドがあり、あるSAVEは、他のですbgsave。

SAVEコマンドRedisのサーバー・プロセスは、RDBファイルが作成されるまで、ブロックされたプロセス中に、サーバーが、サーバーは、任意のコマンド要求を処理することはできませんブロックされます。

そして、SAVEサーバプロセスに異なるアプローチをブロックするコマンドを直接、子プロセスを導出するBGSAVEコマンドは、その後、RDBファイルサーバ・プロセス（親プロセス）を作成するために、紫禁城の責任は、コマンド要求を処理し続けます。

RDBの利点

• RDBファイルには、時間のRedisのデータポイントを保存し、圧縮されたバイナリファイルです。RDBファイルには、バックアップのために理想的です。あなたは簡単に別のバージョンにデータをリストアするために必要なことができるときあなたは、RDBファイルアーカイブのための時間を設定することができます。
• RDBは理想的です災害復旧。リモートサーバーに簡単に単一のファイル転送。
• 必要性が持続するために、メインプロセスは、子プロセスをforkします、子への永続的な仕事は、彼らが上であると言われて、関連するI / O操作、持っていないときRDBのパフォーマンスは、非常に良いですbgsaveを。
• 大量のデータの場合はAOF、RDBより高速な起動を比較しました。

RDBの欠点

• データの損失を引き起こす可能性がRDB。Redisのは、何らかの理由で動作しない場合は5分ごとこの間に最後Redisの問題からのデータのスナップショットを生成し、その後、スナップショットを保存することを仮定すると失われます。上記SAVEの欠点。
• RDBは使用）（フォークを数ミリ秒のために利用できないのRedisで、その結果、時間のポイントを取る可能性のあるデータが比較的大きい場合には、データの永続化のために子供を生産します。データが大きく、CPUのパフォーマンスは、いつでも、より多くのサービス時間のうち、非常に良いではない場合。上記BGSAVEの欠点。

ファイルのパスと名前

デフォルトでは、現在のスナップショットファイルが保存されているだろうRedisの名前のディレクトリでdump.rdbファイルを。ファイルの保存パスと名前を変更するには、設定ファイルを変更することができますredis.conf達成するために：

# RDB文件名，默认为dump.rdb。
dbfilename dump.rdb

# 文件存放的目录，AOF文件同样存放在此目录下。默认为当前工作目录。
dir ./

ポイントを保存します（RDBは有効と無効）

データは、スナップショットファイルを保存した後RedisのM時間がN秒毎に変化したかのように、あなたは、セーブポイントを設定することができます。たとえば、次のような構成は、60秒ごとにセーブポイントを表すデータは、変更の1000倍以上を持っている場合、Redisのは、自動的にファイルのスナップショットを保存します。

save 60 1000

複数のセーブポイントを設定することができ、デフォルト設定にRedisのコンフィギュレーション・ファイルには、以下の3つのポイントを保存しました：

# 格式为：save <seconds> <changes>
# 可以设置多个。
save 900 1 #900秒后至少1个key有变动
save 300 10 #300秒后至少10个key有变动
save 60 10000 #60秒后至少10000个key有变动

あなたが保存したスナップショット機能を無効にしたい場合は、すべての「保存」、または最後に「保存」の設定後、次の設定を追加をコメントアウトすることによって達成するように構成することができます。

save ""

エラー処理

背景のスナップショットは、それがデータの受信を停止する時期のRedisが失敗した場合、デフォルトで、目的は、ユーザーがデータを永続的な成功ではないことを知らせることです。あなたはRedisのと持続性の状態を監視することができ、他の方法がある場合しかし、あなたは、この機能をオフに禁止することができます。

stop-writes-on-bgsave-error yes

データ圧縮

デフォルトのRedisが使用されLZFたデータを圧縮します。あなたは、CPUのパフォーマンスポイントを保存したい場合は、圧縮機能をオフに無効にすることができますが、データセットが圧縮されたときよりも再生されません。

rdbcompression yes

データ検証

RDBのバージョン5との最初からCRC64検証コードファイルの末尾に配置されます。だから我々は、文書の完全性を保証することができますが、保存またはロードすると、ファイルは、いくつかのパフォーマンス（約10％）を失うことになります。あなたがより高い性能を追求したい場合は、スワップを無効にすることができますので、使用するファイルのチェックサムを書き込む際0の代替を、ロード時間を確認するために0、それはチェックをスキップします。

rdbchecksum yes

AOFの永続性

スナップショットは、非常に信頼性がありません。お使いのコンピュータが突然停止した場合、または電源オフ、または誤ってプロセスを強制終了した場合、最新のデータが失われます。AOF文書は、より信頼性が高く、持続的な方法を提供します。Redisのは、データセットを変更します受信したコマンドたびに、コマンドでのRedis、AOFを再起動すると、コマンドは、AOFファイルに追加されるデータを再構築するために、再び実行されます。

ディスク上のファイルことを確認するために、コマンドのタイミングを同期させるために、同期オプションを設定するにはAOF永続的な必要性を使用してください。書き込みbのファイルがすぐにディスク上のコンテンツに同期しますが、バッファに第一号店、およびディスクに同期したときに、オペレーティング・システムによって決定されていないためです。以下の同期オプション：

オプション	同期周波数
常に	各書き込みコマンドが同期されています
everysec	1秒に1回の同期
いいえ	同期するタイミングを決定するために、オペレーティング・システムをしてみましょう

利点

• RDBより信頼性の高いです。あなたは異なるのfsync戦略を行うことができます。fsyncをせずに、毎秒ごとのクエリのfsync FSYNC。FSYNCのデフォルトは1秒に1回です。これは、データの1秒まで失うことを意味します。
• AOF追加のログファイルはプレーンファイルです。でも、突然の停電が発生し、ログの位置が表示されたり破損の問題はありません。さらにいくつかの理由のための唯一のログファイルに書かれた半コマンド（例えば、ディスクフルなど）場合、我々はまた、使用することができredis-check-aof、修復することは非常に簡単で、このツールを。
• AOFファイルが大きすぎる場合には、Redisのは、バックグラウンドで自動的に書き換えられます。書き換えは、新しいファイル上で行われるので、Redisのは、古いファイルのデータを追加していきますが、非常に安全で書き換えます。運用コマンドの最小セットは、現在のデータセットを再構築するために、新しいファイルを作成します。新しいファイルは体重を終了したら、Redisの古いものと新しいファイルがオンに切り替えて、新しいファイルへのデータの書き込みを開始します。
• ファイル形式次々に運転指令を理解しAOF簡単に保存され、データを復元するために導出することは容易です。たとえば、私たちはには注意されないFLUSHALLすべてのデータをはねのけるするコマンドは、限り、ファイルが上書きされていないとして、我々は削除するには、コマンドの最後の部分を停止し、サービスすることができますし、サービスを再起動しますので、あなたが戻ってデータ復旧をブラシを置くことができます。

短所

• RDBファイルよりも同じデータセットの下で、ファイルAOFのサイズは一般的に大きくなります。
• いくつかのfsync戦略では、AOF速度はRDBよりも遅くなります。通常、1秒に1回のfsync設定は、より高いパフォーマンスを得ることができるようになりますが、禁止のfsyncスピードの場合にはRDBのレベルに到達することができます。
• 過去には、我々は、元のデータの不整合で再構成データ利用AOFでいくつかの非常に珍しいBUG結果を発見しました。

AOFを有効にします

構成アイテムappendonlyにyes：

appendonly yes

ファイルのパスと名前

# 文件存放目录，与RDB共用。默认为当前工作目录。
dir ./

# 默认文件名为appendonly.aof
appendfilename "appendonly.aof"

確実

あなたはRedisのコール頻度のfsyncを設定することができ、3つのオプションがあります。

• fsyncを呼び出すときにするたびに新しいコマンドをAOFに加えます。最も遅いが、最も安全な。
• 1秒に1回のfsync。スピード（ほとんどのスナップショットスピードのような2.4版）は、セキュリティが（1秒のデータ損失まで）良いです。
• fsync、に対処するシステムを手渡したことはありません。最速の方法が、一般的にセキュリティを提供します。

FSYNCは、それが速かったので、セキュリティも良いですが、第二の方法（デフォルトモード）ごとに一度お勧めします。以下のような構成は以下のとおりです。

# appendfsync always
appendfsync everysec
# appendfsync no

ログの書き換え

増加の書き込み動作では、AOFファイルが大きくなります。たとえば、あなたがカウンタ100をインクリメントし、その後、最終的な結果は、増分データセットカウンタの最終的な結果ですが、AOFファイルは、レコード100回この操作実際に完了します。ライン上でこのレコードと実際には、一つだけのコマンドを回復するには、それは100 AOFファイルのコマンドは、実際に一つに合理化することができると言うことです。だから、Redisのは、このような機能をサポート：サービスを中断することなくバックグラウンドでAOFファイルを再構築します。

これは次のように動作します：

• Redisのは、フォーク（）を呼び出し、子プロセスを生成します。
• 一時ファイルに書き込まれた新しい子プロセスAOF。
• 障害がデータのセキュリティを確保するために書き換えることができても、メモリバッファではなく、古いAOFで書かれたこれらの新しい変化への新しい変更を書き込む、そうするには、メイン継続的なプロセス。
• ファイルの書き換え処理が終了した後、メイン処理信号を取得し、その後、バッファのメモリは、AOFをもたらす新規の子プロセスに添加されます。
• Redisの

私たちは、リライトの設定をロギングすることで条件を設定することができます。

# Redis会记住自从上一次重写后AOF文件的大小（如果自Redis启动后还没重写过，则记住启动时使用的AOF文件的大小）。
# 如果当前的文件大小比起记住的那个大小超过指定的百分比，则会触发重写。
# 同时需要设置一个文件大小最小值，只有大于这个值文件才会重写，以防文件很小，但是已经达到百分比的情况。

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

書き換えの自動ログ機能を無効にするには、我々は割合が0に設定されて置くことができます。

auto-aof-rewrite-percentage 0

Redisのが自動的に超える2.4を書き換えログすることができ、以前のバージョンを手動で実行する必要がありますBGREWRITEAOFこのコマンド。

データ破損の修理

何らかの理由（例えば、サーバのクラッシュなど）AOFファイルが破損している場合は、Redisの結果としては、ロードすることはできません、それは次の方法で修復することができます。

• AOFのバックアップファイル。

• 使用しredis-check-aof、元のAOFファイルを修復するためのコマンドを：

  $ redis-check-aof --fix

  

• あなたは使用することができるdiff -u2つの文書のコマンドの外観の違いを。

• 復元されたファイルを使用すると、Redisのサービスを再起動します。

AOFからRDBへの切り替え

ただ、ここで言うRedisのこと>メソッドのバージョン2.2 =：

• 新しいバックアップ・dump.rdbファイル、および安全な場所にバックアップファイルを置きます。

• 次の2つのコマンドを実行します。

  $ redis-cli config set appendonly yes
  $ redis-cli config set save ""

• データは事前​​にハンドオーバーと一致していることを確認してください。

• そのデータを確実にするために、適切に書かれたAOFファイルです。

2番目のコマンドは、永続モードのRDBを無効にするために使用されていますが、同時に持続的な2を有効にすることができますので、これは、必要ありません。

私は、構成ファイルを覚えてredis.conf設定を変更するためのコマンドラインを再起動Redisの後に無効となりますので、AOF有効な編集のために。

バックアップ

推奨バックアップ方法：

• スケジュールされたタスクを作成し、毎時間、毎日のスナップショットを作成し、異なるフォルダに保存されています。
• 、ファイルを削除するにはあまりにも古いタスクを実行するタイミング。たとえば、スナップショットの日まで2ヶ月に時間と1で作成された唯一の48時間のスナップショットを保持するためには、作成されました。
• 少なくともRedisのサーバーにサービスが配置されていない、セーブ保存するために、データセンター外の場所に転送スナップショットファイルことを保証するために一日一回。

参照

• [M]の黄Jianhong。Redisの設計と実装。機械工業プレス、2014。
• https://redis.io/topics/persistence