Redisの永続性、RDBモードとAOFモードの動作原理の詳細な説明と操作を理解する

redisの永続性

Redisはメモリレベルのキャッシングプログラムですが、つまり、Redisはデータキャッシングにメモリを使用しますが、データの永続性の目的を達成するために、特定の戦略に従ってメモリデータをハードディスクに保存できます。
現在、Redisは2つのタイプをサポートしています。さまざまなタイプのデータ永続性ストレージメカニズム、RDBおよびAOF

• RDBは、ある時点でのRedisのスナップショットと見なすことができ、災害復旧に適しています。スナップショットと見なすか、Mysqlダンプとして理解することができます。
  • AOFは書き込み操作のログであり、理解を助けるためにMySQLBinlogとして使用できます。

RDBモード

RDBモードのしくみ

RDB（Redis DataBase）：時間ベースのスナップショット。デフォルトでは、最新のスナップショットのみが保持されます。特徴は、実行速度が比較的速いことです。欠点は、最後のスナップショットと現在の時点の間にスナップショットが作成されていないデータが失われる可能性があることです。

スナップショットを実装するためのRDBbgsaveの特定のプロセス：

• Redisは、マスタープロセスから子プロセスをフォークし、コピーオンライトメカニズムを使用します。子プロセスは、データをtmp-.rdbなどの一時ファイルとしてメモリに保存します。データが保存された後、最後に保存されたRDBファイルが保存されます。 RDBスナップショットが完了するたびにデータが確実に保存されるように、子プロセスを置き換えてから閉じます。
• RDBファイルを直接置き換える場合、突然の電源障害などの問題が発生したり、突然のシャットダウンで保存が停止してRDBファイルが完全に保存されなかったりしてデータが失われる可能性があるため、今後は毎回生成されたRDBファイルを手動で実行できます。バックアップ。履歴データを最大限に保存できます。

1. Redisはbgsaveコマンドを実行し、RedisはRDB / AOF子プロセスなどの子プロセスが現在実行中であると判断し、bgsaveコマンドは直接戻ります。
2. 子プロセスをフォークアウトすると、Redis親プロセスはフォーク操作中にブロックされます
3. fork人形逆回59117：M 13 Apr 13：44：40.312 *バックグラウンド保存はpid59180によって開始されました
4. 子プロセスプロセスは、メモリデータのクイック検索ファイルを生成します
5. 子プロセスは、親プロセスに処理を完了するように指示します
   

RDBの方法を実現する

• 同期を保存します。他のコマンドをブロックします。推奨されません
• bgsave非同期バックグラウンド実行、他の実行には影響しません
• 自動、ルールの指定、自動実行

RDB関連の構成ファイル

In the example below the behaviour will be to save:
 206 #   after 900 sec (15 min) if at least 1 key changed
 207 #   after 300 sec (5 min) if at least 10 keys changed
 208 #   after 60 sec if at least 10000 keys changed
save 900 1   #在九百秒内有一个触发我就执行
save 300 10
save 60 10000
dbfilename dump.rdb
dir ./     #编泽编译安装,默认RDB文件存放在启动redis的工作目录,建议明确指定存入目录
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes

RDBモードの長所と短所

RDBモードの利点

• RDBは、特定の時点でデータを保存するフルバックアップモードに適しています。redisコマンドbgsave（非ブロック、バックグラウンド実行）またはsave（書き込み操作をブロックする、推奨）コマンドを実行して、その時点でバックアップを自己定義できます。さらに多くの情報を保持できます。バックアップ、問題が発生した場合、バックアップに非常に適した別のタイムノードに復元すると便利です。このファイル形式は、次の
  ような後続のデータ分析のための多くのサードパーティツールをサポートします。RDBファイルは過去24時間以内に1時間ごとにバックアップできます。 、そして毎月の毎日、RDBファイルもバックアップします。このようにして、問題が発生した場合でも、いつでもデータセットを別のバージョンに復元できます。
• RDBはRedisのパフォーマンスを最大化できます。親プロセスがRDBファイルを保存する場合、子プロセスをフォークアウトするだけで、この子プロセスは次に保存されるすべての作業を処理します。親プロセスはディスクI / Oを実行する必要はありません。オペレーティング
• REBは、AOFよりも高速に、いくつかのGデータなどの多くのデータを回復します。

RDBのデメリット

• REB方式ではデータをリアルタイムで保存できず、最後のRDBバックアップから現在のメモリへのデータが失われる可能性があります。
  サーバーに障害が発生したときにデータの損失を回避する必要がある場合、RDBは適していません。Redisでは、さまざまな保存ポイントを設定してRDBファイルの保存頻度を制御できますが、ROBファイルはデータセット全体の状態を保存する必要があるため、簡単な操作ではありません。したがって、RDBファイルを少なくとも5分保存することができます。この場合、ダウンタイムが発生すると、数分のデータが失われる可能性があります。
