Redis永続化の概要

Redisはどのような持続化メカニズムを提供した:1).RDB(Redis DataBase)永続化:このメカニズムは、指定された時間間隔でメモリ内のデータセットスナップショットをディスクに書き込むことです.        2). AOF(Append Only File)永続化:このメカニズムは、サーバが処理する書き込み操作をログ形式で記録し、Redisサーバの起動時にファイルを読み出してデータベースを再構築し、起動後のデータベースのデータが完全であることを保証します.    3). 永続化なし:Redisサーバの永続化機能を構成的に無効にすることで、Redisを機能強化版のmemcachedと見なすことができます.    4). AOFとRDBを同時に適用した.

RDBメカニズムのメリットとデメリット:

RDBにはどのようなメリットがありますか?

1). この方法を採用すると、Redisデータベース全体に1つのファイルしか含まれません.これはファイルバックアップにとって非常に完璧です.たとえば、最近の24時間のデータを1時間に1回アーカイブするとともに、最近の30日間のデータを毎日アーカイブする予定です.このようなバックアップポリシーにより、システムに災害障害が発生すると、リカバリが容易になります.    2). ディザスタリカバリにとって、RDBは非常に良い選択です.個別のファイルを圧縮して他のストレージメディアに移行するのは簡単です.    3). パフォーマンスの最大化Redisのサービスプロセスでは、永続化が開始されると、forkアウトサブプロセスのみが必要になり、サブプロセスによってこれらの永続化作業が完了するため、サービスプロセスがIO操作を実行することを大幅に回避できます.    4). AOFメカニズムよりもデータセットが大きいとRDBの起動効率が高くなる.RDBとAOFは同時に存在し、AOFファイルを優先的にロードすることができる

RDBにはどんな劣勢があるのだろうか。

    1). データの高可用性、すなわちデータ損失を最大限に回避するために、RDBは良い選択ではありません.システムがタイミング持続化する前にダウンタイムが発生すると、ディスクに書き込む時間がなかったデータが失われるためです.    2). RDBはforkサブプロセスによってデータの永続化作業を支援するため、データセットが大きい場合、サーバ全体が数百ミリ秒、さらには1秒のサービス停止を引き起こす可能性があります.    

AOFメカニズムの優位性と劣勢性

AOFの強みは何ですか?

    1). このメカニズムは、より高いデータセキュリティ、すなわちデータ持続性をもたらすことができる.Redisには、1秒あたりの同期、変更ごとの同期、および非同期の3つの同期ポリシーが用意されています.実際、1秒あたりの同期も非同期で完了し、その効率も非常に高く、システムにダウンタイムが発生すると、この1秒以内に変更されたデータが失われます.同期を変更するたびに、同期の永続化と見なすことができます.つまり、データの変化が発生するたびに、すぐにディスクに記録されます.この方式は効率的に最も低いことが予想される.同期がないということは、言うまでもなく、みんなが正しく理解できると思います.    2). このメカニズムは、ログファイルの書き込み操作にappendモードを採用しているため、書き込み中にダウンタイムが発生しても、ログファイルにすでに存在するコンテンツを破壊することはありません.しかし、今回の操作でデータの半分を書き込むだけでシステムのクラッシュの問題が発生した場合は、Redisの次の起動前にredis-check-aofツールを使用してデータの一貫性の問題を解決することができます.    3). ログが大きすぎる場合、Redisはrewriteメカニズムを自動的に有効にすることができます.すなわち、Redisはappendモードで古いディスクファイルに変更データを継続的に書き込み、その間に実行された変更コマンドを記録するための新しいファイルを作成します.したがって、rewrite切り替えを行うと、データのセキュリティがより保証されます.    4). AOFには、すべての変更操作を記録するためのフォーマットが明確で分かりやすいログファイルが含まれています.実際には、このファイルを使用してデータの再構築を完了することもできます.

AOFの劣勢はどれらがありますか?

1). 同じ数のデータセットの場合、AOFファイルは通常RDBファイルより大きい.    2). 同期ポリシーによっては、AOFの実行効率がRDBよりも遅くなることが多い.要するに、毎秒同期ポリシーの効率は比較的高く、同期無効ポリシーの効率はRDBと同様に効率的である.

永続化構成

Snapshotting

デフォルトでは、Redisはデータセットのスナップショットをdumpにdumpする.rdbファイルにあります.また、Redisサーバdumpのスナップショットの頻度をプロファイルで変更する、redisを開くこともできます.confファイルの後、saveを検索すると、save 900 1#が900秒(15分)後に少なくとも1つのkeyが変化した場合、dumpメモリスナップショットが表示されます.save 300 10#300秒(5分)後、少なくとも10個のkeyが変化した場合、dumpメモリスナップショット.save 60 10000#60秒(1分)後、少なくとも10000 keyが変化した場合、dumpメモリスナップショット.
RDBスキームを使用したくない場合は、save""のコメントを開いて、次の3つのコメントを開くことができます.

Dumpスナップショットのメカニズム

1). Redisはまずforkサブプロセスを行う.    2). サブプロセスは、スナップショットデータを一時RDBファイルに書き込む.    3). サブプロセスがデータの書き込み操作を完了したら、古いファイルを一時ファイルに置き換えます.(深夜にするのがベスト)
SHUTDOWNおよびFLUSHALLコマンドは、RDBスナップショットsaveブロッキングをトリガしてRDBスナップショットをトリガし、データのバックアップを実行します.

AOFファイル

上述したように、RDBのスナップショットタイミングdumpメカニズムは、良好なデータ持続性を保証できない.もし我々の応用がこの点に非常に関心を持っているならば,RedisにおけるAOF機構の使用を考えることができる.Redisサーバの場合、デフォルトのメカニズムはRDBであり、AOFを使用する必要がある場合は、appendonly noをappendonly yesに変更する必要があります.これから、Redisはデータ変更のコマンドを受信するたびにAOFファイルに追加します.Redisの次回の再起動では、AOFファイルの情報をロードして、メモリに最新のデータを構築する必要があります.

AOFの構成：

Redisのプロファイルには、Appendfsync always#がデータ変更が発生するたびにAOFファイルに書き込まれる3つの同期方式があります.appendfsync everysec#AOFのデフォルトポリシーである毎秒同期します.appendfsync no#は同期していません.効率的ですが、データは永続化されません.
4書き換えトリガメカニズムの構成

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

解説:AOFファイルサイズが前回rewrite後のサイズの倍であり、ファイルが64 Mより大きい場合にトリガーされます.普通はすべて3 Gに設定して、64 Mは小さすぎます.

破損したAOFファイルの修復方法

    1). 既存の破損したAOFファイルを追加コピーします.    2). 「redis-check-aof--fix」コマンドを実行して、破損したAOFファイルを修復します.    3). 修復されたAOFファイルでRedisサーバを再起動します.    

Redisのデータバックアップ:

Redisでは、実行中のRedisデータファイルをcopyでオンラインバックアップできます.これは、RDBファイルが生成されると変更されないためである.Redisは毎回最新のデータを1つのテンポラリファイルにdumpし,その後rename関数を用いて原子的にテンポラリファイルを元のデータファイル名に改名する.したがって,任意の時点でcopyデータファイルは安全で一致していると言える.これにより、cron jobを作成することで、Redisのデータファイルをタイミングよくバックアップし、バックアップファイルを安全なディスクメディアにcopyすることができます.