RDB
RDBの永続性は、特定の条件が満たされている（スナップショット）完了し、ハードドライブにコピーして保存を生成するためにバイナリ形式ですべてのデータのRedisのメモリのスナップショットを介して行われます。
トリガ機構
- コマンドを保存します。プロセスは、例えば、長い時間のために、比較的大容量のメモリが閉塞を引き起こす可能性があり、RDB完了するまで、Redisのサーバーが現在ブロックされている、オンライン環境が推奨されていません
- bgsaveコマンド：実装フォーク操作のRedisのプロセスが子プロセスを作成するには、子プロセスを担当するRDB持続的なプロセスが完了した後に自動的に終了します。ブロッキングは、非常に短い時間、一般的に、唯一のフォーク相で起こります
- こうした「MNを保存する」として、保存した構成を使用してください。修飾はn倍の存在は、第二のデータセットをmが示す場合、自動的bgsaveトリガ
- コピー操作の合計量は、ノードから実行した場合RDBノードから生成bgsave、マスタノードが自動的に実行されているファイルを送信します
- Redisのをリロードするデバッグreloadコマンドを実行すると、それが自動的に保存操作をトリガーします。
- 開いていないAOFの永続化機能は、デフォルトのbgsaveによって自動的に実行されている場合は、shutdownコマンドとflushallを実行すると
業務プロセスbgsave
- コマンドを実行Bgsave、Redisの親プロセスの子プロセスは、コマンドbgsave直接リターンがある場合、現在、そのようなRDB / AOF子プロセスとして、そこに実装されているかどうかを判断します
- 子プロセスを作成するには、親プロセスのフォーク操作、親プロセスのフォーク操作が情報を経由してビューlatest_fork_usecオプションをブロックしますstatsコマンドは、フォーク最近の時間のかかる操作を取得することができ、単位はマイクロ秒.Forkの役割は、現在のプロセスのコピーであります同じプロセス。すべてのデータ（変数、環境変数、プログラムカウンタなど）と新しいプロセスの値は、元のプロセスと一致しているが、新しいプロセスであり、そして元プロセスの子プロセスとして
- 親プロセスのフォークが完了した後、bgsaveコマンドが返す「背景の節約を開始し、」情報と親プロセスを詰まらせないだろう、あなたは他のコマンドに応答し続けることができます
- RDBの子プロセスは、（Rdbはdump.rdbファイルを保存されている）ファイルを作成し、親プロセスに応じて一時メモリのスナップショットファイルを生成し、元のファイルは、原子の完了後に交換されます。最後の世代のLastsaveコマンド実行時間は、RDB、対応する情報統計rdb_last_save_timeオプションを取得することができます
- プロセスは、統計を更新するために、親プロセスが完了したことを示す信号を送信し、親プロセス
データ復旧
RDBファイルがデータディレクトリをRedisのサービスを開始するために移動されます、Redisのファイルが自動的にメモリにデータをロードします。
RDB Redisのは、それがスナップショットファイルを読み込み、起動した後、データがメモリにハードディスクからロードされます。異なる構造およびサーバーのパフォーマンスとデータの量は、この時間は異なります。通常千万は20〜30秒かかり1GBのスナップショットファイルのサイズがメモリにロードされ、キーの文字列型を記録します。持続性のためのRDBところで、かつて
Redisの異常終了、それが将来的にすべてのデータ変更の最後のスナップショットを失うことになります。
優位
RDBは、ある時点でRedisのデータのスナップショットの代わりに、小型圧縮バイナリファイルです。バックアップのための理想的な、レプリケーションシナリオの全体量。たとえば、バックアップbgsave 6時間ごとに行われ、リモートマシンまたはRDBファイルシステム（HDFSなど）にファイルをコピーし、災害復旧のための（少ないデータの整合性と一貫性に厳しいです）
Redisの負荷RDBは、（大規模なデータ回復のための）AOFの方法よりもはるかに高速のデータを回復します
恵まれません
RDBの道リアルタイムデータの永続性/秒レベルの永続性を行うための方法はありません。各実行は、子プロセスを作成するためのフォーク操作が大物操作に属し実行されなければならないのでBgsaveは、頻繁に高いコストを実行（メモリ内のデータは、約2倍の拡張を考慮する必要がクローンである）（パフォーマンスに影響します）
RDBファイルには、特定のバイナリ形式を使用して保存、進化のRedisのバージョンは、RDB形式の複数のバージョンを持って、Redisのサービスの古いバージョンは、RDB互換形式（互換性のないバージョン）の新しいバージョンを発行することはできませんがあります
Redisのは、誤って落下した場合、彼らは最後のスナップショットの後のすべての変更を失うことになるので、一定の時間間隔が（そこにデータの損失）を、バックアップを行うには
RDBの保存を停止します
redis-cli config set save ""AOF
AOF（ファイルのみを追加）各書き込みコマンドの個別のログに記録し、データ復旧の再起動を達成するためにAOFファイルコマンドの目的を再実行してください。AOF主な役割は、リアルタイムデータの永続性を解決するものであり、持続性のRedisは現在主流の方法です。理解する人気のものは、各書き込み操作を記録するログの形態である、Redisのは、すべてが始まるRedisのは、それがデータを再構築するためのファイルを読み込み、起動し、のみを形成するためにファイルを追加し、記録するコマンドを記述し、実行しました。
どのように開く方法
セット構成：はい、デフォルトが開いていないappendonly。
設定ファイルのAOF名：appendfilename、デフォルトのファイル名はappendonly.aofです
点滅モードの3種類
- appendfsyncは常に＃それは、ディスクへの即時書き込みを強制的に書き込みコマンドを受信するたびに、完全な持続性の最良の保証はなく、最も遅い速度で、一般的に推奨されません。
- ディスクに書き込まれた第二強制ごとに、パフォーマンスと持続性が良好な妥協をした後appendfsync everysec＃、それは推奨される方法に従うものとします。
- appendfsyncなし＃のOSは、通常約30秒で、最高のパフォーマンスを完全に依存して書かれていないが、ほとんどの永続を保証するものではありませんが、推奨されません。
AOFワークフロー
- すべての書き込みコマンドはaof_bufバッファに追加されます。
- 対応するポリシーに従って製造されたハード・ディスク・バッファにaof_buf同期動作。
- AOFファイルの通常のファイルAOF書き換え、圧縮の目的を達成するためのニーズの高まりとともに、
- ときRedisのサーバーを再起動すると、あなたはデータ復旧のためのAOFファイルをロードすることができます。
メカニズムの書き換え
コマンドがAOFを書き込み続けと、ファイルがこの問題を解決するために大きくなり、RedisのAOF書き換えメカニズムは、圧縮ファイルのサイズを導入しました。AOFファイルは新しいAOFファイルの同期化プロセスへの書き込みコマンドにRedisのプロセスのデータを書き換えることです。モードを追加使用して人気の理解AOFファイル、ファイルは、このような事態を避けるために、はるかになりますAOFファイルのサイズがしきい値設定を超えた場合、新しい書き換えメカニズムを発生し、RedisのはAOF文書を開始しますコマンドbgrewriteaofを使用することができ、データを回復することができる命令の唯一の最小セットを残して、コンテンツの圧縮、。
原理：AOFファイルが成長し続け、大きすぎると、それはファイルを書き換えるために、新しいプロセスをforkします（また、一時ファイルを作成し、最後に名前を変更する最初の）、メモリ内のデータは、新しいプロセスを通過するには、各レコードには、Setステートメントのいずれかを持っています。ファイルAOF操作を書き換え、古いAOFファイルを読み取れませんが、コマンドを使用して、メモリ内のデータベース全体の内容は、AOFファイルの新しい方法を書き換えるために、多少類似点と、スナップショットであります
AOFの書き換え処理は手動でトリガし、自動的にトリガすることができます。
- マニュアルトリガ：コマンドbgrewriteaof直接呼び出し。
- 自動：タイミングが自動AOF書き換え分サイズおよび自動AOF書き換えパーセンテージパラメータをトリガ自動的に決定されます。Redisのは、AOFファイルのサイズが2倍とファイルサイズが最後の書き換えトリガ64Mよりも大きいされている場合AOFのサイズは、デフォルトの設定を書き換え、最後の時間を記録する時期
データ復旧
場合は、データファイルの破損どのように修正します
AOFファイルフォーマットエラー、最初のバックアップのために、その後のRedis-チェックAOF使用して - 失われたデータを見つけ、修理後の差分-uの比較データの違いを利用して、修正するためのコマンドを修正するには、手動でいくつかの完了を変更することができます。AOFファイルが不完全なファイルの書き込みコマンドの機械AOFの終了を引き起こし、このような突然の停電など、最後にそれが不完全で存在してもよいです。RedisのはAOF-負荷切り捨て我々のケースと互換性を持つように構成され、デフォルトで有効になっています。AOFをロードするとき、この問題に直面したとき、無視して起動を続行されます。
パフォーマンス・サマリー
- RDBのみバックアップ目的として提出するので、それが唯一のスレーブ永続的なRDBファイルに推奨され、そして限り、15分程度のバックアップは、かつて900 1この規則を保存するだけ残して、十分です。
- Enalbe AOFが、利益は最悪の場合であれば、それはデータのみの無い2秒以上を失うことになると、起動スクリプトは単純にはちょうどそれをあなた自身のAOFファイルをロードします。まず、持続的なIOをもたらし、そして第二に、AOFは、新しいファイルをブロックする過程で生成された最後の書き換え新しいデータを書き換えるのコストはほとんど避けられ引き起こすことが書かれています。限りハードディスクライセンスとして、あなたはAOF書き換えの頻度を減らすために試してみてください。AOFは基底64Mサイズにデフォルト値を上書き小さすぎる、それは5G以上に設定することができます。デフォルトのサイズは元のサイズの100％以上が適切なオーバライド値に変更することが可能です。
- あなたがAOFを有効にしない場合、単独のマスタースレーブレプリケーションは、高い可用性を実現することができます。IOシステムの多くはまた、書き換え時間の変動性を低減し保存することができます。価格はマスター/スレーブが同時に排出された場合、私は、データの10分を失っただけでなく、起動スクリプトは、新しいものをロードするには2つのマスタ/ RDBファイルのスレーブを比較します。このアーキテクチャの選択にシーナマイクロブロギング
参考資料
https://blog.csdn.net/weixin_39040059/article/details/79120416
https://blog.csdn.net/weixin_39040059/article/details/79120444