• RDBフォーマットの問題と互換性のあるバージョン。データ量が非常に多い場合、親プロセスから子プロセスにRDBファイルに保存するのに時間がかかります。ディスクIOのパフォーマンスに応じて、ミリ秒または秒になる場合があります。データセットが比較的大きい場合、fork（）非常に時間がかかり、サーバーが特定の時間内にクライアントの処理を停止する場合があります。データセットが非常に大きく、CPU時間が非常にタイトな場合、この停止時間は1秒以上になることもあります。AOFの書き換えにもfork（）が必要ですが、AOFの書き換えの実行間隔が長くても、データの耐久性が失われることはありません。

RDBファイルを手動でバックアップするためのスクリプトを練習する

[root@centos7 ~]#vim /apps/redis/etc/redis.conf
save ""
dbfilename dump_6379.rdb
dir "/data/redis"
appendonly no

[root@centos8 ~]#cat redis_backup_rdb.sh
#!/bin/bash
. /etc/init.d/functions
BACKUP=/backup/redis-rdb
DIR=/data/redis
FILE=dump_6379.rdb
PASS=123456
redis-cli -h 127.0.0.1 -a $PASS --no-auth-warning bgsave
result=`redis-cli -a 123456 --no-auth-warning info Persistence |grep
rdb_bgsave_in_progress| sed -rn 's/.*:([0-9]+).*/\1/p'`
until [ $result -eq 0 ] ;do
  sleep 1
  result=`redis-cli -a 123456 --no-auth-warning info Persistence |grep
rdb_bgsave_in_progress| sed -rn 's/.*:([0-9]+).*/\1/p'`
done
DATE=`date +%F_%H-%M-%S`
[ -e $BACKUP ] || { mkdir -p $BACKUP ; chown -R redis.redis $BACKUP; }
mv $DIR/$FILE $BACKUP/dump_6379-${DATE}.rdb
action "Backup redis RDB"
#执行
[root@centos8 ~]#bash redis_backup_rdb.sh
Background saving started
Backup redis RDB                      [ OK ]
[root@centos8 ~]#ll /backup/redis-rdb/ -h
total 143M
-rw-r--r-- 1 redis redis 143M Oct 21 11:08 dump_6379-2020-10-21_11-08-47.rdb

例：saveおよびbgsave67255の実行プロセスを観察します

#阻塞
#生成临时文件

例：自動保存

[root@centos7 ~]#vim /apps/redis/etc/redis.conf
save 60 3
#测试60s内修改3个key,验证是否生成RDB文件

AOFモード

AOFモードの作業モード（2枚の写真は誰もが理解するのに便利です）

1. すべての書き込みコマンドをaofバッファーに追加します
2. AOFバッファーは、対応するappendfsync構成に従ってハードディスクに同期されます
3. AOFファイルを定期的に書き換えます
4. Redisが再起動すると、データ回復のためにAOFファイルをロードできます

AOF：AppendOnylFile、操作の順序に従って、指定されたログファイルの最後に操作を追加します。AOFは
RDBのようなコピーオンライトメカニズムを使用します。AOFはデフォルトで1秒に1回fsyncに設定され、実行されたコマンドはredisであってもAOFファイルに保存されます。サーバーに障害が発生した場合、1秒以内のデータのみが失われます。常に異なるfsync戦略を設定することもできます。つまり、コマンドが実行されるたびにfsyncを実行するように設定すると、fsyncはバックグラウンドでスレッドを実行するため、メインスレッドはユーザーの処理を続行できます。 AOFファイルに書き込まれたI / Oの影響を受けない通常の要求
。RDBとAOFの両方が有効になります。リカバリ時には、デフォルトのAOFファイルの優先度がRDBファイルよりも高くなります。つまり、AOFファイルがリカバリに使用されます。
注!!!：AOFモードのデフォルトは閉じた状態で、初めてAOFを開き、サービスを再起動して有効にした後、AOFの優先度はRDBの優先度よりも高く、AOFにはデフォルトでファイルがないため、すべてのデータが失われます。

AOFの書き換え

• 重複し、マージ可能で、期限切れのデータを新しいAOFファイルに書き換えることで、AOFバックアップが占めるハードディスク領域を節約し、リカバリプロセスを高速化します。
• bgrewriteaofを手動で実行してAOFをトリガーするか、自動書き換え戦略を定義できます
  

