Redis には、RDB (Redis Database) と AOF (Append Only File) という 2 つの永続化ソリューションがあります。 RDB と AOF をすぐに理解して使用したい場合は、記事の一番下に直接ジャンプして概要を読むことができます。この章では、構成ファイル、スナップショットをトリガーする方法、データ回復操作、コマンド操作のデモンストレーション、利点と欠点を使用して、Redis の重要な知識の永続性を学びます。この記事では主に、Redis、RDB、AOF の 2 つの永続化ソリューションの詳細な分析を提供します。私たちがまとめたコンテンツが、これら 2 つのソリューションについての理解を深めるのに役立つことを願っています。
RDBの詳細説明
RDBはRedisのデフォルトの永続化ソリューションです。指定された時間間隔内に、指定された回数の書き込み操作が実行されると、メモリ内のデータがディスクに書き込まれます。つまり、指定したディレクトリに dump.rdb ファイルが生成されます。 Redis を再起動すると、dump.rdb ファイルがロードされてデータが復元されます。
設定ファイルからRDBについて学ぶ
redis.confファイルを開き、SNAPSHOTTINGの対応する内容を見つけます
1 RDBコアルール設定(キー)
save <seconds> <changes> # save "" save 900 1 save 300 10 save 60 10000
説明: 保存<時間間隔を指定> ＜指定回数の更新処理を実行＞の条件を満たすと、メモリ内のデータがハードディスクに同期されます。デフォルトの公式工場設定では、900 秒以内に 1 件の変更、300 秒以内に 10 件の変更、60 秒以内に 10,000 件の変更があった場合、メモリ内のデータ スナップショットがディスクに書き込まれます。
RDB ソリューションを使用したくない場合は、保存「」コメント、次の 3 つのコメントを開くことができます。
2 ローカル データベース ファイル名を指定します。通常はデフォルトの dump.rdb
dbfilename dump.rdb
を使用します。
3 ローカル データベース ストレージ ディレクトリを指定します。通常はデフォルト設定を使用します。
dir ./
4 データ圧縮をオンにするデフォルトでは
rdbcompression yes
説明: ローカルデータベースにデータを保存するときにデータを圧縮するかどうかを構成します。デフォルトは「はい」です。 Redis は LZF 圧縮を使用しますが、CPU 時間を少し消費します。このオプションをオフにすると、データベース ファイルが巨大になります。オンにすることをお勧めします。
RDBスナップショットをトリガー
1 指定された時間間隔内に指定された回数の書き込み操作を実行します
2 保存(ブロック、スナップショットを保存するだけ、他を待つ)またはbgsave(非同期)コマンドを実行します
3データベース内のすべてのデータをクリアするには、flushall コマンドを実行します。これはあまり意味がありません。
4 shutdown コマンドを実行して、サーバーがデータを失うことなく正常にシャットダウンされることを確認しますが、これにはあまり意味はありません。
RDB ファイルを介してデータを復元する
dump.rdb ファイルを Redis インストール ディレクトリの bin ディレクトリにコピーし、Redis サービスを再起動します。実際の開発では、通常、物理マシンのハードディスクの破損を考慮し、バックアップ dump.rdb を選択します。以下の操作デモで体験できます。
RDBの長所と短所
長所:
1 大規模なデータ復旧に適しています。
2 ビジネスにデータの整合性と一貫性に対する高度な要件がない場合は、RDB が良い選択です。
短所:
1 前回のバックアップ中に RDB がダウンした可能性があるため、データの整合性と一貫性は高くありません。
2 Redis はバックアップ中に独自にサブプロセスを作成し、データを一時ファイルに書き込み (この時点でメモリ内のデータは元のサイズの 2 倍です)、最後に一時ファイルを置き換えるため、バックアップ中にメモリが占有されます。ファイルの以前のバックアップ ファイル。
したがって、Redis の永続化とデータの回復は真夜中に実行する方が合理的です。
操作デモ
[root@itdragon bin]# vim redis.conf save 900 1 save 120 5 save 60 10000 [root@itdragon bin]# ./redis-server redis.conf [root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379 127.0.0.1:6379> keys * (empty list or set) 127.0.0.1:6379> set key1 value1 OK 127.0.0.1:6379> set key2 value2 OK 127.0.0.1:6379> set key3 value3 OK 127.0.0.1:6379> set key4 value4 OK 127.0.0.1:6379> set key5 value5 OK 127.0.0.1:6379> set key6 value6 OK 127.0.0.1:6379> SHUTDOWN not connected> QUIT [root@itdragon bin]# cp dump.rdb dump_bk.rdb [root@itdragon bin]# ./redis-server redis.conf [root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379 127.0.0.1:6379> FLUSHALL OK 127.0.0.1:6379> keys * (empty list or set) 127.0.0.1:6379> SHUTDOWN not connected> QUIT [root@itdragon bin]# cp dump_bk.rdb dump.rdb cp: overwrite `dump.rdb'? y [root@itdragon bin]# ./redis-server redis.conf [root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379 127.0.0.1:6379> keys * 1) "key5" 2) "key1" 3) "key3" 4) "key4" 5) "key6" 6) "key2"
ステップ 1: vim で永続化設定時間を変更する 120 秒以内に 5 回変更されると、1 回永続化されます。
ステップ 2: サービスを再起動して、構成を有効にします。
ステップ 3: 5 つのキーをそれぞれ設定します。2 分後、bin の現在のディレクトリに dump.rdb ファイルが自動的に生成されます。 (set key6 は、シャットダウンが RDB スナップショットをトリガーできることを確認するためのものです)
ステップ 4: 現在の dump.rdb のバックアップ コピーを作成します (オンライン作業をシミュレートします)。
ステップ 5: FLUSHALL コマンドを実行してデータベース データをクリアします (データ損失をシミュレートします)。
ステップ 6: Redis サービスを再起動し、データを復元します...え? ? ? ? (´◔ ‸◔`)。データは空ですか? ? ? ? FLUSHALLにはRDBスナップショットをトリガーする機能も備わっているためです。
ステップ 7: バックアップ dump_bk.rdb を dump.rdb に置き換え、次に redis に置き換えます。
注: SHUTDOWN および FLUSHALL コマンドは RDB スナップショットをトリガーします。これは落とし穴であることに注意してください。
その他のコマンド:
keys * データベース保存内のすべてのキーを照合します データをバックアップするための RDB スナップショットをブロックします FLUSHALL Redis サーバー全体のデータをクリアします (ほとんど使用されません) SHUTDOWN シャットダウンして終了します (ほとんど使用されません)
AOF詳細な説明
AOF: Redis はデフォルトでは有効になっていません。 RDB の欠点 (データの不整合) を補うように見えるため、ログの形式を使用して各書き込み操作を記録し、ファイルに追加します。 Redis が再起動されると、ログ ファイルの内容に基づいて書き込み命令が前から後ろに実行され、データの回復作業が完了します。
設定ファイルから AOF について学びましょう
redis.conf ファイルを開き、APPEND ONLY MODE の対応する内容を見つけます
1 つの redis はデフォルトで閉じられています
2 指定本地数据库文件名，默认值为 appendonly.aof
appendfilename "appendonly.aof"
3 指定更新日志条件
# appendfsync always appendfsync everysec # appendfsync no
解说：
always：同步持久化，每次发生数据变化会立刻写入到磁盘中。性能较差当数据完整性比较好（慢，安全）
everysec：出厂默认推荐，每秒异步记录一次（默认值）
no：不同步
4 配置重写触发机制
auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb
解说：当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。一般都设置为3G，64M太小了。
触发AOF快照
根据配置文件触发，可以是每次执行触发，可以是每秒触发，可以不同步。
根据AOF文件恢复数据
正常情况下，将appendonly.aof 文件拷贝到redis的安装目录的bin目录下，重启redis服务即可。但在实际开发中，可能因为某些原因导致appendonly.aof 文件格式异常，从而导致数据还原失败，可以通过命令redis-check-aof --fix appendonly.aof 进行修复 。从下面的操作演示中体会。
AOF的重写机制
前面也说到了，AOF的工作原理是将写操作追加到文件中，文件的冗余内容会越来越多。所以聪明的 Redis 新增了重写机制。当AOF文件的大小超过所设定的阈值时，Redis就会对AOF文件的内容压缩。
重写的原理：Redis 会fork出一条新进程，读取内存中的数据，并重新写到一个临时文件中。并没有读取旧文件（你都那么大了，我还去读你？？？ o(ﾟДﾟ)っ傻啊！）。最后替换旧的aof文件。
触发机制：当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。这里的“一倍”和“64M” 可以通过配置文件修改。
AOF 的优缺点
优点：数据的完整性和一致性更高
缺点：因为AOF记录的内容多，文件会越来越大，数据恢复也会越来越慢。
操作演示
[root@itdragon bin]# vim appendonly.aof appendonly yes [root@itdragon bin]# ./redis-server redis.conf [root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379 127.0.0.1:6379> keys * (empty list or set) 127.0.0.1:6379> set keyAOf valueAof OK 127.0.0.1:6379> FLUSHALL OK 127.0.0.1:6379> SHUTDOWN not connected> QUIT [root@itdragon bin]# ./redis-server redis.conf [root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379 127.0.0.1:6379> keys * 1) "keyAOf" 127.0.0.1:6379> SHUTDOWN not connected> QUIT [root@itdragon bin]# vim appendonly.aof fjewofjwojfoewifjowejfwf [root@itdragon bin]# ./redis-server redis.conf [root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379 Could not connect to Redis at 127.0.0.1:6379: Connection refused not connected> QUIT [root@itdragon bin]# redis-check-aof --fix appendonly.aof 'x 3e: Expected prefix '*', got: ' AOF analyzed: size=92, ok_up_to=62, diff=30 This will shrink the AOF from 92 bytes, with 30 bytes, to 62 bytes Continue? [y/N]: y Successfully truncated AOF [root@itdragon bin]# ./redis-server redis.conf [root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379 127.0.0.1:6379> keys * 1) "keyAOf"
第一步：修改配置文件，开启AOF持久化配置。
第二步：重启Redis服务，并进入Redis 自带的客户端中。
第三步：保存值，然后模拟数据丢失，关闭Redis服务。
第四步：重启服务，发现数据恢复了。（额外提一点：有教程显示FLUSHALL 命令会被写入AOF文件中，导致数据恢复失败。我安装的是redis-4.0.2没有遇到这个问题）。
第五步：修改appendonly.aof，模拟文件异常情况。
第六步：重启 Redis 服务失败。这同时也说明了，RDB和AOF可以同时存在，且优先加载AOF文件。
第七步：校验appendonly.aof 文件。重启Redis 服务后正常。
补充点：aof 的校验是通过 redis-check-aof 文件，那么rdb 的校验是不是可以通过 redis-check-rdb 文件呢？？？
总结 Redis 默认开启RDB持久化方式，在指定的时间间隔内，执行指定次数的写操作，则将内存中的数据写入到磁盘中。 RDB 持久化适合大规模的数据恢复但它的数据一致性和完整性较差。 Redis 需要手动开启AOF持久化方式，默认是每秒将写操作日志追加到AOF文件中。
AOF 的数据完整性比RDB高，但记录内容多了，会影响数据恢复的效率。 Redis 针对 AOF文件大的问题，提供重写的瘦身机制。若只打算用Redis 做缓存，可以关闭持久化。若打算使用Redis 的持久化。建议RDB和AOF都开启。其实RDB更适合做数据的备份，留一后手。AOF出问题了，还有RDB。
相关推荐：
以上がRedis RDBとAOFの詳細説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
