Redis高可用性の「永続化」
2782 ワード
Redis高可用性の概要
Redisでは、高可用性を実現する技術として、主に持続化、複製(読み書き分離)、哨兵、クラスタが挙げられる.永続化:永続化は最も簡単な高可用性方法(高可用性手段として分類されない場合もある)であり、主な役割はデータバックアップであり、データをハードディスクに格納し、プロセスの終了によってデータが失われないことを保証する. レプリケーション:レプリケーションは高可用性Redisの基礎であり、哨兵とクラスタはレプリケーションに基づいて高可用性を実現している.レプリケーションは、主にデータのマルチマシンバックアップと、読み取り操作の負荷分散と簡単なフェイルオーバを実現します.欠陥:障害復旧は自動化できず、書き込み操作は負荷のバランスが取れず、ストレージ能力は単機の制限を受けている. 哨兵:複製に基づいて、哨兵は自動化された故障回復を実現した.欠陥:書き込み操作で負荷が均衡できない;ストレージ能力はスタンドアロンの制限を受けます. クラスター:クラスターを通して、Redisは操作が負荷のバランスが取れないことと、ストレージ能力が単機の制限を受ける問題を解決して、比較的に完備した高利用可能な解決方案を実現した.
Redis永続化の概要
永続化機能:Redisはメモリ・データベースであり、データはすべてメモリに格納されます.
Redisの永続化はRDBとAOFの永続化に分けられる.の前者は、データをハードディスク(HDD)に保存することです. 後者は、実行される書き込みコマンドをハードディスクに保存する.
RDB持続化
RDB永続化は、現在のプロセスにおけるデータ生成スナップショットをハードディスク(したがって、スナップショット永続化とも呼ばれる)に保存し、保存されたファイル接尾辞はRDBである.
Redisが再起動されると、スナップショットファイルのリカバリデータを読み込むことができます.
トリガ条件:手動トリガ 自動トリガ 手動トリガ:saveコマンドとbgsaveコマンドの両方でRDBファイルを生成できます.
saveコマンドは、RDBファイルの作成が完了するまでRedisサービスプロセスをブロックし、Redisサーバがブロックされている間、サーバはコマンド要求を実行できません.
bgsaveコマンドは、サブプロセスを作成し、サブプロセスによってRDBファイルを作成し、親プロセス(つまりRedisメインプロセス)がリクエストの処理を続行します.bgsaveコマンドの実行中、fork(orkがプロセスである場合、サブプロセスのredis接続は使用できません.再接続する必要があります)のみがサーバをブロックし、saveコマンドでは、プロセス全体がサーバをブロックします.
RDB永続化が自動的にトリガされると、Redisはsaveではなくbgsaveを使用して永続化する.以下、自動トリガRDB持続化条件について説明する.
自動トリガ:最も一般的な場合は、プロファイルでsave mnを介して、m秒内にn回の変化が発生した場合にbgsaveがトリガされます.
RedisプロファイルRedis.confでは、次の構成情報が表示されます.
save m n以外にもbgsaveがトリガーされる場合があります.マスタコピーシーンでは、ノードからフルコピー操作が実行されると、マスタノードはbgsaveコマンドを実行し、RDBファイルをスレーブノードに送信する. shutdownコマンドを実行すると、RDB永続化も自動的に実行されます.
起動時にロード
RDBのロード作業は実際のサーバ起動時に自動的に実行され、特別なコマンドはありません.しかし、AOFの優先度が高いため、AOFがオンの場合、AOFファイルを優先的にロードしてデータを復元します.
ファイル検証:
RedisがRDBファイルをロードすると、RDBファイルが検証され、ファイルが破損するとログにエラーが印刷され、Redisの起動に失敗します.
AOF持続化
RDB永続化は、プロセスデータをハードディスクに書き込み、AOF永続化(Append Only File永続化)は、Redisが実行する書き込みコマンドを個別のログファイルに記録し、Redisが再起動されると再びAOFを実行してデータを復元する.
RDBに比べてAOFはリアルタイム性が優れているため,現在主流の持続化スキームとなっている.
AOFを開く:RedisサーバーはRDBをデフォルトで開き、AOFを閉じる.AOFをオンにするには、プロファイルで「appendonly yes」を設定する必要があります.
ファイル検証:
RDBファイルの読み込みと同様に、RedisがAOFファイルを読み込むと、AOFファイルが検証され、ファイルが破損するとログに印刷エラーが発生し、Redisの起動に失敗します.
RDBとAOFの長所と短所
RDB持続化:の利点:RDBファイルはコンパクトで、体積が小さく、ネットワークの伝送が速く、全量の複製に適している.回復速度はAOFよりかなり速い.もちろん,RDBの最も重要な利点の一つは,AOFと比較して性能への影響が比較的小さいことである. 欠点:RDBファイルの致命的な欠点は、そのデータスナップショットの持続化方式が必然的にリアルタイム持続化ができないことを決定していることであるが、データがますます重要になっている今日、データの大量損失は受け入れられないことが多いため、AOF持続化が主流となっている.さらに、RDBは、特定のフォーマットを満たす必要があり、互換性が悪い/ AOF持続化:はRDBの永続化に対応し、AOFの利点は秒レベルの永続化をサポートし、互換性がよく、欠点はファイルが大きく、リカバリ速度が遅く、性能に大きな影響を与えることである.
Redisでは、高可用性を実現する技術として、主に持続化、複製(読み書き分離)、哨兵、クラスタが挙げられる.
Redis永続化の概要
永続化機能:Redisはメモリ・データベースであり、データはすべてメモリに格納されます.
Redisの永続化はRDBとAOFの永続化に分けられる.
RDB持続化
RDB永続化は、現在のプロセスにおけるデータ生成スナップショットをハードディスク(したがって、スナップショット永続化とも呼ばれる)に保存し、保存されたファイル接尾辞はRDBである.
Redisが再起動されると、スナップショットファイルのリカバリデータを読み込むことができます.
トリガ条件:
saveコマンドは、RDBファイルの作成が完了するまでRedisサービスプロセスをブロックし、Redisサーバがブロックされている間、サーバはコマンド要求を実行できません.
bgsaveコマンドは、サブプロセスを作成し、サブプロセスによってRDBファイルを作成し、親プロセス(つまりRedisメインプロセス)がリクエストの処理を続行します.bgsaveコマンドの実行中、fork(orkがプロセスである場合、サブプロセスのredis接続は使用できません.再接続する必要があります)のみがサーバをブロックし、saveコマンドでは、プロセス全体がサーバをブロックします.
RDB永続化が自動的にトリガされると、Redisはsaveではなくbgsaveを使用して永続化する.以下、自動トリガRDB持続化条件について説明する.
自動トリガ:最も一般的な場合は、プロファイルでsave mnを介して、m秒内にn回の変化が発生した場合にbgsaveがトリガされます.
RedisプロファイルRedis.confでは、次の構成情報が表示されます.
save 900 1 # 900 , Redis 1 , bgsave。
save 300 10
save 60 10000
save m n以外にもbgsaveがトリガーされる場合があります.
起動時にロード
RDBのロード作業は実際のサーバ起動時に自動的に実行され、特別なコマンドはありません.しかし、AOFの優先度が高いため、AOFがオンの場合、AOFファイルを優先的にロードしてデータを復元します.
ファイル検証:
RedisがRDBファイルをロードすると、RDBファイルが検証され、ファイルが破損するとログにエラーが印刷され、Redisの起動に失敗します.
AOF持続化
RDB永続化は、プロセスデータをハードディスクに書き込み、AOF永続化(Append Only File永続化)は、Redisが実行する書き込みコマンドを個別のログファイルに記録し、Redisが再起動されると再びAOFを実行してデータを復元する.
RDBに比べてAOFはリアルタイム性が優れているため,現在主流の持続化スキームとなっている.
AOFを開く:RedisサーバーはRDBをデフォルトで開き、AOFを閉じる.AOFをオンにするには、プロファイルで「appendonly yes」を設定する必要があります.
ファイル検証:
RDBファイルの読み込みと同様に、RedisがAOFファイルを読み込むと、AOFファイルが検証され、ファイルが破損するとログに印刷エラーが発生し、Redisの起動に失敗します.
RDBとAOFの長所と短所
RDB持続化: