Redis 永続性スナップショットの方法と原則

いわゆる永続性とは、データが失われないようにすることであり、通常、データはハードディスクに保存されます。 Redis にはスナップショット永続化と AOF 永続化の 2 つの永続化方式があり、それぞれに長所と短所があり、プロジェクトでは実際の状況に応じて具体的な永続化方式を選択する必要があります。

推奨: redis 入門チュートリアル

スナップショット永続化 (RDB)

RDB 永続化メソッドとも呼ばれます。永続化は、スナップショットを取得し、特定の時点でのメモリ データを rdb ファイルに保存し、redis サービスの再起動時にファイルにデータをロードすることによって実現されます。

永続的スナップショットの構成

redis でのスナップショットの永続化はデフォルトで有効になっており、redis.conf 構成ファイルに関連する構成オプションがあります

################################ SNAPSHOTTING  ################################
#
# Save the DB on disk:
#
#   save <seconds> <changes>
#
#   Will save the DB if both the given number of seconds and the given
#   number of write operations against the DB occurred.
#
#   In the example below the behaviour will be to save:
#   after 900 sec (15 min) if at least 1 key changed
#   after 300 sec (5 min) if at least 10 keys changed
#   after 60 sec if at least 10000 keys changed
#
#   Note: you can disable saving completely by commenting out all "save" lines.
#
#   It is also possible to remove all the previously configured save
#   points by adding a save directive with a single empty string argument
#   like in the following example:
#
#   save ""

save 900 1   #900秒内至少有1个key被更改就执行快照
save 300 10  #300内描述至少有10个key被更改就执行快照
save 60 10000  #60秒内至少有10000个key被更改就执行快照

# By default Redis will stop accepting writes if RDB snapshots are enabled
# (at least one save point) and the latest background save failed.
# This will make the user aware (in a hard way) that data is not persisting
# on disk properly, otherwise chances are that no one will notice and some
# disaster will happen.
#
# If the background saving process will start working again Redis will
# automatically allow writes again.
#
# However if you have setup your proper monitoring of the Redis server
# and persistence, you may want to disable this feature so that Redis will
# continue to work as usual even if there are problems with disk,
# permissions, and so forth.
stop-writes-on-bgsave-error yes #拍摄快照失败是否继续执行写命令

# Compress string objects using LZF when dump .rdb databases?
# For default that&#39;s set to &#39;yes&#39; as it&#39;s almost always a win.
# If you want to save some CPU in the saving child set it to &#39;no&#39; but
# the dataset will likely be bigger if you have compressible values or keys.
rdbcompression yes #是否对快照文件进行压缩

# Since version 5 of RDB a CRC64 checksum is placed at the end of the file.
# This makes the format more resistant to corruption but there is a performance
# hit to pay (around 10%) when saving and loading RDB files, so you can disable it
# for maximum performances.
#
# RDB files created with checksum disabled have a checksum of zero that will
# tell the loading code to skip the check.
rdbchecksum yes #是否进行数据校验

# The filename where to dump the DB
dbfilename dump.rdb #快照文件存储的名称
# The working directory.
#
# The DB will be written inside this directory, with the filename specified
# above using the &#39;dbfilename&#39; configuration directive.
#
# The Append Only File will also be created inside this directory.
#
# Note that you must specify a directory here, not a file name.
dir /opt/redis-5.0.3#快照文件存储的位置

効果を確認します

1. インストール ディレクトリを入力し、dump.db ファイルがある場合は削除します。

2. redis を起動し、いくつかのデータを追加し、redis を閉じて終了します。

[root@root redis-5.0.3]# src/redis-cli 
127.0.0.1:6379> ping
PONG
127.0.0.1:6379> set name aaa
OK
127.0.0.1:6379> set age 18
OK
127.0.0.1:6379> incr age
(integer) 19
127.0.0.1:6379> shutdown
not connected> exit

3. インストール ディレクトリに dump.rdb ファイルを生成します。これがスナップショット バックアップ ファイルです。

4. Redis を再度起動し、元のファイルを検出するために入力します。 Redis は起動時にバックアップ ファイルにデータをロードするため、データはまだ存在します。

[root@root redis-5.0.3]# src/redis-server redis.conf 
1211:C 13 Feb 2019 01:27:22.668 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
1211:C 13 Feb 2019 01:27:22.668 # Redis version=5.0.3, bits=64, commit=00000000, modified=0, pid=1211, just started
1211:C 13 Feb 2019 01:27:22.668 # Configuration loaded
[root@root redis-5.0.3]# src/redis-cli 
127.0.0.1:6379> ping 
PONG
127.0.0.1:6379> get name
"aaa"
127.0.0.1:6379> get age
"19"
127.0.0.1:6379> keys *
1) "name"
2) "age"

5.閉じて終了

閉じて終了後、dump.rdbファイルを削除してください。起動後、データが消えていることがわかります

[root@root redis-5.0.3]# src/redis-server redis.conf 
1218:C 13 Feb 2019 01:29:01.336 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
1218:C 13 Feb 2019 01:29:01.336 # Redis version=5.0.3, bits=64, commit=00000000, modified=0, pid=1218, just started
1218:C 13 Feb 2019 01:29:01.336 # Configuration loaded
[root@root redis-5.0.3]# src/redis-cli 
127.0.0.1:6379> ping 
PONG
127.0.0.1:6379> keys *
(empty list or set)

スナップショット永続性の原則

save コマンド:

