Redisの2つの持続化スキームRDBとAOFの詳細

本文は主にRedisの2種類の持続化方案RDBとAOFに対して詳しい分析を行って、私達が整理した内容がみんなにこの2種類の方案に対して更に深い理解があることを助けることができることを望みます.
Redisには、RDB(Redis DataBase)とAOF(Append Only File)の2つの永続化スキームがある.RDBとAOFを迅速に理解し、使用したい場合は、文章の下部に直接ジャンプしてまとめを見ることができます.この章では、プロファイル、スナップショットをトリガーする方法、データを復元する操作、コマンド操作のプレゼンテーション、メリットとデメリットを通じて、Redisの重点知識の永続化を学びます.
RDB詳細
RDBはRedisのデフォルトの永続化スキームである.指定した間隔で、指定した回数の書き込みを行うと、メモリのデータがディスクに書き込まれます.すなわち、指定ディレクトリの下にdumpを生成する.rdbファイル.Redis再起動はdumpをロードする.rdbファイルはデータを復元します.
プロファイルからRDBについて
開くconfファイル、SNAPSHOTTING対応コンテンツ1 RDBコアルール構成を見つけます(ポイント)

save  
# save ""
save 900 1
save 300 10
save 60 10000

 
解説:saveは、条件を満たすとメモリのデータをハードディスクに同期します.デフォルトでは900秒以内に1つの変更があり、300秒以内に10つの変更があり、60秒以内に10000の変更がある場合は、メモリ内のデータスナップショットをディスクに書き込みます.
RDBスキームを使用したくない場合は、save""のコメントを開いて、次の3つのコメントを開くことができます.
2ローカルデータベースのファイル名を指定します.一般的にデフォルトのdumpを使用します.rdb

dbfilename dump.rdb

 
3ローカル・データベースの保存ディレクトリを指定します.一般的にはデフォルトの構成も使用します.
dir ./
4デフォルトオープンデータ圧縮

rdbcompression yes

 
説明:ローカル・データベースに格納するときにデータを圧縮するかどうかを設定します.デフォルトはyesです.RedisはLZF圧縮方式を採用しているが,CPUの時間が少しかかっている.このオプションをオフにすると、データベース・ファイルが大きくなります.開くことを推奨します.
RDBスナップショットのトリガー
1指定した時間間隔で、指定回数の書き込みを行う
2 save(ブロック、スナップショットの保存のみ、その他の待機)またはbgsave(非同期)コマンドの実行
3 flushallコマンドを実行して、データベースのすべてのデータを空にして、意味がありません.
4 shutdownコマンドを実行して、サーバーが正常に閉じて、データが失われないことを保証します.意味...大きくもないです.
RDBファイルによるデータ復旧
これを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"

 
第一歩:vimは持続化構成時間を修正し、120秒以内に5回修正すると1回持続化する.
ステップ2:サービスを再起動して構成を有効にします.
第3歩:それぞれ5つのkeyをセットし、2分後、binの現在のディレクトリの下でdumpを自動的に生産する.rdbファイル.(set key 6はshutdownがRDBスナップショットをトリガする役割を果たすことを検証するため)
ステップ4:現在のdump.rdbバックアップ1部(シミュレーションラインで動作).
ステップ5:FLUSHALLコマンドを実行してデータベースデータを空にします(アナログデータが失われました).
ステップ6:Redisサービスを再起動し、データを復元.....あれ???( ′◔ ‸◔`).データが空です???これはFLUSHALLにもRDBスナップショットをトリガする機能があるからです.
ステップ7:バックアップするdump_bk.rdb置換dump.rdbは次に再Redisする.
注意点:SHUTDOWNとFLUSHALLコマンドはRDBスナップショットをトリガーします.これはピットです.注意してください.
その他のコマンド:
keys*マッチングデータベース内のすべてのkey saveブロックはRDBスナップショットをトリガし、そのバックアップデータFLUSHALLにRedisサーバ全体のデータ(ほとんど使わない)SHUTDOWNシャットダウンをクリアさせる(少ない)
AOF詳細
AOF:Redisはデフォルトではオンになっていません.RDBの不足(データの不一致)を補うために、ログ形式で各書き込み操作を記録し、ファイルに追加します.Redisが再起動すると、ログ・ファイルの内容に応じて、データのリカバリを完了するために、書き込みコマンドが前後に1回実行されます.
構成ファイルからAOFについて
開くconfファイル、APPEND ONLY MODEの対応する内容を探し当てます1 redisはデフォルトで閉じて、開いて手動でnoをyesに変える必要があります

appendonly yes

 
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後のサイズの倍であり、ファイルが64 Mより大きい場合にトリガーされます.普通はすべて3 Gに設定して、64 Mは小さすぎます.
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後のサイズの倍であり、ファイルが64 Mより大きい場合にトリガされます.ここで「倍」と「64 M」はプロファイルで変更できます.
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"

ステップ1:コンフィギュレーションファイルを修正し、AOF永続化コンフィギュレーションをオンにします.
ステップ2:Redisサービスを再起動し、Redisが所有するクライアントにアクセスします.
ステップ3:値を保存し、データ損失をシミュレートしてRedisサービスを閉じます.
ステップ4:サービスを再起動し、データが回復したことを発見します.(ちなみに、FLUSHALLコマンドがAOFファイルに書き込まれ、データ復旧に失敗するチュートリアルがあります.私がインストールしたのはredis-4.0.2でこの問題に遭遇していません).
ステップ5:appendonlyを変更します.aof、ファイル異常をシミュレートします.
ステップ6:Redisサービスの再起動に失敗しました.これはまた、RDBとAOFが同時に存在し、AOFファイルを優先的にロードできることを示している.
ステップ7:appendonlyを検証します.aofファイル.Redisサービスを再起動したら正常です.
补充点:aofの検査はredis-check-aofファイルを通じて、rdbの検査はredis-check-rdbファイルを通じて(通って)ことができますか??
まとめRedisはデフォルトでRDB永続化方式をオンにし、指定した時間間隔で指定回数の書き込み操作を実行すると、メモリ内のデータをディスクに書き込む.RDB永続化は、大規模なデータ・リカバリに適していますが、データの一貫性と完全性が劣っています.Redisは、AOF永続化方式を手動でオンにする必要があり、デフォルトでは、書き込み操作ログをAOFファイルに1秒ごとに追加します.
AOFのデータ整合性はRDBより高いが,記録内容が多くなるとデータ復旧の効率に影響する.RedisはAOFファイルの大きな問題に対して、書き換えのダイエットメカニズムを提供しています.Redisのみでキャッシュする場合は、永続化をオフにできます.Redisの永続化を使うつもりなら.RDBもAOFもオンにすることをお勧めします.実はRDBはデータのバックアップに適していて、後手を残しています.AOFに問題が発生しました.RDBもあります.
ここまでRedisの永続化は紹介済みで、何か悪いところが指摘できます.