redis持続化(RDB、AOF)

4550 ワード

redisはメモリデータベースであるが、メモリに限らず、redisは永続化する方法がある.
3つの持続的な方法があります.
方式1:dumpを生成する.rdbファイル
方式2:appendonlyを生成する.aofファイル
方式3:master/slave(主にコピー読み書きから分離)

RDB:(redis database)


概要:


一般的に、rdbは指定された時間間隔でメモリ内のデータセットスナップショットをディスク、すなわちsnapshotスナップショットに書き込み、復元したい場合はスナップショットファイル(dump.rdbファイル)を直接読み取り、メモリに復元することができる.
redisは単独でforkのサブプロセスを永続化し、まずデータを一時ファイルに書き込み、永続化が終了したら(すなわち、一時ファイルが作成された)、前回永続化して生成したrdbファイルに置き換えます.プロセス全体で、メインプロセスはIO操作を一切行わない.
rdbには、最後に永続化されたデータが失われる可能性があるという欠点があります.時間帯によってスナップショットが行われるからです.

詳細:


Rdb:デフォルト状態
セーブ900 1 300秒以内に10回未満、900秒以内に1回、バックアップ
セーブ300 10,060秒以内に10,000回未満、300秒以内に10回、バックアップ
Save 60 10,000 60秒で10,000回、バックアップ(このバックアップはすぐではなく、50秒で10,000回に達しても60秒待ってdump.rdbファイルを生成する必要があります)
saveでは、bgsaveコマンドは直接バックアップでき、上記の条件を待つ必要はありません.
save:保存するだけで、その他は関係なく、すべてブロックします.(つまりdumpファイルを書き込む場合、redisが占有するメモリで書き込み操作ができない)
bgsave:redisはバックグラウンドで非同期で高速操作を行い、スナップショットと同時にクライアントの要求に応答することができ、lastsaveコマンドで最後にスナップショットを正常に実行した時間を取得することができる.

トラップ:


1.flushallコマンド:すべてのメモリのredisデータを消去し、すぐにdumpを生成します.rdbファイルですが、空になったため、このファイルは空に記録されています.
2.shutdownコマンド:redis-cli SHUTDOWNによってredisを停止することは、安全に終了するモードであり、redisは終了時にメモリ内のデータを直ちに完全なrdbスナップショットを生成する.
3.redisに新しいデータをいくつか保存し、kill-9でredisプロセスを乱暴に殺し、redis障害が異常に終了し、メモリデータが失われたシーンをシミュレートする.
今回、redisプロセスが異常に殺され、データがdumpファイルに入らず、最新のデータがいくつか失われたことが分かった.
4.機械が突然切られ、ここ数分のデータが回復できない可能性がある.
5.一般的にdumpを生成する.rdbファイルの後、再びそのファイルを他のマシンにバックアップし、リカバリ時にdump.rdbファイルをredisディレクトリにコピーし、起動すればよい
 

知識点:redis起動の判断方法


方法一:ps-ef|grep redis
方法2:lsof-i:6379

知識点:redisを起動する方法(次の2つのコマンドを前後して起動)


redis-server/myredis/redis.conf
redis-cli -p 6379

ナレッジポイント:Linuxでディスク領域とメモリ領域を表示するコマンド


df-hディスク領域を見る
freeメモリ領域を見る
---------------------------------------------------------------------------------------------------------------------------------------------
以下はブログから抜粋したもっと詳細な説明です.https://blog.csdn.net/why15732625998/article/details/80565044

2.1 RDB持続化機構の構成


redisでconfファイル、つまりここの/etc/redis_6379/6379.confはRDB持続化を構成します.
save 60 1000

60 s毎に1000個を超えるkeyが変更すると、新しいdumpが生成される.rdbファイルは、現在のredisメモリ内の完全なデータスナップショットであり、この操作はsnapshottingとも呼ばれ、スナップショットはsaveまたはbgsaveコマンドを手動で呼び出し、rdbスナップショット生成を同期または非同期で実行することもできる.
saveは複数設定ことができ、複数のsnapshottingチェックポイントであり、1つのチェックポイントに着くたびにチェックして、指定したkey数が変更されたかどうか、あれば新しいdumpを生成する.rdbファイル.次のように構成されています.
save 900 1
save 300 10
save 60 10000

2.2 RDB持続化機構に基づくデータ回復実験


1.redisにいくつかのデータを保存し、すぐにredisプロセスを停止し、redisを再起動し、さっき挿入したデータがまだ存在しないことを確認します.なぜですか.
redis-cli SHUTDOWNという方法でredisを停止するのは、実際には安全に終了するモードであり、redisは終了するとメモリのデータをすぐに完全なrdbスナップショットを生成します。

2.redisに新しいデータをいくつか保存し、kill-9でredisプロセスを乱暴に殺し、redis障害が異常に終了し、メモリデータが失われるシーンをシミュレートする
今回、redisプロセスが異常に殺され、データがdumpファイルに入らず、最新のデータがいくつか失われていることがわかりました.
3.手動でsaveチェックポイントを設定し、save 5 1起動レポートpidが既に存在する場合は/var/run/redis_6379.pidを削除する
rm -rf redis_6379.pid

いくつかのデータを書き込んで、5秒待ってredisプロセスを停止して、redisを再起動して、さっき挿入したデータがまだいないことを見て、この時私たちはデータが順調に回復できることを発見しました.
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
 

AOF:


概要:


aof用ファイル追加方式は、ログに記録する方式で永続化を実現し、すべての書き込み操作を記録するappendonlyを生成する.aofファイルは、リカバリ時に起動時に読み込むだけでよい.
redis.confファイルでは、デフォルトはappendonly noで、yesに変更してaofメカニズムを起動します.

詳細:


1.2つのリカバリ(バックアップ)ポリシーが同時に存在する場合、誰の話を聞きますか?
まずappendonlyを探してください.aofファイル(dump.rdbを無視)
2.aofファイルが破損した場合、以下のコマンドでaofを修復できます.
redis-check-aof --fix appendonly.aof
rdbファイルリカバリは、redis-check-dump
3.appendsync:デフォルトはeverysec、持続化パラメータ設定、非同期操作、毎秒記録、1秒以内にダウンタイムした場合、データが失われる.
このパラメータにはalwaysとNoもあります.同期永続化(パフォーマンスが悪い)と非永続化をそれぞれ表す.
4.rewrite:aofファイルのダイエットメカニズム、その最適化aofファイルを圧縮
5.no-appendfsync-no-rewrite:書き換える時にappendsyncを運用し、no-appendfsync-no-rewriteはデフォルトのnoでよい.書き換える時のデータの安全性を保証する.
 
 

選択方法:


1.迅速なリカバリとバックアップ、データに対する感度、完全性、要求が高くない------rdb単独で使用すればよい.
2.aofとrdbの併用を推奨
3.aofは単独で使用しないことを推奨
 

master/slave:


主従レプリケーションは
1.読み書き分離、io圧力の低減
2.バックアップ
このモードはよく使われ、持続化スキームの基礎はrdbとaofであるが、その特殊な戦略がある.
この章では、説明を省略します.