Redisチュートリアル(10)：永続化について詳しく解説

1. Redis が提供する永続化メカニズム:

1). RDB 永続化:
このメカニズムは、指定された時間間隔内にメモリ内のデータセットのスナップショットをディスクに書き込むことを指します。
2). AOF 永続性:
このメカニズムは、サーバーによって処理されたすべての書き込み操作をログの形式で記録し、Redis サーバーの起動開始時にファイルが読み取られてデータベースが再構築されます。起動後のデータベースは完了です。
3). 永続性なし:
Redis を memcached の拡張バージョンとして扱うことができるように、構成を通じて Redis サーバーの永続化機能を無効にすることができます。
4). AOF と RDB を同時に適用します。

2. RDB メカニズムの長所と短所:

RDB の利点は何ですか?

1). この方法を採用すると、Redis データベース全体にファイルが 1 つだけ含まれるようになり、ファイルのバックアップに最適です。たとえば、過去 24 時間のデータを 1 時間ごとにアーカイブし、過去 30 日間のデータを毎日アーカイブすることも計画できます。このようなバックアップ戦略により、システムに致命的な障害が発生した場合でも、非常に簡単に復元できます。
2) 災害復旧には、RDB が非常に良い選択です。単一のファイルを簡単に圧縮して、他の記憶メディアに転送できるからです。
3) パフォーマンスを最大化します。 Redis サービス プロセスの場合、永続化を開始するときに必要なのは、子プロセスをフォークアウトすることだけであり、その後、子プロセスが永続化作業を完了します。これにより、サービス プロセスによる IO 操作の実行を大幅に回避できます。
4). AOF機構と比較して、データセットが大きい場合、RDBの起動効率が高くなります。

RDB の欠点は何ですか?

1). データの高可用性を確保したい場合、つまりデータ損失を最大限に回避したい場合、RDB は適切な選択ではありません。スケジュールされた永続化の前にシステムがクラッシュすると、ディスクに書き込まれる時間がなかったデータが失われるためです。
2). RDB はフォーク子プロセスを通じてデータの永続化を支援するため、データ セットが大きい場合、サーバー全体が数百ミリ秒、場合によっては 1 秒間サービスを停止する可能性があります。

3. AOF メカニズムの長所と短所:

AOF の利点は何ですか?

1). このメカニズムにより、より高いデータ セキュリティ、つまりデータの永続性が実現されます。 Redis は 3 つの同期戦略を提供します。つまり、1 秒ごとに同期、変更ごとに同期、および同期なしです。実際、同期も 1 秒ごとに非同期で完了し、その効率も非常に高くなります。唯一の違いは、システムがダウンすると、この 1 秒以内に変更されたデータが失われることです。変更が同期されるたびに、それを同期永続性と考えることができます。つまり、発生したすべてのデータ変更はすぐにディスクに記録されます。この方法は最も効率が低いことが予測できます。同期がないことについては、これ以上言う必要はなく、誰もが正しく理解できると思います。
2). このメカニズムはログ ファイルの書き込みに追加モードを使用するため、書き込みプロセス中にダウンタイムが発生した場合でも、ログ ファイル内の既存のコンテンツは破壊されません。ただし、この操作でデータの半分しか書き込まず、システム クラッシュが発生した場合でも、次回 Redis を開始する前に、redis-check-aof ツールを使用してデータの整合性の問題を解決できますので、ご心配なく。
3). ログが大きすぎる場合、Redis は書き換えメカニズムを自動的に有効にすることができます。つまり、Redis は、変更されたデータを追加モードで古いディスク ファイルに継続的に書き込みます。同時に、この期間中にどの変更コマンドが実行されたかを記録する新しいファイルも作成します。したがって、書き換えスイッチングを行う際のデータの安全性をより確保することができる。
4). AOF には、すべての変更操作を記録するための、明確でわかりやすい形式のログ ファイルが含まれています。実際、このファイルを通じてデータの再構築を完了することもできます。

AOF の欠点は何ですか?
1) 同じ数のデータセットの場合、AOF ファイルは通常、RDB ファイルよりも大きくなります。
2). 同期戦略によっては、動作効率の点で AOF は RDB よりも遅くなることがよくあります。つまり、1 秒あたりの同期戦略の効率は比較的高く、同期無効化戦略の効率は RDB と同等です。

4. その他:

1. スナップショット:

デフォルトでは、Redis はデータセットのスナップショットを dump.rdb ファイルにダンプします。さらに、構成ファイルを通じて Redis サーバーのダンプ スナップショットの頻度を変更することもできます。6379.conf ファイルを開いた後、save を検索すると、次の構成情報が表示されます:
save 900 1 #After 900 minutes (15 minutes) )、少なくとも 1 つのキーが変更された場合は、メモリ スナップショットをダンプします。
save 300 10 #300 秒 (5 分) 後、少なくとも 10 個のキーが変更された場合は、メモリ スナップショットをダンプします。
save 60 10000 #60 秒 (1 分) 後、少なくとも 10,000 個のキーが変更された場合、メモリ スナップショットをダンプします。

2. ダンプ スナップショット メカニズム:

1) Redis は最初に子プロセスをフォークします。
2). 子プロセスは、スナップショット データを一時 RDB ファイルに書き込みます。
3). 子プロセスがデータの書き込み操作を完了したら、古いファイルを一時ファイルに置き換えます。

3. AOF ファイル:

上で何度も述べたように、RDB のスナップショット スケジュール ダンプ メカニズムでは、良好なデータ耐久性を保証できません。アプリケーションがこれを本当に懸念している場合は、Redis の AOF メカニズムの使用を検討できます。 Redis サーバーの場合、デフォルトのメカニズムは RDB です。AOF を使用する必要がある場合は、構成ファイル内の次のエントリを変更する必要があります:
appendonly no を appendonly yes に変更します
これ以降、Redis は毎回データの変更を受け取るようになります。コマンドを実行すると、AOF ファイルに追加されます。次回 Redis を再起動するときは、AOF ファイル内の情報をロードして、最新のデータをメモリに構築する必要があります。

4. AOF 構成:

Redis 構成ファイルには 3 つの同期方法があります。それらは次のとおりです:
appendfsync always #AOF ファイルは、データ変更が発生するたびに書き込まれます。
appendfsync Everysec #1 秒ごとに同期するこの戦略は、AOF のデフォルトの戦略です。
appendfsync no #決して同期しない。効率的ですが、データは保持されません。

5. 破損した AOF ファイルを修復する方法:

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

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

Redis では、実行中の Redis データ ファイルをコピーすることでオンラインでバックアップできます。これは、RDB ファイルが一度生成されると変更されないためです。 Redis は、毎回最新のデータを一時ファイルにダンプし、名前変更機能を使用して一時ファイルの名前を元のデータ ファイル名にアトミックに変更します。したがって、データ ファイルのコピーはいつでも安全かつ一貫性のあるものであると言えます。これを考慮して、cron ジョブを作成して Redis データ ファイルを定期的にバックアップし、そのバックアップ ファイルを安全なディスク メディアにコピーできます。

上記は Redis チュートリアル (10): 永続化の詳細な説明の内容です。さらに関連するコンテンツについては、PHP 中国語 Web サイト (www.php.cn) に注目してください。