Redis の永続性とマスター/スレーブ レプリケーション メカニズムの概要

この記事の内容は、redis の永続化とマスター/スレーブ レプリケーションのメカニズムを紹介するものであり、必要な方は参考にしていただければ幸いです。

Redis の永続性

Redis は、さまざまなレベルでさまざまな永続化メソッドを提供します。

RDB の永続化はポイントを生成できます。指定された時間間隔内のデータセットのインタイムスナップショット

AOF は、サーバーによって実行されたすべての書き込み操作コマンドを永続的に記録し、サーバーの起動時にこれらのコマンドを再実行します。 AOF ファイル内のすべてのコマンドは Redis プロトコル形式で保存され、新しいコマンドがファイルの末尾に追加されます。 Redis は、AOF ファイルのサイズがデータ セットの状態を保存するために必要な実際のサイズを超えないように、バックグラウンドで AOF ファイルを書き換えることもできます。

Redis は、AOF 永続性と RDB 永続性を同時に使用することもできます。この場合、Redis が再起動すると、AOF ファイルを使用してデータセットを復元することが優先されます。これは、AOF ファイルによって保存されたデータセットは、通常、RDB ファイルによって保存されたデータセットよりも完全であるためです。
永続性をオフにして、サーバーの実行中にのみデータが存在するようにすることもできます。

RDB(Redis Database)

Rdb: 指定された時間間隔内でデータセットのメモリ内スナップショットをディスクに書き込みます。専門用語では、スナップショットはスナップショットです。復元されると、スナップショット ファイルはメモリに直接読み込まれます。

Redis は永続化のために別のサブプロセスを作成 (フォーク) し、永続化プロセスが終了すると、この一時ファイルを使用して最後の永続化が置き換えられます。返却された書類。プロセス全体を通じて、メイン プロセスは IO 操作を実行しないため、非常に高いパフォーマンスが保証されます。大規模なデータ リカバリが必要であり、データ リカバリの整合性がそれほど重要ではない場合は、RDB 方式の方が AOF 方式よりも効率的です。高効率。 RDB の欠点は、最後の永続化以降のデータが失われる可能性があることです。

Fork の機能は、現在のプロセスと同じプロセスをコピーすることです。新しいプロセスのすべてのデータ (変数、環境変数、プログラム カウンタなど) は同じ値になります。元のプロセスと同じですが、まったく新しいプロセスであり、元のプロセスのサブプロセスとして機能します

隠れた危険: 現在のプロセスに大量のデータがある場合、fork 後のデータ量*2サーバーに高い負荷がかかり、動作パフォーマンスが低下する原因となります。

Rdb は dump.rdb ファイルを保存します

テストでは、flushAll コマンドを実行し、shutDown を使用します。プロセスが直接閉じられると、redis は 2 回目に開かれたときに dump.rdb ファイルを自動的に読み取りますが、復元されるときはすべて空になります。 (この理由: シャットダウン時に、redis システムは空の dump.rdb を保存して、元のキャッシュ ファイルを置き換えます。そのため、redis システムが 2 回目に開かれたときに、空の値ファイルが自動的に読み取られます)

RDB 保存操作

Rdb はメモリ全体の圧縮スナップショットであり、スナップショットのトリガーに合わせて RDB のデータ構造を構成できます。デフォルトの条件は、1 分間に 1 回、または 5 分間に 10 回、または 15 分間に 1 回の変更です。RDB 永続化戦略を無効にする場合は、何も設定しないでください。命令を保存するか、空の文字列パラメーターを渡して保存しても問題ありません。

-----> save コマンド: 操作オブジェクトをすぐに保存します

RDB スナップショットをトリガーする方法

保存: 保存するときは、保存するだけで、他のものは無視し、すべてをブロックします。

Bgsave: redis はスナップショット操作をバックグラウンドで実行します。また、lastsave コマンドを使用して、最後に成功したスナップショットの実行時刻を取得することもできます。

fluhall コマンドを実行すると、dump.rdb ファイルも生成されますが、空になります。

復元方法:

バックアップ ファイル (dump.rdb) を Redis インストール ディレクトリに移動し、サービスを開始します。

Config get dir コマンドで、 directory

#停止方法

