1.エンタープライズレベルの永続的な構成戦略
企業では、RDB生成戦略はデフォルトとほぼ同じです
60 10000を節約：RDBができる限り最大1分のデータを失うことを確認したい場合は、1分ごとにスナップショットを生成してみてください。低ピーク期間中、データの量は少なく、不要です
10000-> RDBを生成、1000-> RDB、独自のアプリケーションとビジネスデータに従って、自分で決定
AOFをオンにする必要があります、fsync、毎秒
auto-aof-rewrite-percentage 100：現在のAOFサイズが前回の100％を超え、前回の2倍になった
auto-aof-rewrite-min-size 64mb：データ量に応じて、16mb、32mb
2.エンタープライズレベルのデータバックアップソリューション
RDBはコールドバックアップに非常に適しています。世代ごとに、変更はありません。
データバックアップソリューション
（1）データバックアップを実行するcrontabスケジュールスケジューリングスクリプトを記述します
（2）RDBバックアップを1時間ごとにコピーしてディレクトリに移動し、最後の48時間のバックアップのみを保持します
（3）毎日のRDBのコピーを毎日保持しますバックアップ、ディレクトリに移動し、最新の月のバックアップのみを保持し
ます（4）バックアップをコピーするたびに、古いバックアップを削除します
（5）バックアップして、現在のサーバー上のすべてのデータを毎晩送信しますリモートクラウドサービスに移動する
/ usr / local / redis
1時間ごとにコピーしてバックアップし、48時間前にデータを削除する
crontab -e
0 * * * * sh /usr/local/redis/copy/redis_rdb_copy_hourly.sh
redis_rdb_copy_hourly.sh
＃！/ bin / sh cur_date = `date +％Y％m％d％ k` rm -rf / usr / local / redis / snapshotting / $ cur_date mkdir / usr / local / redis / snapshotting / $ cur_date cp / var / redis / 6379 / dump.rdb / usr / local / redis / snapshotting / $ cur_date del_date = `date -d -48hour +％Y％m％d％ k` rm -rf / usr / local / redis / snapshotting / $ del_date
1日に1回コピーする
crontab -e
0 0 * * * sh /usr/local/redis/copy/redis_rdb_copy_daily.sh
redis_rdb_copy_daily.sh
＃！/ bin / sh cur_date = `date +％Y％m％d` rm -rf / usr / local / redis / snapshotting / $ cur_date mkdir / usr / local / redis / snapshotting / $ cur_date cp / var / redis / 6379 / dump.rdb / usr / local / redis / snapshotting / $ cur_date del_date = `date -d -1month +％Y％m％d` rm -rf / usr / local / redis / snapshotting / $ del_date
1日に1回、すべてのデータをリモートクラウドサーバーにアップロードする
3.データ復旧計画
（1）redisプロセスがハングした場合は、redisプロセスを再起動し、AOFログファイルに基づいてデータを直接復元します
これ以上のデモはありません。AOFデータリカバリの部分で、デモ、fsync毎秒、最大1秒が失われます
（2）redisプロセスが配置されているマシンがハングした場合、マシンを再起動した後、redisプロセスを再起動して、AOFログファイルに基づいて直接データリカバリを実行してください。
AOFは破損しておらず、AOFに基づいて直接回復することもできます
AOF追加のみ、順次書き込み、AOFファイルが破損している場合は、redis-check-aof修正を使用
（3）redis内の最新のAOFおよびRDBファイルが失われた/破損した場合、現在マシン上にある最新のRDBデータのコピーに基づいてデータを復元することができます
現在の最新のAOFおよびRDBファイルは、回復できないために失われている/損傷している。一般に、人為的なマシンの誤動作ではない
ビッグデータシステム、hadoop、hadoopに保存されている多数のデータファイルに対応するディレクトリを誤って配置した人、rm -rf、私の友人の小さな会社、操作とメンテナンスが信頼できず、アクセス許可があまり良くありません。
/ var / redis / 6379の下のファイルが削除されました
最新のRDBバックアップを見つけます。時間レベルのバックアップは問題ありません。時間レベルのバックアップは最新である必要があります。redisにコピーすると、1時間のデータに復元できます
災害復旧訓練
appendonly.aof + dump.rdb、データを回復するためにappendonly.aofを優先しますが、redisによって自動的に生成されたappendonly.aofにはデータがないことがわかりました
次に、私たち自身のdump.rdbにはデータがありますが、明らかに私たちのデータは使用されていません
redisが起動すると、メモリ内のデータに基づいて自動的にリベースし、空のデータを直接使用して最新のRDBスナップショットを生成し、データを上書きし、過去のdump.rdbをコピーします
redisを停止したら、appendonly.aofを実際に削除してから、dump.rdbをコピーして、redisを再起動する必要があります。
appendonly.aofを削除しても非常に簡単ですが、AOF永続性がオンになっているため、ファイルがそこになくてもredisはまずAOFに基づいて復元し、次に新しい空のAOFファイルを作成します
Redisを停止し、構成内のAOFを一時的に閉じてから、RDBのコピーをコピーしてから、Redisを再起動します。データを回復できますか、それを回復できますか
脳が熱くなったら、redisをオフにし、手動で構成ファイルを変更し、aofを開いて、redisを再起動します。データがなくなり、aofファイルが空になり、すべてのデータがなくなります
データ損失の場合、AOFとRDBを二重に保ちながら、RDBコールドバックアップに基づいてデータを完全に復元する方法
redisの停止、aofのクローズ、rdbバックアップのコピー、redisの再起動、データ回復の確認、コマンドラインでのredis設定の直接変更、aofのオープン、このredisはメモリ内のデータに対応するログをaofファイルに書き込みます
このとき、aofとrdbの2つのデータファイルのデータが同期されます
config set appendonly yes構成パラメーターをホット変更します。構成ファイルの実際のパラメーターは永続的に変更されない可能性があります。redisを再度停止し、手動で構成ファイルを変更し、aofコマンドを開いて、redisを再起動します。
（4）現在のマシン上のすべてのRDBファイルが破損している場合は、リモートクラウドサービスから最新のRDBスナップショットをプルしてデータを回復します
（5）たとえば、特定の時間オンラインになったプログラムがデータを完全に汚染し、データが完全に間違っているなど、重大なデータエラーが見つかった場合は、より早い時点を選択してデータを回復できます。
たとえば、コードは12時にオンラインになり、コードにバグがあることが判明したため、コードによって生成されたすべてのキャッシュデータがredisに書き込まれましたが、すべて間違っていました。
11ポイントのRDBのコールドバックアップを見つけ、上記の手順に従ってデータを11ポイントに復元しますが、問題ありませんか？