redis の実行中に、明示的に保存コマンドを送信してスナップショットを取得できます。保存コマンドはブロック コマンドです。つまり、サーバーが保存コマンドを受信すると、スナップショットの作成が開始されます。この期間中、他のリクエストは処理されません。バックアップが完了するまで、他のリクエストは一時停止されます

bgsave コマンド

bgsave コマンドもすぐにスナップショットを取得します。save コマンドとは異なり、bgsave はブロック コマンドではなく、フォーク サブスレッドです。このサブスレッドはバックアップ操作を担当します。親プロセスはクライアントのリクエストの処理を続行するため、ブロックが発生することはありません。

127.0.0.1:6379> ping
PONG
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> set name zhangsan
OK
127.0.0.1:6379> set age 20
OK
127.0.0.1:6379> bgsave
Background saving started

4. シャットダウンコマンド

コマンドをシャットダウンしたいだけの場合。サーバーは自動的に保存コマンドを送信して、スナップショット操作を完了します。バックアップ操作が完了したら、サーバーをシャットダウンします。したがって、操作が前の 3 つの条件を満たさない場合、サーバーをシャットダウンした後、再度サーバーを開いたときにデータが失われることはありません。

5. sync コマンド

マスター/スレーブ環境では、スレーブ ノードはマスター ノードのデータを同期したいときに、レプリケーションを開発するために sync コマンドを送信します。このとき、マスター ノードは bgsave コマンドを送信して新しいスレッドをフォークしてスナップショットを完了し、bgsave コマンド操作が完了した後にスナップショット ファイルをスレーブ ノードに送信してマスター ノードとスレーブ ノードのデータ同期を完了します。

利点と欠点

利点

RDB ファイルは、特定の時点の Redis データを保存するため、バックアップに適しています。 RDB ファイルはアーカイブされるので、必要なときにデータを別のバージョンに簡単に復元できます。 RDB は災害復旧に非常に適しています。単一のファイルをリモート サーバーに簡単に転送できます。データ量が比較的多い場合、RDB の起動が早い

デメリット

RDB はデータ損失を起こしやすい 3 分ごとに保存するように設定している場合、redis が適切に動作しない場合何らかの理由で、最後のスナップショットと Redis の問題の間のデータが失われます。

スナップショットの永続性を無効にする方法

1. redis.conf 構成ファイル内のすべての保存構成をコメント アウトします。2. 最後の保存構成に Eat コマンドを追加します

save ""

AOF 永続性

Redis のキーと値のペアのデータを直接保存するスナップショット永続性とは異なり、AOF 永続性は Redis によって実行された書き込みコマンドを保存することで Redis のメモリ データを記録します。理論的には、Redis メモリ データを変更する可能性のあるすべてのコマンド (つまり、書き込みコマンド) を保存している限り、これらの保存された書き込みコマンドに基づいて、Redis のメモリ状態を復元できます。 AOF 永続化は、この原則を使用してデータ永続化とデータ回復を実現します。

AOF を開く

redis では、aof はデフォルトで閉じられているため、構成ファイルを変更して aof を有効にする必要があります

appendonly yes
appendfilename "appendonly.aof"
# If unsure, use "everysec".
# appendfsync always
appendfsync everysec
# appendfsync no
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

スナップショットの永続性をオフにする

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

サービスを確認して再起動する

単純なコマンド操作を実行すると、append.aof ファイルに保存されている内容が実行したコマンドであることがわかります

AOF 永続バックアップに関する注意事項

1.appendfsync には、everysec、always、no という 3 つの値があります。ここでは、everysec を使用することをお勧めします。推奨されません。常にサーバーのパフォーマンスに重大な影響を与えるため 2. 最悪の場合でも、毎秒のデータ損失は 1 秒のみであり、影響は制御可能な範囲内です。

利点と欠点

利点

AOF 永続化メソッドは、さまざまな同期頻度を提供します。デフォルトの同期頻度を使用して 1 秒に 1 回同期する場合でも、Redis は失われるのはせいぜい 1 秒のデータだけです。 AOF ファイルの形式は可読性が高いため、ユーザーはより柔軟な処理方法を利用できます。たとえば、誤って FLUSHALL コマンドを使用した場合、再書き込みが進行する前に、最後の FLUSHALL コマンドを手動で削除し、AOF を使用してデータを回復できます。

欠点

AOF はさまざまな同期頻度を提供しますが、デフォルトでは、1 秒に 1 回の同期頻度でもパフォーマンスが高くなります。ただし、Redis の負荷が高い場合、RDB は AOF よりも優れたパフォーマンス保証を備えています。 RDB はスナップショットを使用して Redis データ全体を永続化しますが、AOF は実行された各コマンドを AOF ファイルに追加するだけなので、理論上は RDB の方が AOF 方式よりも堅牢です

永続化いくつかの使用上の提案

1. Redis をキャッシュ サーバーとしてのみ使用する場合、永続性を使用することはできません。

2. 通常の状況では、両方の永続化メソッドを有効にします。 redis は、データを応答するために最初に AOF ファイルをロードします。 RDB の利点は高速であることです。

3. マスター/スレーブ ノードでは、RDB はバックアップ データとして機能し、スレーブ (スレーブ ノード) でのみ開始されます。同期時間は、このルールのみ (900 1 を保存) を残して、より長く設定できます。 。 それでおしまい。

関連する推奨事項:

mysql ビデオ チュートリアル: https://www.php.cn/course/list/51.html

以上がRedis 永続性スナップショットの方法と原則の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。