RDB 保存ルールを動的に停止する方法: redis -cli config set save ""

AOF(Append Only File)

各書き込み操作をログの形式で記録し、redis によって実行されたすべての書き込み命令を記録します (読み取り操作は記録されません)。ファイルのみを追加できますが、再書き込みはできません。redis が起動すると、ファイルが読み取られてデータが再構築されます。つまり、redis が再起動されると、ログの内容に従って書き込み命令が前から後ろに実行されます。ファイルを作成してデータ復旧作業を完了します。

======追加のみモード=====

aof を開く: 追加のみ Yes (デフォルトは no)

注:

実際の作業や生産では、aof ファイルの破損 (ネットワーク伝送またはその他の問題により aof ファイルの破損が発生する) がよく発生します。

サーバーの起動時にエラーが発生します (ただし、dump.rdb ファイルは完了しています)。これは、起動前に aof ファイルがロードされていることを示します。コマンド redis-check-aof --fix aof file [aof 構文と矛盾するフィールドを自動的にチェックして削除]

Aof ポリシー

Appendfsync パラメータ: 常に同期永続化では、すべてのデータ変更がすぐにディスクに記録されるため、パフォーマンスは低下しますが、データの整合性は向上します。

Everysec: 工場出荷時のデフォルト推奨、非同期操作、毎秒記録、1 秒後のダウンタイム、データ損失

いいえ: fsync は行わない: データをオペレーティング システムに渡して処理します。より高速ですが安全性は低いオプションです。

リライトコンセプト: AOF はファイルの追加を使用しますが、ファイルはますます大きくなります。この状況を回避するために、新しいリライト メカニズムが使用されます。 、aof ファイルのサイズが設定されたしきい値を超えると、redis は aof ファイルの内容を自動的に圧縮し、データを復元できる最小限の命令セットを保持するコマンド bgrewirteaof を使用できます。

書き換えの原則: aof ファイルが成長し続けて大きくなると、新しいプロセスがフォークされてファイルを書き換えます (つまり、

は最初に一時ファイルを書き込み、次にその名前を変更します)。新しいプロセスのメモリ 各レコードには set ステートメントがあり、aof ファイルを書き換える操作は、古い aof ファイルを読み取るのではなく、コマンドを使用してメモリ データベースの内容全体を新しい aof ファイルに書き換えます。スナップショット。

トリガーメカニズム: redis は最後に書き換えられた aof のサイズを記録します。デフォルト設定では、aof ファイルのサイズが最後の書き換え後のサイズの 2 倍になり、ファイルが 64M より大きい場合にトリガーされます ( 3G)

no-appendfsync-on-rewrite no: データのセキュリティを確保するために、デフォルトの no を使用するかどうか。 -rewrite-percentage multiple settings base value

auto-aof-rewrite-min-size ベースライン値のサイズを設定します

AOF の利点

#AOF 永続性を使用すると、Redis の耐久性が高まります。fsync なし、毎秒 fsync、書き込みコマンドが実行されるたびに fsync など、さまざまな fsync 戦略を設定できます。 AOF のデフォルト ポリシーは、1 秒に 1 回 fsync を実行することです。この構成でも、Redis は良好なパフォーマンスを維持でき、障害が発生した場合でも、失われるデータは最大 1 秒だけです (fsync はバックグラウンド スレッドで実行されます)。そのため、メインスレッドはコマンド要求の処理に懸命に取り組み続けることができます)。

AOF ファイルは追加操作のみを実行するログ ファイル (追加のみのログ) であるため、何らかの理由でログに不完全なコマンドが含まれている場合でも、AOF ファイルへの書き込みにはシークは必要ありません。書き込み時にディスクがいっぱいになる、書き込みが途中で停止するなど）場合、redis-check-aof ツールを使用すると、この問題を簡単に解決することもできます。

Redis は、AOF ファイルのサイズが大きくなりすぎると、バックグラウンドで AOF を自動的に書き換えることができます。書き換えられた新しい AOF ファイルには、現在のデータ セットを復元するために必要な最小限のコマンド セットが含まれています。 Redis は新しい AOF ファイルの作成プロセス中に既存の AOF ファイルにコマンドを追加し続けるため、書き換えプロセス全体が完全に安全です。たとえ書き換えプロセス中にシャットダウンが発生しても、既存の AOF ファイルは失われません。 。新しい AOF ファイルが作成されると、Redis は古い AOF ファイルから新しい AOF ファイルに切り替えて、新しい AOF ファイルへの追加を開始します。

