Redisの永続性
参考：ステーションbのブロガーは、マッドゴッドが書いたメモに出会った。Bloggerの接続：リンク。
Redisのは、メモリデータベースであるメモリ内のデータベースの状態をディスクに保存されていない場合、サーバー・プロセスが終了すると、サーバ内のデータベースの状態も表示されなくなります。したがって、Redisは永続化機能を提供します！
RDB（Redisデータベース）
RDBとは
マスタースレーブレプリケーションでは、rdbはスレーブ上のバックアップです。
メモリ内のデータセットのスナップショットは、指定された時間間隔内にディスクに書き込まれます。つまり、専門用語のスナップショットです。復元されると、スナップショットファイルがメモリに直接読み込まれます。
Redisは、永続化のために子プロセスを個別に作成（フォーク）します。最初にデータを一時ファイルに書き込みます。永続化プロセスが終了すると、最後に永続化されたファイルがこの一時ファイルに置き換えられます。プロセス全体で、メインプロセスは操作を実行しません。これにより、非常に高いパフォーマンスが保証されます。大規模なデータリカバリが必要で、データリカバリの整合性がそれほど重要でない場合、RDB方式はAOF方式よりも優れています。RDBの欠点最後の永続化後にデータが失われる可能性があるということです。デフォルトはRDBであり、通常の状況では、この構成を変更する必要はありません。
rdbによって保存されたファイルはdump.rdbで、これは構成ファイルのスナップショットで構成されています。
トリガーメカニズム
1.保存のルールが満たされると、rdbルールが自動的に
トリガーされます。2。flshallコマンドを実行すると、rdbルールもトリガーされます！
3。redisを終了すると、RDBファイルも生成されます。
バックアップは自動的にdump.rdbを生成します
rdbファイルを復元する方法！
1. rdbファイルをredis起動ディレクトリに置くだけで、redisの起動時にダンプが自動的にチェックされます。rdbはデータを復元します！
2.保管する必要のある場所を確認します
127.0.0.1:6379> config get dir
1) "dir"
2) "/usr/local/bin" //如果在这个目录下存在dump。rdb文件，启动就会自动恢复其中的数据
redisのほぼデフォルトの構成で十分ですが、それでも理解する必要があります
利点：
1。大規模なデータ復旧に適しています！dump.rdb
2は、高いデータ整合性を必要としません。
短所：
1。プロセス操作には一定の時間間隔が必要です。redisが予期せずクラッシュした場合、最後に変更されたデータは失われます！
2.プロセスがフォークの場合、一定量のメモリスペースを占有します。
AOF（ファイルのみ追加）
使用するすべてのコマンド、履歴を記録し、復元時にこのファイルをすべて実行します。
それは何ですか
各書き込み操作をログの形式で記録し、Redisによって実行されたすべての命令を記録し（読み取り操作は記録されません）、追加のファイルのみを許可し、ファイルの書き換えは許可しません。Redisはファイルを読み取り、起動時にデータを再構築します。つまり、redis
が再起動すると、ログファイルの内容に応じて書き込みコマンドを前後に実行し、データ復旧作業を完了します。
Aofはappendonly.aofファイルを保存します
追加
appendonly yes //默认no 不开启状态 yes 开启aof
//重启，redis就可以生效了！
appendonly.aofファイルにエラーがあります。Redisを起動できません。修復する必要があります。Aofファイル
redisはツールを提供します。redis-check-aof --fix
ファイルが正常な場合は、再起動すると直接復元できます。
長所と短所！
appendonly no //默认是不开启aof模式的，默认使用rdb方式持久化的，在大部分所有的情况下，rdb完全够用！
appendfilename "appendonly.aof" //持久化的文件的名字
#appendfsync always //每次修改都会sync。消耗性能
appendfsync everysec //每秒执行一次，可能会丢失这1s的数据！
#appendfsync no //不执行sync，这个时候操作系统自己同步数据，速度最快！
#rewrite //重写
利点：
- すべての変更が同期され、ファイルの整合性が向上します。
- 1秒ごとに同期すると、1秒のデータが失われる可能性があります
- 同期しないでください。最も効率的です。
短所：
- データファイルと同等で、AOFはRDBよりもはるかに大きく、修復速度もRDBよりも遅くなります。
- Aofの運用効率もRDBよりも遅いため、redisのデフォルト構成はRDB永続性です。
ルールを書き換える
Aofはデフォルトでファイルの無制限の追加になり、ファイルはどんどん大きくなります！
aofファイルが64mより大きい場合は、大きすぎます。aofファイルを書き換えるための新しいプロセスをフォークしてください！
拡張：
1. RDB永続性メソッドは、指定された時間間隔内にデータのスナップショットストレージを実行できます
。2。AOF永続性メソッドは、サーバーへの各書き込み操作を記録します。サーバーが再起動すると、これらのコマンドが再実行され、元のデータが復元されます。 、AOFコマンドは、Redisプロトコルを使用して、各書き込み操作をファイルの最後に追加して保存します。Redisは、AOFファイルのボリュームが大きくなりすぎないように、バックグラウンドでAOFファイルを再書き込みすることもできます。
3.キャッシュのみ。サーバーの実行中にのみデータを存在させたい場合は、永続性を使用することもできません
。4。両方の永続化メソッドを同時に開きます。
-
この場合、redisを再起動すると、最初にAOFファイルをロードして元のデータを復元します。通常の状況では、AOFファイルによって保存されたデータセットはRDBファイルによって保存されたデータセットよりも完全であるためです。
-
RDBデータはリアルタイムではなく、両方を同時に使用するとサーバーが再起動し、AOFファイルのみが検出されます。AOFのみを使用する必要がありますか？RDBはデータベースのバックアップに適しているため、作成者は推奨しません。 （AOFは常に変化しているため、バックアップには適していません）すぐに再起動すると、AOFに潜在的なバグはありません。念のために保管してください。
5.パフォーマンスの推奨事項
- RDBファイルはバックアップ目的でのみ使用されるため、RDBファイルをスレーブに永続化することのみをお勧めします。バックアップには15分しかかからず、9001ルールのみを保存します。
- AOFを有効にすると、最悪の場合、2秒以内のデータしか失われないという利点があります。起動スクリプトは単純で、独自のAOFファイルのみをロードします。コストは、連続10をもたらすことです。 2つ目は、AOFrewriteの終了です。再書き込みプロセスで生成された新しいデータを新しいファイルに書き込むことによって引き起こされるブロックは、ほぼ避けられません。ハードディスクにライセンスが付与されている限り、AOFリライトの頻度を可能な限り減らす必要があります。AOFリライトのデフォルト値である64Mは小さすぎて、5Gを超えて設定できます。デフォルトでは、リライトは適切なものに変更できます。元のサイズの100％を超える場合の値。
- AOFを有効にしない場合は、マスタースレーブの再実行のみに依存することで高可用性を実現できます。これにより、10を大幅に節約し、書き換えによるシステムの変動を減らすことができます。マスター/スレーブが同時にダンプされると、10分以上のデータが失われるという代償があります。起動スクリプトは、2つのマスター/スレーブのRDBファイルも比較して、新しいファイルをロードする必要があります。Weiboはこれです。建築。