注!!!：AOFモードはデフォルトでオフになっています。AOFを初めてオンにしてサービスを再開すると、AOFの優先度はRDBの優先度よりも高くなり、AOFにはデフォルトでファイルがないため、すべてのデータが失われます。

[root@centos8 ~]#ll /var/lib/redis/
total 314392
-rw-r--r-- 1 redis redis 187779391 Oct 17 14:23 dump.rdb
[root@centos8 ~]#redis-cli
127.0.0.1:6379> config get appendonly
1) "appendonly"
2) "no"
127.0.0.1:6379> config set appendonly  yes
OK
[root@centos8 ~]#ll /var/lib/redis/
total 314392
-rw-r--r-- 1 redis redis 187779391 Oct 17 14:23 dump.rdb
-rw-r--r-- 1 redis redis  85196805 Oct 17 14:45 temp-rewriteaof-2146.aof
[root@centos8 ~]#ll /var/lib/redis/
total 366760
-rw-r--r-- 1 redis redis 187779391 Oct 17 14:45 appendonly.aof
-rw-r--r-- 1 redis redis 187779391 Oct 17 14:23 dump.rdb
[root@centos8 ~]#vim /etc/redis.conf
appendonly yes #改为yes
#config set appendonly yes 可以同时看到下面显示

AOF関連の構成

appendonly yes              #是否开启AOF日志记录，默认redis使用的是rdb方式持久化，这种方式在许多应用中已经足够用了，但是redis如果中途宕机，会导致可能有几分钟的数据丢失(取决于dump数据的间隔时间)，根据save来策略进行持久化，Append Only File是另一种持久化方式，可以提供更好的持久化特性，Redis会把每次写入的数据在接收后都写入 appendonly.aof 文件，每次启动时Redis都会先把这个文件的数据读入内存里，先忽略RDB文件。默认不启用此功能
appendfilename "appendonly-${port}.aof"          #文本文件AOF的文件名，存放在dir指令指定的目录中
appendfsync everysec    #aof持久化策略的配置
#no表示由操作系统保证数据同步到磁盘,Linux的默认fsync策略是30秒，最多会丢失30s的数据
#always表示每次写入都执行fsync，以保证数据同步到磁盘,安全性高,性能较差
#everysec表示每秒执行一次fsync，可能会导致丢失这1s数据,此为默认值,也生产建议值
dir /path               #快照文件保存路径，示例：dir "/apps/redis/data"

no-appendfsync-on-rewrite yes     #在aof rewrite期间,是否对aof新记录的append暂缓使用文件同步策略,主要考虑磁盘IO开支和请求阻塞时间。
#默认为no,表示"不暂缓",新的aof记录仍然会被立即同步到磁盘，是最安全的方式，不会丢失数据，但是要忍受阻塞的问题
#为yes,相当于将appendfsync设置为no，这说明并没有执行磁盘操作，只是写入了缓冲区，因此这样并不会造成阻塞（因为没有竞争磁盘），但是如果这个时候redis挂掉，就会丢失数据。丢失多少数据呢？Linux的默认fsync策略是30秒，最多会丢失30s的数据,但由于yes性能较好而且会避免出现阻塞因此比较推荐
#rewrite 即对aof文件进行整理,将空闲空间回收,从而可以减少恢复数据时间
auto-aof-rewrite-percentage 100             #当Aof log增长超过指定百分比例时，重写AOF文件，设置为0表示不自动重写Aof日志，重写是为了使aof体积保持最小，但是还可以确保保存最完整的数据
auto-aof-rewrite-min-size 64mb              #触发aof rewrite的最小文件大小
aof-load-truncated yes                      #是否加载由于某些原因导致的末尾异常的AOF文件(主进程被kill/断电等)，建议yes
aof-use-rdb-preamble no #redis4.0新增RDB-AOF混合持久化格式，在开启了这个功能之后，AOF重写产生的文件将同时包含RDB格式的内容和AOF格式的内容，其中RDB格式的内容用于记录已有的数据，而AOF格式的内容则用于记录最近发生了变化的数据，这样Redis就可以同时兼有RDB持久化和AOF持久化的优点（既能够快速地生成重写文件，也能够在出现问题时，快速地载入数据）,默认为no,即不启用此功能

例：構成を動的に変更し、appendonly.aofファイルを自動的に生成します

127.0.0.1:6379> CONFIG set appendonly yes

AOFを手動で実行して、BGREWRITEAOFコマンドを書き換えます

• BGREWRITEAOF
  時間の複雑さ：O（N）、NはAOFファイルに追加されるデータの数です。
  AOFファイルの書き換え操作を実行します。書き換えると、現在のAOFファイルの最適化されたバージョンが作成されます。
• BGREWRITEAOFが失敗しても、BGREWRITEAOFが成功する前に古いAOFファイルが変更されないため、データが失われることはありません。
• 書き換え操作は、他の永続化作業がバックグラウンドで実行されていない場合にのみトリガーされます。
  つまり、Redisの子プロセスがスナップショット保存作業を実行している場合、AOF書き換え操作がスケジュール（スケジュール）され、作業が保存されるまで待機します。完了後にAOF書き換えを実行します。この場合、BGREWRITEAOFの戻り値は引き続きOKですが、保存操作が完了するまでBGREWRITEAOFを実行できないことを示すメッセージが追加されます。Redis 2.6以降では、INFO [section]コマンドを使用して、BGREWRITEAOFが予約されているかどうかを確認できます。
• 他のAOFファイルの書き換えがすでに実行されている場合、BGREWRITEAOFはエラーを返し、この新しい
  BGREWRITEAOF要求は次の実行のためにスケジュールされません。
• Redis 2.4以降、AOFの書き換えはRedis自体によってトリガーされ、BGREWRITEAOFは手動で書き換え操作をトリガーするためにのみ使用されます。

例：手動bgrewriteaof

127.0.0.1:6379> BGREWRITEAOF
Background append only file rewriting started

#同时可以观察到下面显示

AOFモードの長所と短所

AOFモードの利点

• データセキュリティは比較的高いです。使用されているfsync戦略（fsyncはメモリ内のredisの変更されたすべてのファイルをストレージデバイスに同期することです）によると、デフォルトはappendfsync everysecです。つまり、fsyncは1秒に1回実行されます。この構成では、Redisは引き続き良好なパフォーマンスを維持でき、障害が発生した場合でも、1秒のデータのみが失われます（fsyncはバックグラウンドスレッドで実行されるため、メインスレッドはコマンド要求の処理に引き続き懸命に取り組むことができます）
• このメカニズムはログファイルの書き込み操作に追加モードを使用するため、書き込みプロセス中にシークする必要はなく、ダウンタイムが発生しても、ログファイルの既存のコンテンツが破壊されることはありません。ただし、この操作でデータの半分しか書き込まれず、システムがクラッシュした場合でも、心配しないでください。次回Redisを開始する前に、redis-check-aofツールを使用してデータの整合性の問題を解決できます。
• Redisは、AOFファイルのボリュームが大きくなりすぎると、バックグラウンドでAOFを自動的に書き換えることができます。書き換えられた新しいAOFファイルには、現在のデータセットを復元するために必要な最小限のコマンドセットが含まれています。Redisは新しいAOFファイルを作成中であるため、再書き込み操作全体は絶対に安全です。追加モードでは、変更されたデータが既存のAOFファイルに継続的に追加されます。再書き込みプロセスが停止しても、既存のAOFファイルはそのままです。失われることはありません。新しいAOFファイルが作成されると、Redisは古いAOFファイルから新しいAOFファイルに切り替えて、新しいAOFファイルの追加を開始します。
• AOFには、すべての変更操作を記録するための、明確にフォーマットされた、理解しやすいログファイルが含まれています。実際、このファイルを使用してデータを再構築することもできます。AOFファイルには、データベースで実行されたすべての書き込み操作が整然と格納されます。これらの書き込み操作はRedisプロトコルの形式で保存されるため、AOFファイルの内容は非常に読みやすくなっています。 、ファイルの解析も非常に簡単です。AOFファイルのエクスポートも非常に簡単です。
• たとえば、誤ってFLUSHALL。コマンドを実行したが、AOFファイルが書き換えられない限り、サーバーを停止し、AOFファイルの最後にあるFLUSHALコマンドを削除して、Redisを再起動すると、データセットを
  FLUSHALLに復元できます。以前の状態。

AOFモードのデメリット

• 一部の操作を繰り返しても、すべて記録されます。AOFのファイルサイズはRDB形式のファイルサイズよりも大きくなります。
• 大きなデータセットを回復する場合、AOFはRDBよりも低速です
• fsync戦略によっては、AOFはRDBよりも遅い場合があります
• バグの可能性が増える

RDBとAOFの選択

• 主にキャッシング機能として使用される場合、または数分のデータの損失に耐えることができる場合、通常、実稼働環境では通常、デフォルト値でもあるRDBを有効にするだけで済みます。
• データを永続的に保存する必要があり、まったく失われない場合は、RDBとAOFを同時にオンにすることを選択できます。通常、AOFのみをオンにすることはお勧めしません。