AOF ファイルには、データベース上で実行されたすべての書き込み操作が順序どおりに保存されます。これらの書き込み操作は Redis プロトコルの形式で保存されるため、AOF ファイルの内容は非常に簡単に読み取って分析できます。ファイル（解析）も非常に簡単です。 AOF ファイルのエクスポート (エクスポート) も非常に簡単です。たとえば、誤って FLUSHALL コマンドを実行した場合でも、AOF ファイルが上書きされていなければ、サーバーを停止し、AOF の最後にある FLUSHALL コマンドを削除するだけです。ファイルを削除し、Redis を再起動すると、データセットを FLUSHALL が実行される前の状態に復元できます。

AOF の欠点

同じデータ セットの場合、通常、AOF ファイルのサイズは RDB ファイルのサイズよりも大きくなります。

使用される fsync 戦略によっては、AOF は RDB よりも遅くなる可能性があります。通常の状況では、1 秒あたりの fsync パフォーマンスは依然として非常に高く、fsync をオフにすると、負荷が重い場合でも AOF を RDB と同じ速度にすることができます。ただし、RDB は、巨大な書き込み負荷を処理する場合に、より保証された最大レイテンシを提供できます。

AOF には過去にこのようなバグがありました。個別のコマンドが原因で、AOF ファイルをリロードすると、データ セットを保存時の元の状態に復元できなくなりました。 (たとえば、ブロッキング コマンド BRPOPLPUSH はかつてそのようなバグを引き起こしました。)

この状況に備えて、テスト スイートにテストが追加されました。ランダムで複雑なデータ セットを自動的に生成し、それらをリロードして、すべてが適切に動作していることを確認します。この種のバグは AOF ファイルでは一般的ではありませんが、それに比べて、RDB でこの種のバグが発生することはほとんどありません。

Redis データのバックアップ

データベースを必ずバックアップしてください。

ディスク障害やノード障害などにより、データが消失する可能性があり、バックアップを怠ると大変危険です。

Redis は、サーバーの実行中に RDB ファイルをコピーできるため、データのバックアップに非常に適しています。RDB ファイルが作成されると、変更は加えられません。サーバーが新しい RDB ファイルを作成する場合、まずファイルの内容を一時ファイルに保存します。一時ファイルが書き込まれると、プログラムは rename(2) を使用して元の RDB ファイルを一時ファイルにアトミックに置き換えます。

これは、RDB ファイルをいつでも安全にコピーできることを意味します。

推奨事項:

通常のタスク (cron ジョブ) を作成し、RDB ファイルを 1 時間ごとにフォルダーにバックアップし、それを 1 回ごとにバックアップします。日 RDB ファイルを別のフォルダーにバックアップします。

通常のタスク スクリプトを実行するたびに、スナップショット バックアップに対応する日付と時刻の情報があることを確認してください。たとえば、過去 48 時間の 1 時間ごとに、find コマンドを使用して期限切れのスナップショットを削除します。スナップショット。過去 1 か月または 2 か月の毎日のスナップショットを保存することもできます。

少なくとも 1 日に 1 回は、データ センターの外部、または少なくとも Redis サーバーを実行している物理マシンの外部で RDB をバックアップします。

災害復旧バックアップ

Redis 災害復旧バックアップは、基本的にデータをバックアップし、これらのバックアップを複数の異なるサーバーに転送します。 。

ディザスター リカバリー バックアップにより、Redis が実行されスナップショットが生成されるメイン データ センターで重大な問題が発生した場合でも、データを安全な状態に保つことができます。

Redis ユーザーの中には起業家もいます。彼らは無駄にできるお金があまりないので、実用的で安価な災害復旧バックアップ方法をいくつか紹介します:

