Redisの永続化方法は何ですか?長所と短所は何ですか.
3471 ワード
https://www.cnblogs.com/yzh-blog/p/11670762.html?utm_source=tuicool&utm_medium=referral
永続化の目的は、主に災害復旧、データ復旧です.Redisのデータはすべてメモリに入っているので、Redisが切れて構成が永続化されていなければ、再起動時にデータがすべて失われます.突然、大量の要求が来て、キャッシュはすべて命中することができなくて、キャッシュの雪崩をもたらして、mysqlは大量の要求を積むことができなくて、全体のシステムの崩壊をもたらします.Redisを永続化すれば、Redisが故障してもすぐに再起動し、対外的にサービスを提供することができます.
RDB持続化:指定した時間間隔内にメモリ中のデータセットスナップショットをディスクに書き込み、実際の操作過程はforkのサブプロセスであり、まずデータセットを一時ファイルに書き込み、書き込みに成功した後、前のファイルを置き換え、バイナリ圧縮で記憶する.AOF永続化:AOFメカニズムは各書き込みコマンドをログとしてappend-onlyのモードで1つのログファイルに書き込み、redisが再起動するとAOFログの書き込みコマンドを再生することでデータセット全体を再構築することができる.RDBとAOFにより、Redisメモリのデータをディスクに永続化したり、アリクラウドなどの他の場所に分割したりすることができます.Redisが切れた場合、ディスクやアリクラウドなどからデータをRedisにコピーし、Redisを再起動すると、Redisは自動的にファイルに基づいてデータを再構築します.RDBとAOFの2つの永続化メカニズムを同時に使用すると、AOFのデータがより完全であるため、redisが再起動されると、AOFを使用してデータが再構築されます.RDB永続化の構成:Redisはデータセットのスナップショットをdumpからdumpにする.rdbファイルにあります.また、プロファイルによりRedisサーバdumpのスナップショットの頻度を変更する、6379を開くこともできる.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メモリスナップショット.AOF永続化構成:Redisの構成ファイルには、appendfsync always#がデータ変更が発生するたびにAOFファイルに書き込まれる3つの同期方式があります.appendfsync everysec#AOFのデフォルトポリシーである毎秒同期します.appendfsync no#は同期していません.効率的ですが、データは永続化されません.
RDBとAOFのメリットとデメリット
RDBの長所と短所:この方法を採用すると、Redisデータベース全体に1つのファイルしか含まれません.これはファイルバックアップにとって非常に完璧です.たとえば、最近の24時間のデータを1時間に1回アーカイブするとともに、最近の30日間のデータを毎日アーカイブする予定です.このようなバックアップポリシーにより、システムに災害障害が発生すると、リカバリが容易になります.AOF永続化メカニズムに比べて、RDBデータファイルに直接基づいてredisプロセスを再起動および復元することは、より迅速である.RDBはredisが対外的に提供する読み書きサービスに対して、影響は非常に小さく、redisに高性能を維持させることができる.redisメインプロセスはforkのサブプロセスを必要とし、サブプロセスにディスクIO操作を実行させてRDBの持続化を行うだけでよいからである.ディザスタリカバリにとって、RDBは非常に良い選択です.個別のファイルを圧縮して他のストレージメディアに移行するのは簡単です.redis障害時に、できるだけ少ないデータ損失をしたい場合は、RDBはAOFがないほうがいいです.一般的に、RDBデータスナップショットファイルは、5分ごとに生成されるか、またはそれ以上の時間ごとに生成されます.この場合、redisプロセスがダウンタイムすると、最近の5分のデータが失われることを受け入れなければなりません.RDBは、forkサブプロセスがRDBスナップショットデータファイルの生成を実行するたびに、データファイルが特に大きい場合、クライアントに提供されるサービスを数ミリ秒、または数秒停止させる可能性がある.
AOFの長所と短所:AOFはデータを失わないようによりよく保護することができ、一般的にAOFは1秒おきにバックグラウンドスレッドを通じてfsync操作を実行し、最大1秒のデータを失う.AOFログファイルはappend-onlyモードで書き込まれるため、ディスクアドレスのオーバーヘッドがなく、書き込み性能が非常に高く、ファイルが破損しにくい.今回の操作でデータの半分を書き込むだけでシステムがクラッシュする問題が発生した場合は、Redisの次の起動前にredis-check-aofツールを使用してデータ整合性の問題を解決することができます.AOFログファイルが大きすぎる場合でも,バックグラウンド書き換え操作が発生しても,クライアントの読み書きには影響しない.rewrite logの場合、その中の命令が圧縮され、データを復元する必要がある最小ログが作成されるからです.新しいログファイルを作成するときは、古いログファイルは通常通りに書き込まれます.新しいmerge後のログファイルreadyの場合は、新しい古いログファイルを交換すればよい.したがって、rewrite切り替えを行うと、データのセキュリティがより保証されます.AOFは、すべての変更操作を記録するために明確で分かりやすい形式のログ・ファイルを使用しており、災害的な誤削除の緊急復旧に適しています.例えば、flushallコマンドですべてのデータを空にしてしまった人がいて、この時点でバックグラウンドrewriteが発生していない限り、AOFファイルをすぐにコピーして、最後のflushallコマンドを削除してから、aofファイルを戻して、リカバリメカニズムを通じて、自動的にすべてのデータをリカバリすることができます.同じ数のデータセットの場合、AOFファイルは通常RDBファイルより大きい.RDBは、大きなデータセットを復元する際の速度がAOFの復元速度よりも速い.AOFがオンになると、サポートされる書き込みQPSはRDBがサポートする書き込みQPSよりも低くなります.AOFは一般的に毎秒fsync 1回のログファイルに構成されるからです.AOFのような複雑なコマンドログ/merge/再生に基づく方法は、RDBが完全なデータスナップショットファイルを毎回永続化する方法よりも脆弱で、バグが発生しやすい.選択方法
RDBとAOFはどのように選択しますか?RDBだけを使用しないでください.それは多くのデータを失うことになります.AOFだけを使用しないでください.それは2つの問題があります.第一に、AOFを通じて冷たい準備をして、RDBをしていないと回復速度が速くなります.第二に、RDBはデータスナップショットを簡単に粗暴に生成するたびに、AOFのような複雑なバックアップとリカバリメカニズムのバグを回避することができる.redisは同時に2つの持続化方式を開くことをサポートし、AOFとRDBの2つの持続化メカニズムを総合的に使用することができ、AOFでデータが失われないことを保証し、データ回復の第1の選択とすることができる.RDBで異なる程度の冷却を行い、AOFファイルが失われたり破損したりして使用できない場合、RDBを使用して迅速なデータ復旧を行うこともできます.
永続化の目的は、主に災害復旧、データ復旧です.Redisのデータはすべてメモリに入っているので、Redisが切れて構成が永続化されていなければ、再起動時にデータがすべて失われます.突然、大量の要求が来て、キャッシュはすべて命中することができなくて、キャッシュの雪崩をもたらして、mysqlは大量の要求を積むことができなくて、全体のシステムの崩壊をもたらします.Redisを永続化すれば、Redisが故障してもすぐに再起動し、対外的にサービスを提供することができます.
Redis ：
RDB持続化:指定した時間間隔内にメモリ中のデータセットスナップショットをディスクに書き込み、実際の操作過程はforkのサブプロセスであり、まずデータセットを一時ファイルに書き込み、書き込みに成功した後、前のファイルを置き換え、バイナリ圧縮で記憶する.AOF永続化:AOFメカニズムは各書き込みコマンドをログとしてappend-onlyのモードで1つのログファイルに書き込み、redisが再起動するとAOFログの書き込みコマンドを再生することでデータセット全体を再構築することができる.RDBとAOFにより、Redisメモリのデータをディスクに永続化したり、アリクラウドなどの他の場所に分割したりすることができます.Redisが切れた場合、ディスクやアリクラウドなどからデータをRedisにコピーし、Redisを再起動すると、Redisは自動的にファイルに基づいてデータを再構築します.RDBとAOFの2つの永続化メカニズムを同時に使用すると、AOFのデータがより完全であるため、redisが再起動されると、AOFを使用してデータが再構築されます.RDB永続化の構成:Redisはデータセットのスナップショットをdumpからdumpにする.rdbファイルにあります.また、プロファイルによりRedisサーバdumpのスナップショットの頻度を変更する、6379を開くこともできる.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メモリスナップショット.AOF永続化構成:Redisの構成ファイルには、appendfsync always#がデータ変更が発生するたびにAOFファイルに書き込まれる3つの同期方式があります.appendfsync everysec#AOFのデフォルトポリシーである毎秒同期します.appendfsync no#は同期していません.効率的ですが、データは永続化されません.
RDBとAOFのメリットとデメリット
RDBの長所と短所:この方法を採用すると、Redisデータベース全体に1つのファイルしか含まれません.これはファイルバックアップにとって非常に完璧です.たとえば、最近の24時間のデータを1時間に1回アーカイブするとともに、最近の30日間のデータを毎日アーカイブする予定です.このようなバックアップポリシーにより、システムに災害障害が発生すると、リカバリが容易になります.AOF永続化メカニズムに比べて、RDBデータファイルに直接基づいてredisプロセスを再起動および復元することは、より迅速である.RDBはredisが対外的に提供する読み書きサービスに対して、影響は非常に小さく、redisに高性能を維持させることができる.redisメインプロセスはforkのサブプロセスを必要とし、サブプロセスにディスクIO操作を実行させてRDBの持続化を行うだけでよいからである.ディザスタリカバリにとって、RDBは非常に良い選択です.個別のファイルを圧縮して他のストレージメディアに移行するのは簡単です.redis障害時に、できるだけ少ないデータ損失をしたい場合は、RDBはAOFがないほうがいいです.一般的に、RDBデータスナップショットファイルは、5分ごとに生成されるか、またはそれ以上の時間ごとに生成されます.この場合、redisプロセスがダウンタイムすると、最近の5分のデータが失われることを受け入れなければなりません.RDBは、forkサブプロセスがRDBスナップショットデータファイルの生成を実行するたびに、データファイルが特に大きい場合、クライアントに提供されるサービスを数ミリ秒、または数秒停止させる可能性がある.
AOFの長所と短所:AOFはデータを失わないようによりよく保護することができ、一般的にAOFは1秒おきにバックグラウンドスレッドを通じてfsync操作を実行し、最大1秒のデータを失う.AOFログファイルはappend-onlyモードで書き込まれるため、ディスクアドレスのオーバーヘッドがなく、書き込み性能が非常に高く、ファイルが破損しにくい.今回の操作でデータの半分を書き込むだけでシステムがクラッシュする問題が発生した場合は、Redisの次の起動前にredis-check-aofツールを使用してデータ整合性の問題を解決することができます.AOFログファイルが大きすぎる場合でも,バックグラウンド書き換え操作が発生しても,クライアントの読み書きには影響しない.rewrite logの場合、その中の命令が圧縮され、データを復元する必要がある最小ログが作成されるからです.新しいログファイルを作成するときは、古いログファイルは通常通りに書き込まれます.新しいmerge後のログファイルreadyの場合は、新しい古いログファイルを交換すればよい.したがって、rewrite切り替えを行うと、データのセキュリティがより保証されます.AOFは、すべての変更操作を記録するために明確で分かりやすい形式のログ・ファイルを使用しており、災害的な誤削除の緊急復旧に適しています.例えば、flushallコマンドですべてのデータを空にしてしまった人がいて、この時点でバックグラウンドrewriteが発生していない限り、AOFファイルをすぐにコピーして、最後のflushallコマンドを削除してから、aofファイルを戻して、リカバリメカニズムを通じて、自動的にすべてのデータをリカバリすることができます.同じ数のデータセットの場合、AOFファイルは通常RDBファイルより大きい.RDBは、大きなデータセットを復元する際の速度がAOFの復元速度よりも速い.AOFがオンになると、サポートされる書き込みQPSはRDBがサポートする書き込みQPSよりも低くなります.AOFは一般的に毎秒fsync 1回のログファイルに構成されるからです.AOFのような複雑なコマンドログ/merge/再生に基づく方法は、RDBが完全なデータスナップショットファイルを毎回永続化する方法よりも脆弱で、バグが発生しやすい.選択方法
RDBとAOFはどのように選択しますか?RDBだけを使用しないでください.それは多くのデータを失うことになります.AOFだけを使用しないでください.それは2つの問題があります.第一に、AOFを通じて冷たい準備をして、RDBをしていないと回復速度が速くなります.第二に、RDBはデータスナップショットを簡単に粗暴に生成するたびに、AOFのような複雑なバックアップとリカバリメカニズムのバグを回避することができる.redisは同時に2つの持続化方式を開くことをサポートし、AOFとRDBの2つの持続化メカニズムを総合的に使用することができ、AOFでデータが失われないことを保証し、データ回復の第1の選択とすることができる.RDBで異なる程度の冷却を行い、AOFファイルが失われたり破損したりして使用できない場合、RDBを使用して迅速なデータ復旧を行うこともできます.