ディレクトリ
序文
我々は、任意のソフトウェアまたはハードウェア障害が発生していない独自のサーバーに十分な自信を持っている場合でも、Redisのサーバーがメモリである知っているが、データのRedisサーバ障害の原因となる、突然の電源障害が発生する可能性があるでしょう。したがって、我々は、データのバックアップのために、従来のリレーショナル・データベースに同じで、メモリ内のRedisのデータは、データの信頼性を確保するために、ハードディスクなどの不揮発性媒体に永続化する必要があります。
サーバー内のデータRedisのメモリは、それが再起動した後、弊社のサーバーは、前のデータを再利用する、またはシステム故障を防止し、遠隔地にデータをバックアップするためにできることであるハードディスクなどのメディアの利益のために持続しました。
以下のようないくつかのシナリオがあります：
对于一些需要进行大量计算而得到的数据，放置在Redis服务器，我们就有必要对其进行数据的持久化，如果需要对数据进行恢复的时候，我们就不需进行重新的计算，只需要简单的将这台机器上的数据复制到另一台需要恢复的Redis服务器就可以了。
Redisのは、2つの異なる方法で永続化方法を提供してくれます：スナップショット（スナップショットで）だけ追加したファイル（追加のみファイル）。
（1）はじめに名詞
スナップショット（RDB）：私たちは、一般的にバックアップとして知られているものです、彼はあなたのハードドライブにRedisのサーバー永続データの中に定期的にデータをバックアップすることができます。
ただ、アペンドファイル（AOF）：彼はハードドライブの内部をコピーするには、書き込みコマンドをコマンドを記述し、後半の回復は、それだけでこの書き込みコマンドを見て行く必要があります。使用して、時間のマスターコピーを行ってから、私たちのMySQLデータベースと同様にbinlog、バイナリファイルを、同じ書き込みコマンドを再度実行します。
（2）持続的なスナップショット共通の構成：
save 60 1000 #60秒时间内有1000次写入操作的时候执行快照的创建stop-writes-on-bgsave-error no #创建快照失败的时候是否仍然继续执行写命令rdbcompression yes #是否对快照文件进行压缩dbfilename dump.rdb #如何命名硬盘上的快照文件dir ./ #快照所保存的位置
（3）AOP永続構成。
appendonly no #是否使用AOF持久化appendfsync everysec #多久执行一次将写入内容同步到硬盘上no-appendfsync-on-rewrite no #对AOF进行压缩的时候能否执行同步操作auto-aof-rewrite-percentage 100 #多久执行一次AOF压缩auto-aof-rewrite-min-size 64mb #多久执行一次AOF压缩dir ./ #AOF所保存的位置
注：これらの2つの永続的を単独で使用することができるが、また、どの方法の具体的な選択は、特定の状況に応じて選択するように、同時に使用することができます。
スナップショットの永続性
私たちは、バックアップと呼ぶもののスナップショット。ユーザーデータは、スナップショットが作成された後、ユーザーがバックアップスナップショットすることができ、ある時点でRedisのメモリをバックアップすることができます。一般的に、すべてのデータが失われ、単一サーバーの障害を防ぐために、我々は、同じデータ、この場合は、データ復旧やサーバーの再起動してデータのコピーを作成し、別のサーバーにスナップショットをコピーすることができます使用することができたときにこれらのスナップショット情報のリカバリデータは、あなたはまた、データの単一のサーバーに障害が発生した損失を防ぐことができます。
道のスナップショットを作成することですしかし、我々は完全にスナップショットを作成するとき、我々はうまくので、必ずしもすべての更新操作を作成するタイミングで、これを理解することができます私たちのデータが失われないことを保証するものではありません、注意を払う必要がなかったですスナップショット。システムがクラッシュした場合、ユーザーはすべてのデータのスナップショットを生成するために、最新の変更後に失われます。そのため、永続的なデータのスナップショットだけでなく、あまり頻繁に変更やデータの欠落している一部のシーンに影響を与えるために適しています。
まず、道のスナップショットを作成します。
Redisのクライアントを送信することにより、（1）BGSAVE スナップショットコマンドを作成します。
使用BGSAVE時間は、Redisのは、子プロセスを作成するためにフォークを呼び出して、親プロセスがプロセスのコマンド要求に継続している間に子プロセスは、ハードディスクに書き込まれたスナップショットを担当しています。
使用シナリオ：
次のような設定の保存を使用する場合：save 60 1000 最近のスナップショットが作成された後のRedisから算出した条件が満たされたときに、「1000の書き込み操作が60秒以内にある」とき、それは自動的にBGSAVE Redisのコマンドをトリガします。
あなたはセーブセット以上を使用している場合は任意の時間の条件を満たすように設定を保存するとき、そして、RedisのはBGSAVEコマンドをトリガします。
Redisのクライアントを送信することにより、（2）SAVE snapshotコマンドを作成します。
スナップショットが作成される前に、Redisのサーバーは、他のコマンドからのすべての要求に応答しませんSAVEコマンドを受信します。SAVEコマンドが使用されていない、我々はそこではない場合にのみ、通常BGSAVEコマンドを実行するための十分なメモリは、SAVEコマンドを使用します、あるいは例持続待つの完成である事は、このコマンドの操作を使用しますしません。
使用シナリオ：
Redisの要求は、SHUTDOWNコマンドオフサーバーが受信した場合、標準信号TERMを受信したとき、または、それがクライアントから送信された任意のコマンドを実行していない、すべてのクライアントをブロックし、SAVEコマンドを実行し、SAVEコマンドを実行しますサーバをシャットダウンした後。
第二に、永続的なスナップショットノートの使用：
方法では、データは、例えば、時間の、ほんの数GB場合はRedisのサーバーよりも小さい場合には、データのスナップショットを保存するために使用します。Redisのは、子プロセスを作成し、ハードドライブの内部へのセーブデータ、時間はさらに短く、必要なデータを読み込むよりも時間のスナップショットを生成するために必要。
あまりときRedisのサーバーメモリの残りの場合は、子プロセスを作成することは、より多くの時間がかかるだろうしかし、データの増加とともに、Redisのメモリフットプリントは、より大きな、BGSAVEを取得していますこれは、システムのコマンドラインBGSAVE長い休止を行いますと、サーバーが使用できない可能性があります。
各仮想マシンのカテゴリは、経過時間のサブスレッドを作成します。
子プロセスを作成し、一時停止するときしたがって防止のRedisのために、我々は、自動保存ターン送信BGSAVE SAVEに持続するか、手動でオフにすることを検討することができますので、
手動BGSAVEは現象を一時停止する送付、私たちは、ポーズが特定のサービス要求に影響を与えていない場合にコントロールにコマンドを送信する時間を制御することができます。
また、SAVEコマンドを使用したときのRedisスナップショットの作成が完了するまでは、しかしブロックされたままになることは注目に値するが、Redisの結果が停止し、子プロセスを作成すると、それは、ないようBGSAVEに、子プロセスを作成する必要はありません。正確にこのため、SAVEは速くBGSAVEよりスナップショットを作成速いスピードのスナップショットを作成します。
スナップショットを作成し、我々は、このような方法により、早朝3または4時、手書きのスクリプト、実行のタイミングなどを要求、少ない時間を、サービスを提供することができます。
AOFの永続性
AOFの永続性は、コマンドを記述しますAOFは、変更が発生し、記録データのために、最後に書き込まれたファイルが実行されています。我々はデータを回復するときに、このように、あなただけのデータを復元するためにどのようなAOFファイルの最初から最後まで実行する必要があります。
まず、AOFの永続性オプションを開きます
私たちは、次のコマンドを使用して、AOFを開くことができます。
appendonly yes
我々は、次のコマンドを使用して、同期周波数AOFファイルを設定する必要があります。
appendfsync everysec/always/no
二、appendfsync同期周波数差
appendfsync以下の周波数の違いを同期：
もちろん、（1）常に方法は、セーブデータは非常に良いためにすることはできませんが、この同期化戦略は、処理速度のRedisのコマンドは、ハードドライブの性能を制限されますので、ハードディスク書き込み操作の多くを必要とします。
通常のハードディスクは、毎秒の書き込みコマンドの数万人を扱うことができるSSDを使用して、第2の書き込みコマンドあたり200について扱うことができますが、それぞれの時間はわずか続け書き込みコマンドは、書かれた少量のせいにしますデータの練習は、書き込み増幅の深刻な問題につながる可能性があり、この減少は深刻なSSDの寿命に影響を与えました。
（2）everysec方法、Redisのは、第二旅団AOFファイルごとに一度の周波数に同期。この場合、あなただけのも考慮に書き込みパフォーマンスを取ることができ、アカウントデータのセキュリティを考慮に入れることができます。
パフォーマンスへのRedisのは、あなたがデータの1秒以内に生成されたデータの欠落、障害が発生した場合でも、それを保証することができる方法の毎秒更新使用して、二AOF性能ごとに一度ファイルを同期とほぼ同じ特性任意の永続性を使用しないとき。
（3）決して、Redisのは、AOFファイルにない表示されるすべての同期を実行しますが、AOFファイルの同期にする場合、オペレーティングシステムによって決定されるべきです。
このコマンドは、通常のRedisのパフォーマンスに影響をあまり発生しないが、システムはデータ損失のこのオプションRedisのサーバー変数番号を使用して失敗したとき。
ユーザーのハードディスク書き込み操作の処理速度が十分に速くないときにまた、バッファは、ハードディスクの書き込みデータを埋めるために待っている、Redisの書き込み動作がブロックされ、Redisのコマンド要求処理が遅くなる原因、このため、一般的には、このオプションを使用することをお勧めしません。
第三に、書き換え/ AOFファイル圧縮
データ量の増加によって、AOFファイルは、大きなできるように、すべてのデータの回復時間は成長しているAOFファイルを解決するために、非常に長い時間になると、ユーザーは、Redisののに送信できるBGREWRITEAOF コマンド、冗長コマンド・ファイルを除去することにより、AOF AOFファイルを書き換えるためのコマンドは、可能な限り小さく医療AOFファイルです。
原理は非常にBGREWRITEAOFとBGSAVEように動作します：Redisのは、子供がAOFファイルの書き換え動作を担当して、子プロセスを作成します。
同じファイルにつながった子プロセスを作成する際にAOF上書きされますので、AOFは、部門は、子プロセスを作成するときに、ファイルを書き換えるので、永続的なパフォーマンスとメモリフットプリントの問題のスナップショットので。
第四に、トリガ書き換え/ AOFファイル圧縮条件のセット
設定することにより、AOF auto-aof-rewrite-percentage と auto-aof-rewrite-min-size BGREWRITEAOFオプションを実行して自動的に。
次のようにその特定の意味は、一例として見ることができます。
auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb
AOFは、64メガバイトよりも現在のファイルサイズを大きくを示し、少なくとも（100％）、二重、RedisのBGREWRITEAOF書き換えコマンドを実行するときにファイルの書き換えの体積後AOFの体積比が大きくなります。
AOF書き換えがあまりにも頻繁に実行した場合は、することができauto-aof-rewrite-percentage 、より、あなたはAOFファイルの容量が大きくなった後にのみ、このほとんど偶然のRedisの書き換え動作を行うことができます100のためのオプションの値を設定し、それはまた作りますデータ回復のための時間の実行時間がより長くなります。
スナップショットファイルとファイルを確認しAOF
我々はデータ復旧を行ったときに、永続した方法に関係なく、Redisのは、2つのコマンドラインプログラムを提供しています。
redis-check-aofredis-check-dump
彼らは再びシステムを失敗したことができた場合、ファイルのスナップショットとAOFの状態を確認し、ファイルを修復するためにそこに必要とすることができます。
時間は、ユーザーがRedisのチェック-AOFのコマンドを実行している場合は、指定し--fix たパラメータを、プログラムがファイルの修復をAOFます。
彼はときに最初のエラーコマンドが表示され、プログラムはエラーの後、間違ったコマンドやコマンドを削除し、不正または不完全なコマンドの表情、ファイルAOF与えられたすべてのコマンドをスキャン：ファイルAOF方法の修正を簡単です、それらの前に失敗したコマンドに位置のみ正しいコマンドを残します。ほとんどの場合、AOFの最後に削除されたファイルは、不完全な書き込みコマンドです。
概要
上記、サポートの永続性に一緒に研究二つの方法は、一方では、私たちは、データのスナップショットを必要とするか、AOFの永続性の方法により、他の一方で、我々はまた、取得したファイルの永続的なバックアップ、さまざまにバックアップする必要がありますサーバー上で、それは可能な限りデータ損失の損失を減少させることができること。
参考記事：
1アクションでのRedis - [美]ヨシヤL.Carlsono