Amazon S3 やその他のサービス。 S3 は、災害時バックアップ システムを構築するのに適した場所です。最も簡単な方法は、毎時または毎日の RDB バックアップを暗号化して S3 に転送することです。データの暗号化は、gpg -c コマンド (対称暗号化モード) で実行できます。パスワードは、必ず複数の異なる安全な場所に保管してください (たとえば、組織内の最も重要な人物にパスワードをコピーできます)。複数のストレージ サービスを使用してデータ ファイルを同時に保存すると、データのセキュリティが向上します。

スナップショットの送信は、SCP (SSH のコンポーネント) を使用して実行できます。以下はシンプルで安全な転送方法です。データセンターから遠く離れた VPS (仮想プライベートサーバー) を購入し、SSH をインストールし、パスワードなしの SSH クライアントキーを作成し、このキーを VPS のauthorized_keys ファイルに追加します。ファイルをこの VPS に転送できます。最高のデータ セキュリティを確保するには、災害復旧用に少なくとも 2 つの異なるプロバイダーから VPS を購入してください。

このタイプの災害復旧システムは、慎重に扱わないと簡単に障害が発生する可能性があることに注意してください。

ファイル転送の完了後、少なくとも、転送されたバックアップ ファイルのサイズが元のスナップショット ファイルのサイズと同じかどうかを確認する必要があります。 VPS を使用している場合は、ファイルの SHA1 チェックサムを比較することで、ファイルが完全に転送されたかどうかを確認することもできます。

さらに、バックアップ ファイルの転送を担当する転送 (転送) が失敗した場合に通知する独立したアラーム システムも必要です。

Redis マスター/スレーブ レプリケーション

Redis は、シンプルで使いやすいマスター/スレーブ レプリケーション機能をサポートしています。マスターサーバーの正確なレプリカになります。

Redis レプリケーション機能に関するいくつかの重要な側面を次に示します:

Redis は非同期レプリケーションを使用します。 Redis 2.8 以降、スレーブ サーバーはレプリケーション ストリームの処理の進行状況を 1 秒に 1 回マスター サーバーに報告します。

マスター サーバーは複数のスレーブ サーバーを持つことができます。

マスター サーバーだけでなく、スレーブ サーバーも独自のスレーブ サーバーを持つことができ、複数のスレーブ サーバーがグラフのような構造を形成することもできます。

レプリケーション機能はマスター サーバーをブロックしません。1 つ以上のスレーブ サーバーが初期同期中であっても、マスター サーバーはコマンド要求の処理を続行できます。

レプリケーション機能はスレーブ サーバーをブロックしません。対応する設定が redis.conf ファイル内で行われている限り、サーバーは、スレーブ サーバーがサーバーは初期同期中です。

ただし、古いバージョンのデータ セットがサーバーから削除され、新しいバージョンのデータ セットがロードされる間、接続要求はブロックされます。

マスターサーバーへの接続が切断されたときにクライアントにエラーを送信するようにスレーブサーバーを設定することもできます。

レプリケーション機能は、純粋にデータの冗長性を目的として使用することも、複数のスレーブ サーバーに読み取り専用コマンド リクエストを処理させることでスケーラビリティを向上させることもできます。たとえば、重い SORT コマンドの実行を下位ノードに任せることができます。 。
レプリケーション機能を使用すると、マスター サーバーの永続化操作を免除できます。マスター サーバーの永続化機能をオフにして、スレーブ サーバーに永続化操作を実行させます。

メインサーバーの永続性、レプリケーション機能のデータセキュリティをオフにする場合。

Redis レプリケーション機能を設定する場合は、メインサーバーの永続化機能を有効にすることを強く推奨します。それ以外の場合、デプロイされたサービスは、遅延やその他の問題によって自動的にプルアップされることを回避する必要があります。

ケース:

1. ノード A がメイン サーバーであり、永続性がオフになっていると仮定します。そして、ノード B とノード C は、ノード A

2. ノード A からデータをコピーします。ノード A がクラッシュし、サービスを自動的にプルアップしてノード A を再起動します。ノード A の永続性がオフになっているため、そこで再起動します。その後はデータはなくなります。

3. ノード B とノード C はノード A からデータをコピーしますが、A のデータは空であるため、保存したデータ コピーは削除されます。

