Redis持続化メカニズムとどのように持続化を実現するか

一.Redis持続化の概要
Redisの高性能は、すべてのデータがメモリに格納されているためであり、再起動後もデータが失われないようにするためには、メモリからハードディスクにデータを同期させる必要がある.このプロセスは永続化である.Redisは、RDB(Redis Database)方式とAOF(Append Only File)方式の2つの方式の永続化をサポートする方式.いずれかを単独で使用したり、両者を組み合わせて使用したりすることができる

RDB永続化(デフォルト)このメカニズムは、メモリ内のデータセットスナップショットを所定の時間間隔でディスク

に書き込むことを意味する.

AOF永続化このメカニズムは、サーバが処理する書き込み操作をログ形式で記録し、Redisサーバが起動したときにファイルを読み込んでデータベースを再構築し、起動後のデータベースのデータが完全な

であることを保証する.

非永続化Redisサーバの永続化機能を構成的に無効化することで、Redisを機能強化版のmemcachedと見なすことができます.

redisは、RDBおよびAOF

を同時に使用することができる
二.RDB持続化機構
1.RDB持続化機構の利点

この方法を採用すると、Redisデータベース全体に1つのファイルしか含まれません.これはファイルバックアップにとって完璧です.たとえば、最近24時間のデータを1時間に1回アーカイブすると同時に、30日近くのデータを毎日アーカイブする予定です.このようなバックアップポリシーにより、システムに障害が発生すると、リカバリを簡単に行うことができます.

ディザスタリカバリでは、RDBは非常に良い選択です.なぜなら、個別のファイルを圧縮して他のストレージメディアに転送することが非常に簡単であるためです.

性能最大化.Redisのサービスプロセスにとって、持続化を開始する時、唯一しなければならないのはfork出サブプロセスであり、その後サブプロセスによって持続化操作を完成させることで、サービスプロセスのIO操作を極めて避けることができる

AOFよりもデータセットが大きいとRDBの起動効率が高くなります
2.RDB持続化機構の欠点

データの高可用性を保証したい場合、すなわちデータが失われないことを最大限に保証したい場合、RDBは、システムがタイミング持続化する前にダウンタイムし、ディスクに書き込まれていないデータが

すべて失われるため、良い選択ではありません.

RDBはforkサブプロセスによってデータの永続化作業を支援するため、データセットが大きい場合、サーバ全体が数百ミリ秒、さらには1 sec

のサービスを停止する可能性がある.
3.RDB持続化メカニズム構成
redis.windows.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 at all commenting all the "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
save 300 10
save 60 10000

ここで、上記の構成は、RDB方式のデータ永続化タイミングである.
キーワード
時間(Sec)
keyモディファイア
説明する
save
900
1
900秒(15分)ごとに少なくとも1つのキーが変化するとdumpメモリスナップショット
save
300
10
300秒(5分)ごとに少なくとも10 keyが変化するとdumpメモリスナップショット
save
60
10000
60秒(1分)ごとに少なくとも10000キーが変化するとdumpメモリスナップショット
三.AOF持続化メカニズム
1.AOF持続化機構の利点

このメカニズムは、より高いデータセキュリティ、すなわちデータ持続性をもたらすことができる.Redisでは、3つの同期ポリシー、すなわち、毎秒同期、各修正同期、および非同期が提供されている.実際には、毎秒同期も非同期で完了し、その効率も非常に高く、システムにダウンタイムが発生すると、この1秒以内に修正されたデータは失われる.同期永続化と見なすことができ、データの変化が発生するたびに直ちにディスクに記録される.この方法は効率的に最も低いことが予想される.同期がないことについては、言うまでもなく、

を理解することができる.

ログファイルの書き込み操作はappendモードを採用しているため、書き込み中にダウンタイムが発生しても、ログファイルにすでに存在する内容を破壊することはない.しかし、今回の操作でデータの半分だけを書き込むとシステムがクラッシュする問題が発生し、Redisの次の起動前に、データ整合性の問題を解決するためにredis-check-aofツールを使用することができます

ログが大きすぎる場合、Redisは自動的にrewriteメカニズムを有効にすることができる.すなわち、Redisはappendモードで変更データを古いディスクファイルに絶えず書き込むとともに、Redisはこの期間中にどのような変更コマンドが実行されたかを記録するための新しいファイルを作成するので、rewrite切替を行う際にデータの安全性をよりよく保証することができる

AOFには、すべての変更操作を記録するためのフォーマットが明確で分かりやすいログファイルが含まれています.実際には、このファイルを通じてデータの再構築

を完了することもできます.
2.AOF持続化メカニズムの欠点

同じ数のデータセットの場合、AOFファイルは通常RDBファイル

よりも大きい.

同期ポリシーによっては、AOFの実行効率がRDBよりも遅くなることが多い.要するに、1秒あたりの同期ポリシーの効率は比較的高く、同期無効化ポリシーの効率はRDBと同様に

効率的である.
3.AOF持続化メカニズム構成

AOF持続化

をオン

############################## APPEND ONLY MODE ###############################
# By default Redis asynchronously dumps the dataset on disk. This mode is
# good enough in many applications, but an issue with the Redis process or
# a power outage may result into a few minutes of writes lost (depending on
# the configured save points)
# #
The Append Only File is an alternative persistence mode that provides
# much better durability. For instance using the default data fsync policy
# (see later in the config file) Redis can lose just one second of writes in a
# dramatic event like a server power outage, or a single write if something
# wrong with the Redis process itself happens, but the operating system is
# still running correctly.
# #
AOF and RDB persistence can be enabled at the same time without problems.
# If the AOF is enabled on startup Redis will load the AOF, that is the file
# with the better durability guarantees.
# #
Please check http://redis.io/topics/persistence for more information.
appendonly no

appendonlyをyesに変更し、aof永続化メカニズムをオンにします.デフォルトでは、ディレクトリの下にappendonly.aofファイルが生成されます.

AOF持続化タイミング

# appendfsync always
appendfsync everysec
# appendfsync no

上記の構成はaof持続化のタイミングであり、以下のように解釈される.
キーワード
永続化のタイミング
説明する
appendfsync
always
更新コマンドを実行するたびに、永続化
appendfsync
everysec
1秒ごとに永続化
appendfsync
no
オペレーティングシステムのアイドルコールに依存して、永続化はアクティブに実行されません.
四.二つの持続化方式の対比
コマンド#コマンド#
RDB
AOF
起動の優先度
低い
高い
たいせき
小さい
大きい
リカバリ速度
速い
遅い
データセキュリティ
データを失う
策略によって決める
重さ
重い
軽い