この記事では、redis における RDB と AOF 永続性の原則について説明します。それらの長所と短所は何ですか?どれを使用すべきかを分析してください。お役に立てれば幸いです!
Redis は、RDB と AOF の 2 つの永続化ソリューションを提供します。
RDB: Redis のメモリ内データ スナップショットを生成します。バイナリ ファイル dumpr.rdb
AOF: クエリを除くすべての Redis 書き込みコマンドを記録し、Redis サービスの開始時にこれらのコマンドを再実行します。
デフォルトでは、Redis はデータを RDB スナップショットの形式でハードディスクに一定期間永続化し、保存します。 dumpr.rdb バイナリ ファイルとしてそれらを保存します。 [関連する推奨事項: Redis ビデオ チュートリアル ]
動作原理の簡単な紹介:
Redis を永続化する必要がある場合、Redis はフォークします。子プロセスの場合、子プロセスはディスク上の一時 RDB ファイルにデータを書き込みます。子プロセスが一時ファイルの書き込みを完了したら、元の RDB を置き換えます。これの利点は、コピーオンライトができることです。
もちろん、save または bgsave を手動で (非同期的に) 実行して RDB ファイルを生成することもできます。
redis.conf のデフォルト設定
save 900 1 save 300 10 save 60 10000
RDBスナップショット コマンド
デフォルトでは、Redis はデータベース スナップショットを dump.rdb という名前のバイナリ ファイルに保存します。
「データ セットに N 秒以内に少なくとも M 個の変更がある」という条件が満たされた場合に、データ セットを自動的に保存するように Redis を設定できます。
SAVE または BGSAVE を呼び出して、Redis にデータセットを手動で保存させることもできます。
たとえば、次の設定では、「60 秒以内に少なくとも 1000 個のキーが変更された」という条件を満たした場合に、Redis がデータ セットを自動的に保存できるようになります。永続化 この方法はスナップショットと呼ばれます。
#RDB 作成の原則Redis が dump.rdb ファイルを保存する必要がある場合、サーバーは次の操作を実行します。
Redis は fork() を呼び出し、親プロセスと子プロセスの両方を持ちます。
RDB は、ある時点の Redis データを保存する比較的コンパクトなファイルです。バックアップと災害復旧のために。
たとえば、過去 24 時間以内に 1 時間ごとに RDB ファイルをバックアップしたり、毎月毎日 RDB ファイルをバックアップしたりできます。これにより、問題が発生した場合でも、いつでもデータ セットを別のバージョンに復元できます。 RDB の欠点サーバー障害時のデータ損失を最小限に抑える必要がある場合、RDB は向きません。 Redis では、さまざまなセーブポイントを設定して RDB ファイルを保存する頻度を制御できますが、RDB ファイルはデータセット全体の状態を保存する必要があるため、これは簡単な操作ではありません。したがって、少なくとも 5 分に 1 回は RDB ファイルを保存できます。この場合、障害が発生すると、数分間のデータが失われる可能性があります。
AOF 永続性
appendonly.aof# に追加されます。 ＃ ファイル。 AOF は完全な永続性を実現できます。構成ファイルでオンにする必要があるだけです (デフォルトは no)。appendfsync yes AOF をオンにした後、Redis がコマンドを実行するたびに、データを変更すると、そのデータが AOF ファイルに追加され、Redis が再起動すると、AOF ファイルが読み取られて「再生」され、Redis がシャットダウンされる直前の状態が復元されます。
AOF 構成
Redis がデータをディスクに fsync する頻度を構成できます。 redis.conf のデフォルト設定
save 60 1000
には 3 つのオプションがあります:
1、新しいコマンドが AOF ファイルに追加されるたびに fsync を実行します : 非常に遅く、非常に安全です。
2、fsync は 1 秒に 1 回 : 十分な速度 (RDB 永続性を使用するのとほぼ同じ) で、障害が発生しても失われるデータは 1 秒だけです。
3、fsyncは行わない: データの処理をオペレーティング システムに任せます。より高速ですが安全性は低いオプションです。
推奨 (およびデフォルト) の対策は、1 秒に 1 回 fsync することです。この fsync 戦略は、速度とセキュリティの両方を考慮できます。
AOF 作成原理
AOF の書き換えは RDB スナップショットの作成と同じであり、どちらもコピーオンライト メカニズムを巧みに利用しています。
以下は AOF 書き換えの実行手順です。:
Redis は fork() を実行し、親プロセスと子プロセスの両方を持ちます。
子プロセスは、新しい AOF ファイルの内容を一時ファイルに書き込み始めます。
新しく実行されたすべての書き込みコマンドについて、親プロセスはそれらをメモリ キャッシュに蓄積し、これらの変更を既存の AOF ファイルの末尾に追加します。こうすることで、書き換えの途中でシャットダウンが発生した場合でも、既存の AOF ファイルは引き続き安全です。
子プロセスが書き換え作業を完了すると、親プロセスにシグナルを送信し、シグナルを受信した親プロセスは、メモリ キャッシュ内のすべてのデータを新しい AOF ファイルの末尾に追加します。 ＃＃＃＃＃＃ 終わり！ Redis は古いファイルを新しいファイルにアトミックに置き換え、それ以降のすべてのコマンドは新しい AOF ファイルの末尾に直接追加されます。
AOF の利点1. 永続化に AOF を使用すると、fsync なし、1 秒に 1 回の fsync など、さまざまな fsync 戦略を設定できます。 、書き込みコマンドが実行されるたびに fsync を実行します。
AOF のデフォルト ポリシーは、fsync を 1 秒に 1 回行うことです。この構成でも、Redis は良好なパフォーマンスを維持でき、障害が発生した場合でも、失われるデータは最大 1 秒のみです。
fsync はバックグラウンド スレッドで実行されるため、メイン スレッドはコマンド リクエストの処理に懸命に取り組み続けることができます。
2. AOF ファイルは、追加操作のみを実行するログ ファイルです。新しいファイルを生成した後に置き換えられるものではありません。たとえ、何らかの理由 (書き込み時など) でログに不完全なコマンドが含まれていたとしても、ディスクがいっぱいである、書き込みが途中で停止するなど）場合は、redis-check-aof ツールを使用してこの問題を簡単に解決することもできます。
3、Redis は、AOF ファイルのサイズが大きくなりすぎると、バックグラウンドで AOF を自動的に書き換えることができます。書き換え後の新しい AOF ファイルには、現在のデータ セットを復元するために必要な最小限のコマンド セットが含まれています。
Redis の書き換えでは新しい AOF ファイルが作成されるため、書き換え操作全体は絶対に安全です。書き換えプロセス中にエラーが発生した場合でも、書き換えプロセス中はコマンドが既存の古い AOF ファイルに追加され続けます。シャットダウンしても、既存の古い AOF ファイルは失われません。新しい AOF ファイルが作成されると、Redis は古い AOF ファイルから新しい AOF ファイルに切り替えて、新しい AOF ファイルへの追加を開始します。
4. AOF ファイルには、データベース上で実行されたすべての書き込み操作が順序どおりに保存されます。これらの書き込み操作は Redis プロトコルの形式で保存されるため、AOF ファイルの内容は非常に読みやすくなっています。解析（パース）も簡単です。 AOF ファイルのエクスポートも非常に簡単です。たとえば、誤って _FLUSH ALL_ (Redis サーバー全体のデータをクリア (すべてのデータベースのすべてのキーを削除)) コマンドを実行した場合でも、AOF ファイルが上書きされていない限り、エクスポートできます。その後、サーバーを停止し、AOF ファイルの末尾にある
FLUSHALLコマンドを削除し、Redis を再起動する限り、データ セットを FLUSHALL が実行される前の状態に復元できます。実行されました。
AOF の欠点同じデータ セットの場合、通常、AOF ファイルのサイズは RDB ファイルのサイズよりも大きくなります。
使用される fsync 戦略によっては、AOF は RDB よりも遅くなる可能性があります。通常の状況では、1 秒あたりの fsync パフォーマンスは依然として非常に高く、fsync をオフにすると、負荷が重い場合でも AOF を RDB と同じ速度にすることができます。
ただし、巨大な書き込み負荷を処理する場合、RDB はより保証された最大レイテンシー (レイテンシー) を提供できます。
RDB と AOF の違いAOF 永続性は、サーバーによって処理されたすべての書き込みおよび削除操作をログ形式で記録します。クエリ操作は記録されません。レコードはテキスト形式で追加されます。ファイルを開いて詳細な操作を確認できます。記録。
RDB と AOF どちらを使用すればよいですか?AOF は、Redis によって実行されるすべてのコマンドをディスクに追加します。大量の書き込みを処理すると、Redis のパフォーマンスが低下します。受け入れられるかどうかはわかりません。
データベースのバックアップと災害復旧:
RDB スナップショットを定期的に生成すると、データベースのバックアップに非常に便利で、RDB は AOF よりも速くデータ セットを復元します。
Redis は RDB と AOF を同時に開くことをサポートしており、システムの再起動後、Redis は AOF を使用したデータの回復を優先するため、データ損失が最小限になります。
AOF はファイルの末尾にコマンドを継続的に追加することで機能するため、書き込まれたコマンドの数が増加し続けると、AOF ファイルサイズもどんどん大きくなっていきます。
たとえば、
カウンターに対して INCR を 100 回呼び出す場合、カウンターの現在の値を保存するためだけに、AOF ファイルには Use 100 が必要です。レコード (エントリ)。
ただし、実際には、カウンターの現在値を保存するには SET コマンドを 1 つだけ使用するだけで十分で、残りの 99 レコードは実際には冗長です。
この状況に対処するために、Redis は興味深い機能 をサポートしています。サービス クライアントを中断せずに AOF ファイルを再構築できます。
BG REWRITE AOF コマンドを実行すると、Redis によって新しい AOF ファイルが生成されます。このファイルには、現在のデータ セットを再構築するために必要な最小限のコマンドが含まれています。
Redis 2.2 では、BGREWRITEAOF コマンドを手動で実行する必要があります。Redis 2.4 では、AOF 書き換えを自動的にトリガーできます。詳細については、2.4 のサンプル構成ファイルを参照してください。
ディスク障害、ノード障害、その他の問題によりデータが消失する可能性があり、バックアップを怠ると非常に危険です。
Redis は、サーバーの実行中に RDB ファイルをコピーできるため、データのバックアップに非常に適しています。RDB ファイルが作成されると、変更は加えられません。サーバーが新しい RDB ファイルを作成する場合、まずファイルの内容を一時ファイルに保存し、一時ファイルが書き込まれると、プログラムは rename(2) を使用して元の RDB ファイルを一時ファイルにアトミックに置き換えます。
これは、RDB ファイルをいつでも安全にコピーできることを意味します。
以下は私たちの提案です:
1. RDB ファイルを 1 時間ごとにフォルダーにバックアップする定期タスク (cron ジョブ) を作成し、それを毎時間バックアップします。 RDB ファイルを別のフォルダーにバックアップします。
2. スナップショット バックアップに対応する日付と時刻の情報があることを確認してください。通常のタスク スクリプトを実行するたびに、find コマンドを使用して期限切れのスナップショットを削除します。 48 時間。過去 1 か月または 2 か月の 1 時間ごとのスナップショットおよび毎日のスナップショットも保持できます。
3. 少なくとも 1 日に 1 回は、データ センターの外部、または少なくとも Redis サーバーを実行している物理マシンの外部で RDB をバックアップします。
プログラミング関連の知識について詳しくは、プログラミング ビデオをご覧ください。 ！
以上がRDB と AOF 永続性の簡単な分析、利点と欠点は何ですか?選び方は？の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