メイン サーバーの永続化がオフになり、同時に自動プルアップ プロセスがオンになると、Sentinel を使用して高可用性を実現したとしても非常に危険です。レディス。メイン サーバーが急速に起動されるため、設定されたハートビート間隔内にメイン サーバーが再起動されたことを Sentinel が検出できず、その後も上記のデータ損失プロセスが実行されます。

データ セキュリティは常に非常に重要であるため、メイン サーバーがオフになったときに永続性を自動的に取得することを禁止する必要があります。

スレーブ サーバーの構成

スレーブ サーバーの構成は非常に簡単で、次の行を構成ファイルに追加するだけです。
slaveof 192.168 .1.1 6379
もう 1 つの方法は、SLAVEOF コマンドを呼び出し、メイン サーバーの IP とポートを入力すると、同期が開始されます
127.0.0.1:6379> SLAVEOF 192.168.1.1 10086
OK

読み取り専用スレーブ サーバー

Redis 2.6 以降、スレーブ サーバーは読み取り専用モードをサポートしており、このモードがデフォルトのモードです。スレーブサーバー。
読み取り専用モードは、redis.conf ファイルのスレーブ読み取り専用オプションによって制御されます。このモードは、CONFIG SET コマンドによってオンまたはオフにすることもできます。

読み取り専用スレーブ サーバーは書き込みコマンドの実行を拒否するため、操作エラーによりデータが誤ってスレーブ サーバーに書き込まれることはありません。

さらに、スレーブ サーバーでコマンド SLAVEOF NO ONE を実行すると、スレーブ サーバーはレプリケーション機能をオフにし、元の同期されたデータ セットはスレーブ サーバーからマスター サーバーに戻りません。捨てられた。

「SLAVEOF NO ONE は同期データセットを破棄しない」機能を利用することで、メインサーバに障害が発生した場合でも、スレーブサーバを新たなメインサーバとして使用することができ、無停止運用を実現します。

スレーブ サーバーの関連構成:

マスター サーバーが requirepass オプションを使用してパスワードを設定する場合、同期を許可するためにスレーブサーバーの操作をスムーズに進めるためには、スレーブサーバーに対しても対応する認証設定を行う必要があります。

実行中のサーバーの場合、クライアントを使用して次のコマンドを入力できます:
config set masterauth
このパスワードを永続的に設定するには、構成ファイルに追加できます。
masterauth

マスター サーバーは、少なくとも N 台のスレーブ サーバーが存在する場合にのみ書き込み操作を実行します

Redis 2.8 以降、データ セキュリティを確保するために、次のことができます。現在少なくとも N 台のスレーブ サーバーが接続されている場合にのみ書き込みコマンドを実行するようにマスター サーバーを構成します。

ただし、Redis は非同期レプリケーションを使用するため、マスター サーバーから送信された書き込みデータがスレーブ サーバーで受信されない可能性があり、データ損失の可能性が依然として存在します。

この機能の仕組みは次のとおりです。

スレーブ サーバーはマスター サーバーに 1 秒に 1 回 ping を送信し、レプリケーション ストリームのステータスを報告します。状況。
マスター サーバーは、各スレーブ サーバーが最後に PING を送信した時刻を記録します。

ユーザーは、構成を通じて最大ネットワーク遅延 min-slaves-max-lag と、書き込み操作の実行に必要なスレーブ サーバーの最小数 min-slaves-to-write を指定できます。

少なくとも min-slaves-to-write スレーブ サーバーがあり、これらのサーバーのレイテンシー値が min-slaves-max-lag 秒未満の場合、マスター サーバーは書き込みを実行します。クライアントから要求された操作。

一方、min-slaves-to-write および min-slaves-max-lag で指定された条件を満たさない場合、書き込み操作は実行されず、メイン サーバーはリクエストが実行されます。書き込み操作のクライアントがエラーを返しました。

この機能の 2 つのオプションとその必要なパラメーターは次のとおりです:

min-slaves-to-write <number of slaves>
min-slaves-max-lag <number of seconds>

上記はこの記事の全内容です。皆さんの学習に役立つことを願っています。さらにエキサイティングなコンテンツについては、PHP 中国語 Web サイトの関連チュートリアルのコラムに注目してください。 ！ ！

以上がRedis の永続性とマスター/スレーブ レプリケーション メカニズムの概要の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。