Redisの永続化方法は何ですか?
Redis持続化方式
1 Redis永続化とは
redisの値はメモリに格納されているため、突然の電源オフなどの特殊な状況を防ぐために、データの永続化バックアップが必要です.メモリデータをHDDに保存
2 Redis永続化ストレージ方式
2.1 RDB持続化
RDBはバイナリファイルで、ある時点で一時ファイルにデータを書き込み、永続化が完了した後、この一時ファイルで前回永続化したファイルを置き換え、データ回復に達する.
利点:単独のサブプロセスを使用して永続化を行い、メインプロセスはIO操作を一切行わず、redisの高性能を保証する.
欠点:RDBは一定時間間隔で永続化され、永続化間にredisが故障するとデータ損失が発生する.データの要求が厳格でない場合に適しています
ここで、この実行データが一時ファイルに書き込まれた時点は、構成によって自己決定され、構成redisによってn秒以内にm個以上のkeyが変更された場合、RDB動作が実行される.この操作は,この時点でRedisのすべてのデータ,スナップショットデータを1回保存することに似ている.この持続化方法は通常snapshotsとも呼ばれる.
RDBはデフォルトでオンであり、redis.confの具体的な構成パラメータは以下の通りである.
注意:テスト時にrootユーザー操作を使用する
2.2 AOF持続化
Append-Only Fileは、「操作+データ」をフォーマット命令で操作ログファイルの末尾に追加し、append操作が戻った後(ファイルに書き込まれたか、書き込む)、実際のデータ変更を行い、「ログファイル」は履歴のすべての操作過程を保存した.サーバがデータリカバリを必要とする場合、このログファイルを直接replayすることで、すべての操作手順を復元できます.AOFは比較的信頼性が高く、AOFファイルの内容は文字列であり、非常に読みやすく、解析しやすい.
利点:より高いデータ整合性を保つことができ、fileを追加する時間を1 sに設定すると、redisが故障すると、最大1 sのデータが失われる.ログ書き込みが不完全であればredis-check-aofをサポートしてログ修復を行う.AOFファイルがrewriteされる前に(ファイルが大きすぎるとコマンドがマージされて書き換えられます)、誤操作のflushallなどのコマンドの一部を削除できます.
欠点:より高いデータ整合性を保つことができ、追加fileを設定する時間が1 sであれば、redisが故障した場合、最大1 sのデータが失われる.ログ書き込みが不完全であればredis-check-aofをサポートしてログ修復を行う.AOFファイルがrewriteされる前に(ファイルが大きすぎるとコマンドがマージされて書き換えられます)、誤操作のflushallなどのコマンドの一部を削除できます.
欠点:AOFファイルはRDBファイルより大きく、リカバリ速度が遅い.
AOFはログファイルと簡単に考えることができ、このファイルは「変更操作」(例えばset/delなど)しか記録されず、serverの中で大量の変更操作が続くと、AOFファイルが非常に膨大になり、serverが失効した後、データ復旧の過程が長くなることを意味する.実際、1つのデータが何度も変更されると、複数のAOFレコードが生成されますが、実際には現在の状態を保存すれば、履歴の操作レコードは破棄できます.AOF永続化モードには「AOF rewrite」も伴っているからだ.
AOFの特性は比較的安全であることを決定し、データの損失が少ないことを望む場合は、AOFモードを採用することができます.AOFファイルが書き込まれている間に突然serverが失効した場合、ファイルの最後の記録が不完全になる可能性があります.aofファイルのリカバリで正常になるように、手動またはプログラムで不完全な記録を検出して修正することができます.また、redis永続化手段にaofがある場合は、server障害が失効した後に再起動する前に、aofファイルの整合性を検出する必要があります.
AOFデフォルトクローズ、オープンメソッド、プロファイルの変更reds.conf:appendonly yes
AOFはファイル操作であり、変更操作が比較的密集しているserverに対しては、ディスクIOの負荷が重くなるに違いない.さらにlinuxは、write操作のたびに実際のディスク操作をトリガーするのではなく、bufferに入り、bufferデータがバルブ値に達したときに実際の書き込みをトリガー(他のタイミングもある)する「遅延書き込み」手段を採用しています.これはlinuxのファイルシステムの最適化ですが、bufferがディスクにリフレッシュされていない場合は、危険をもたらす可能性があります.このとき、物理機器が無効になる(例えば、電源が切れる)と、最後のaofレコードまたは複数のaofレコードが失われる可能性がある.上記のプロファイルから、redisは3つのaofレコード同期オプションを提供していることがわかります.
Always:aofレコードごとにすぐにファイルに同期します.これは最も安全な方法です.ディスクの操作とブロックの遅延も多く、IOの支出が大きいと考えられています.
everysec:毎秒1回同期し、パフォーマンスとセキュリティが比較的中庸な方法であり、redisが推奨する方法でもあります.物理サーバの障害が発生した場合、最近の1秒以内にaofレコードが失われる可能性があります(一部が失われる可能性があります).
No:redisはファイル同期を直接呼び出すのではなく、オペレーティングシステムに渡して処理し、オペレーティングシステムはbuffer充填状況/チャネルアイドル時間などの選択に基づいて同期をトリガすることができる.これは一般的なファイル操作方法です.パフォーマンスが優れており、物理サーバが故障した場合、OS構成によってデータ損失が発生します.
実は、私たちが選択できるのは少なすぎて、everysecは最高の選択です.各データが非常に信頼性が高いことを気にする場合は、「リレーショナル・データベース」を選択することをお勧めします.
2.3 AOFとRDBの違い
RDB:
RDBは、ある時点で一時ファイルにデータを書き込み、永続化が完了した後、この一時ファイルに前回永続化したファイルを置き換え、データ復旧に達する.
利点:個々のサブプロセスを使用して永続化を行い、メインプロセスはIO操作を一切行わず、Redisの高性能を保証する
欠点:RDBは一定時間間隔で永続化され、永続化の間にRedisが故障するとデータ損失が発生する.データの要求が厳格でない場合に適しています
AOF:
Append-only-fileは、「操作」+「データ」y 8 iフォーマット命令を操作ログファイルの末尾に追加し、append操作が戻った後(ファイルに書き込まれたか、書こうとしている)、実際のデータ変更を行い、「ログファイル」は履歴にある操作手順を保存します.サーバがデータリカバリを必要とする場合、このログファイルを直接replayすることで、すべての操作プロセスを復元することができます.AOFは比較的信頼性が高く、mysqlのbin.log、apache.log、zookeeperのtxn-logとまったく同じです.AOFファイルの内容は文字列で、解析や読みやすいです.
利点:より高いデータ整合性を保つことができ、最適なfileを設定する時間が1 sであれば、Redisが故障した場合、最大1 sのデータが失われます.ログ書き込みが不完全であればredis-check-aofをサポートしてログ修復を行う.AOFファイルがrewriteされる前に(ファイルが大きすぎるとコマンドがマージされて書き換えられます)、誤操作のflushallなどのコマンドの一部を削除できます.
欠点:AOFファイルはRDBファイルより大きく、リカバリ速度が遅い.
1 Redis永続化とは
redisの値はメモリに格納されているため、突然の電源オフなどの特殊な状況を防ぐために、データの永続化バックアップが必要です.メモリデータをHDDに保存
2 Redis永続化ストレージ方式
2.1 RDB持続化
RDBはバイナリファイルで、ある時点で一時ファイルにデータを書き込み、永続化が完了した後、この一時ファイルで前回永続化したファイルを置き換え、データ回復に達する.
利点:単独のサブプロセスを使用して永続化を行い、メインプロセスはIO操作を一切行わず、redisの高性能を保証する.
欠点:RDBは一定時間間隔で永続化され、永続化間にredisが故障するとデータ損失が発生する.データの要求が厳格でない場合に適しています
ここで、この実行データが一時ファイルに書き込まれた時点は、構成によって自己決定され、構成redisによってn秒以内にm個以上のkeyが変更された場合、RDB動作が実行される.この操作は,この時点でRedisのすべてのデータ,スナップショットデータを1回保存することに似ている.この持続化方法は通常snapshotsとも呼ばれる.
RDBはデフォルトでオンであり、redis.confの具体的な構成パラメータは以下の通りである.
#dbfilename：
dbfilename dump.rdb
#dir： ， /redis/redis-5.0.5/src redis-cli，
src
dir ./
##snapshot ，save
## 900 ， ， snapshot
## ， ，
## “save” snapshot
#save ， 1 key 900s ； 10 key300s ； 10000
key60s 。
save 900 1
save 300 10
save 60 10000
## snapshot ， “ ”，“ ” / /OS
stop-writes-on-bgsave-error yes
## rdb ， “yes”， “ cpu ”，
rdbcompression yes
注意:テスト時にrootユーザー操作を使用する
2.2 AOF持続化
Append-Only Fileは、「操作+データ」をフォーマット命令で操作ログファイルの末尾に追加し、append操作が戻った後(ファイルに書き込まれたか、書き込む)、実際のデータ変更を行い、「ログファイル」は履歴のすべての操作過程を保存した.サーバがデータリカバリを必要とする場合、このログファイルを直接replayすることで、すべての操作手順を復元できます.AOFは比較的信頼性が高く、AOFファイルの内容は文字列であり、非常に読みやすく、解析しやすい.
利点:より高いデータ整合性を保つことができ、fileを追加する時間を1 sに設定すると、redisが故障すると、最大1 sのデータが失われる.ログ書き込みが不完全であればredis-check-aofをサポートしてログ修復を行う.AOFファイルがrewriteされる前に(ファイルが大きすぎるとコマンドがマージされて書き換えられます)、誤操作のflushallなどのコマンドの一部を削除できます.
欠点:より高いデータ整合性を保つことができ、追加fileを設定する時間が1 sであれば、redisが故障した場合、最大1 sのデータが失われる.ログ書き込みが不完全であればredis-check-aofをサポートしてログ修復を行う.AOFファイルがrewriteされる前に(ファイルが大きすぎるとコマンドがマージされて書き換えられます)、誤操作のflushallなどのコマンドの一部を削除できます.
欠点:AOFファイルはRDBファイルより大きく、リカバリ速度が遅い.
AOFはログファイルと簡単に考えることができ、このファイルは「変更操作」(例えばset/delなど)しか記録されず、serverの中で大量の変更操作が続くと、AOFファイルが非常に膨大になり、serverが失効した後、データ復旧の過程が長くなることを意味する.実際、1つのデータが何度も変更されると、複数のAOFレコードが生成されますが、実際には現在の状態を保存すれば、履歴の操作レコードは破棄できます.AOF永続化モードには「AOF rewrite」も伴っているからだ.
AOFの特性は比較的安全であることを決定し、データの損失が少ないことを望む場合は、AOFモードを採用することができます.AOFファイルが書き込まれている間に突然serverが失効した場合、ファイルの最後の記録が不完全になる可能性があります.aofファイルのリカバリで正常になるように、手動またはプログラムで不完全な記録を検出して修正することができます.また、redis永続化手段にaofがある場合は、server障害が失効した後に再起動する前に、aofファイルの整合性を検出する必要があります.
AOFデフォルトクローズ、オープンメソッド、プロファイルの変更reds.conf:appendonly yes
## aof ， “no”， “yes” aof
## “yes” ，aof /
appendonly yes
## aof
appendfilename appendonly.aof
## aof ， ：always everysec no, everysec
appendfsync everysec
## aof-rewrite ，appendfsync ，"no" “ ”，“yes” “ ”， “no”
no-appendfsync-on-rewrite no
##aof rewrite (mb,gb), aof rewrite， “64mb”，
“512mb”
auto-aof-rewrite-min-size 64mb
## “ ”rewrite， rewrite aof 。
## rewrite ，redis “ aof” ( A)， aof A*(1 + p)
## rewrite， aof ， aof 。
auto-aof-rewrite-percentage 100
AOFはファイル操作であり、変更操作が比較的密集しているserverに対しては、ディスクIOの負荷が重くなるに違いない.さらにlinuxは、write操作のたびに実際のディスク操作をトリガーするのではなく、bufferに入り、bufferデータがバルブ値に達したときに実際の書き込みをトリガー(他のタイミングもある)する「遅延書き込み」手段を採用しています.これはlinuxのファイルシステムの最適化ですが、bufferがディスクにリフレッシュされていない場合は、危険をもたらす可能性があります.このとき、物理機器が無効になる(例えば、電源が切れる)と、最後のaofレコードまたは複数のaofレコードが失われる可能性がある.上記のプロファイルから、redisは3つのaofレコード同期オプションを提供していることがわかります.
Always:aofレコードごとにすぐにファイルに同期します.これは最も安全な方法です.ディスクの操作とブロックの遅延も多く、IOの支出が大きいと考えられています.
everysec:毎秒1回同期し、パフォーマンスとセキュリティが比較的中庸な方法であり、redisが推奨する方法でもあります.物理サーバの障害が発生した場合、最近の1秒以内にaofレコードが失われる可能性があります(一部が失われる可能性があります).
No:redisはファイル同期を直接呼び出すのではなく、オペレーティングシステムに渡して処理し、オペレーティングシステムはbuffer充填状況/チャネルアイドル時間などの選択に基づいて同期をトリガすることができる.これは一般的なファイル操作方法です.パフォーマンスが優れており、物理サーバが故障した場合、OS構成によってデータ損失が発生します.
実は、私たちが選択できるのは少なすぎて、everysecは最高の選択です.各データが非常に信頼性が高いことを気にする場合は、「リレーショナル・データベース」を選択することをお勧めします.
2.3 AOFとRDBの違い
RDB:
RDBは、ある時点で一時ファイルにデータを書き込み、永続化が完了した後、この一時ファイルに前回永続化したファイルを置き換え、データ復旧に達する.
利点:個々のサブプロセスを使用して永続化を行い、メインプロセスはIO操作を一切行わず、Redisの高性能を保証する
欠点:RDBは一定時間間隔で永続化され、永続化の間にRedisが故障するとデータ損失が発生する.データの要求が厳格でない場合に適しています
AOF:
Append-only-fileは、「操作」+「データ」y 8 iフォーマット命令を操作ログファイルの末尾に追加し、append操作が戻った後(ファイルに書き込まれたか、書こうとしている)、実際のデータ変更を行い、「ログファイル」は履歴にある操作手順を保存します.サーバがデータリカバリを必要とする場合、このログファイルを直接replayすることで、すべての操作プロセスを復元することができます.AOFは比較的信頼性が高く、mysqlのbin.log、apache.log、zookeeperのtxn-logとまったく同じです.AOFファイルの内容は文字列で、解析や読みやすいです.
利点:より高いデータ整合性を保つことができ、最適なfileを設定する時間が1 sであれば、Redisが故障した場合、最大1 sのデータが失われます.ログ書き込みが不完全であればredis-check-aofをサポートしてログ修復を行う.AOFファイルがrewriteされる前に(ファイルが大きすぎるとコマンドがマージされて書き換えられます)、誤操作のflushallなどのコマンドの一部を削除できます.
欠点:AOFファイルはRDBファイルより大きく、リカバリ速度が遅い.