実践的な指導！Redis のマスター/スレーブ レプリケーションのプロセス全体を最初から学びます

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

マスター/スレーブ レプリケーションの概要

単一の Redis の問題を分析する

プロジェクトでは、書き込み操作よりも読み取り操作の方が多くなります。京東、淘宝網などのように、同時に、購入する人よりも見ている人がはるかに多くなります。単一の Redis はすべて、書き込み操作と読み取り操作の両方を実行する必要があります。効率が低く、同時実行性が高いと不安定になる

したがって、マスター/スレーブレプリケーションにつながります

百聞は一見に如かず

Redis マスター/スレーブ レプリケーションの概略図

上の絵の解釈

1. 上の図は、ホスト データが更新された後にスタンバイ マシンに自動的に同期するマスター/スレーバー メカニズムを示しています。
2. マスターは主に書き込み、スレイバーは主に読み取り
3. 利点: 読み取りと書き込みの分離、効率の向上 (理解: 読み取りと書き込みの分離後、読み取りおよび書き込み操作を異なる Reid に分散し、単一 Redis への負荷を軽減し、効率を向上させる)
4. 利点: 災害復旧と迅速なリカバリ (理解: スレーバーが正常に動作しなくなった場合は、別のスレーバーに切り替えることができます)
5. マスター/スレーブ レプリケーションには 1 つのマスターと複数のスレーブが必要であり、複数のマスターは存在できません (理解: 複数のマスター サーバー マスターがある場合、スレーバーはどのマスターと同期するかを決定できず、データ障害が発生します)。
6. マスターサーバーの高可用性を解決するには、Redis クラスターを使用できます。

マスターと複数のスレーブを構築する

ニーズの表明

1. マスター/スレーブ レプリケーション構造を構築する
2. ここで 1 つのマスターと 2 つのスレーブを構築でき、他のスレーブもこれに従うことができます

アイデア分析

実行の開始

1. ディレクトリを作成し、redis.conf を /wyxredis にコピーします。

作成コマンドは mkdir /wyxredis です

作成したディレクトリ cd /wyxredis に移動します

次に、作成したばかりのディレクトリに redis.conf をコピーします

cp /etc/redis.conf /wyxredis/redis.conf

1. vi /wyxredis/redis.conf で次の設定を行います。

   

1. /wyxredis/redis6379.conf /wyxredis/redis6380.conf /wyxredis/redis6381.conf の 3 つのファイルを作成し、編集します

バッシュ

コードをコピーする

include /wyxredis/redis.conf pidfile /var/run/redis_6379.pid port 6379 dbfilename dump6379.rdb

最初の 3 つのファイルはすべてそのような操作ですが、ポート番号を変更する必要があることに注意してください。

1. 3 つの Redis サーバーを起動する

   

2. 3 つの Redis サービスに接続すると、図に示すように、情報レプリケーションによってマスター/スレーブ レプリケーションの関連情報が出力されます。この時点では、3 つの Redis すべてがマスターです

Connected_slaves は複数のスレーブ サーバーを表します

1. 6380 と 6381 をスレーバーとして、6379 をホストとして構成します。スレーバーでコマンドを実行して、インスタンスのスレーブ サーバーになります。

-コマンドの説明:slaveof <master_ip> <master_port>

上の写真を説明してください

role:slave は、マスター サーバーからのテーブルを含むマスター サーバーを表します。

master_host はメインサーバーの IP を指します

master_port はマスターサーバーのポートを指します

master_link_status_up はマスターサーバーがオンラインかどうかを表します

その他も実際に英単語をもとに解説されているのでわかりやすいです。

1. マスターに書き込むと、スレーブでデータを読み取ることができます。スレーブにデータを書き込むと、エラーが報告されます

1. この時点では、基本的なマスター/スレーブ レプリケーション構造は問題ありません。

マスター/スレーブ レプリケーション - 原理

回路図

上図の解釈 - マスター/スレーブ レプリケーション プロセス

• スレーブはマスターに正常に接続した後、同期コマンドを送信します。
• マスターは、バックグラウンド保存プロセスを開始するコマンドを受信し、データ セットを変更するために受信したすべてのコマンドを収集します。バックグラウンド プロセスの実行後、マスターはデータ ファイル全体をスレーブに転送して、完全な同期を完了します。
• スレーブ サービスはデータベース ファイル データを受信した後、それを保存し、メモリにロードします (つまり完全なコピー)。
• マスター データが変更されると、新しく収集された変更コマンドがスレーブに渡され、同期、つまり増分レプリケーションが完了します。
• ただし、マスターが再接続されている限り、完全同期 (フルコピー) が自動的に実行されます。

1人のマスターと2人のサーヴァント

スレーブサーバーがダウンして再起動しても、マスターの最新データを取得できます

マスター サーバーがダウンした場合、スレーブ サーバーはマスター サーバーをプリエンプトせず、マスター サーバーが回復しても、スレーブ サーバーは元のマスター サーバーを参照したままになります。

聖火を渡す

回路図

上の絵の解釈

1. 前のスレーブは次のスレーブのマスターになることができ、スレーブは他のスレーブから接続および同期リクエストを受信することもでき、その後、スレーブはチェーン内の次のマスターとして機能し、マスターの書き込み圧力を効果的に軽減し、分散化することができます。そしてリスクを軽減する

2. <master_ip><master_port> のスレーブを使用

3. リスクとしては、スレーブがダウンすると、後続のスレーブは同期できなくなることです。

4. ホストがハングアップし、スレーブはスレーブのままで、データを書き込むことができません

実験

1. 6381のホストを6380に設定し、そのデータ同期を6380から取得します。

1. 6380 および 6379 を表示

反クライアント

1. トーチを渡す構造により、マスターがダウンした場合、マスターを指すスレーブをマスターに昇格させることができ、後続のスレーブは変更する必要がありません

2. スレーブをマスターに変更するには、slaveof no one を使用します (注: 後でセンチネル モードを使用すると、切り替えを自動的に完了できます)。

実験

センチネルモード（センチネル）

動作図

2. センチネル モード (図に示すように): 顧客志向の自動バージョンで、ホストに障害があるかどうかをバックグラウンドで監視でき、障害がある場合は、スレーブ データベースをメインに自動的に変換します。投票数に応じたデータベース

実験

1. 1 つのマスターと 2 つのスレーブ モード、6379 と 6380、6381 に調整します。前の説明に従って調整するだけです。
2. /wyxredis/sentinel.confを作成します。名前はむやみに書けず、指定に従ってください

ヤムル

コードをコピーする

sentinel monitor redis_master 127.0.0.1 6379 1

例証します:

• redis_master は監視オブジェクトのサーバー名です。
• 1 は、少なくとも何人のセンチネルが移行に同意するかを意味します。ここでは、移行に同意するセンチネルが 1 人いる限り、切り替えが可能であることを示すために 1 を設定します。

センチネルを開始し、センチネルのポートが 26379 であることに注意してください。

マスターが電話を切ると、スレーブの選択から新しいマスターが生成されます

元のマスターが再起動すると、自動的にスレーブになります。

注意事項と詳細

1. センチネルモードでは、ホストダウン後の実行プロセス分析

2. 上図の解釈 - センチネルがスレーブ マシンから新しいマスター ホストを選択する方法と選択条件は次のとおりです。

1. redis.conf のデフォルトの優先度:replica-priority 100、値が小さいほど優先度が高くなります
2. オフセットは元のホストから取得したデータの量を指し、最も完全なデータを持つものが優先されます。
3. 各 Redis インスタンスが開始されると、40 桁の runid がランダムに生成され、値が小さいほど優先度が高くなります。