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

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

redisクラスターの戦略です

スレーブ（ライブラリ）ありまたはマスター（ライブラリ）なし：弟は兄が誰であるかを選択できますが、兄には弟を選択する権利がありません

読み取りと書き込みの分離：マスター書き込み、スレーブ読み取り

1人のマスターと2人の使用人

3つのサーバーを準備し、redis.confを変更します

bind 0.0.0.0

3つのredisを開始し、各マシンの役割を確認します。すべてマスターです。

info replication

テスト開始

• まず、3台すべてのマシンを空にして、最初のマシンに付加価値を付けます

  mset k1 v1 k2 v2
  

• 他の2台のマシンをコピーします（兄を探します）

  slaveof 192.168.204.141 6379
  

• 最初の付加価値

  set k3 v3
  

思考1：スレーブの前にk1とk2を取得できますか？

• はい、兄貴をフォローしている限り、以前のデータはすぐに同期されます

思考2：スレーブの後にk3を取得できますか？

• はい、兄貴をフォローしている限り、データはすぐに同期されます

思考3：k4を同時に追加した結果はどうなりますか？

• マスター（141master）は正常に追加できますが、スレーブ（142と143はスレーブ）は失敗します。スレーブはデータの読み取りのみを担当し、データを書き込む権利はありません。これが「読み取り/書き込み分離」です。

思考4：マスターシャットダウンとスレーブマシンはどうですか？

• 142と143はまだスレーブであり、マスターがオフラインであることを示しています

思考5：ホストが再起動したときのスレーブはどうですか？

• 142と143はまだスレーブであり、マスターがオンラインであることを示しています

思考6：スレーブマシンは死んでいます、マスターマシンはどうですか？飛行機から戻った後、アイデンティティは変わりましたか？

• ホストは変更されておらず、1つのスレーブのみが欠落しています
• ホストとスレーブは変更されておらず、再起動から戻ったスレーブがマスターになり、元のクラスターには存在しなくなります。

血で

マスターは理論的には複数のスレーブを持つことができますが、この場合、マスターは非常に疲れます

Javaオブジェクト指向継承の推移性を使用して、この問題を解決し、ホストの負担を軽減できます。

3世代を形成する：

127.0.0.1:6379> slaveof 192.168.204.141 6379 		# 142跟随141
OK
127.0.0.1:6379> slaveof 192.168.204.142 6379 		# 143跟随142
OK

王位を簒く

1つのマスター、2つのスレーブ、1つのマスターが電話を切ると、2つのスレーブから1つのマスターのみを選択できます。

国は統治者なしではありえない、軍隊は指揮官なしではありえない

ボスを手動で選択

シミュレーションテスト：1はマスター、2と3はスレーブ、1が電話を切ると、2はマスターとしての電力を改ざんし、3は2に続きます。

slaveof no one 		# 2上执行，没有人能让我臣服，那我就是老大

slaveof 192.168.204.142 6379 		# 3跟随2号

思考：1が戻るとどうなりますか？

• 2と3は新しいクラスターを形成し、1とは何の関係もありません。だから1は洗練された司令官になりました

コピーの原則

上記の手順を完了すると、サーバーからのデータ初期化のすべての操作が完了し、スレーブサーバーはユーザーからの読み取り
要求を受信できるようになります。

• フルコピー：スレーブ初期化段階、この時点で、スレーブはマスター上のすべてのデータをコピーする必要があります。スレーブがデータファイルを受信したら、それを保存してメモリにロードします。（ステップ1234）

• インクリメンタルレプリケーション：スレーブが初期化された後、正常に動作し始めたときにマスターサーバーで発生する書き込み操作をスレーブサーバーに同期するプロセス。（ステップ56）

  • ただし、マスターが再接続されている限り、1回限りの（完全な複製）同期が自動的に実行されます。

• Redisマスタースレーブ同期戦略：マスタースレーブが接続されたばかりの場合は、完全同期を実行します。完全同期が終了した後、増分同期を実行します。

• もちろん、必要に応じて、スレーブはいつでも完全同期を開始できます。

• redis戦略では、いずれの場合も、最初に増分同期を実行しようとします。失敗した場合は、スレーブに完全同期を実行するように要求します。

センチネルモード

パワーを奪う自動バージョン！

歩哨がパトロールしていて、突然気づきました！！！！！上司は死んでいて、男の子は自動的に投票し、新しい上司が群衆の中から選ばれます

Sentinelは、Redisの高可用性ソリューションです。

• 1つ以上のSentinelインスタンスで構成されるSentinelシステムは、任意の数のマスターサーバーとすべてのスレーブサーバーを監視できます。監視対象のマスターサーバーがオフライン状態になると、マスターサーバーの下のスレーブサーバーが自動的にオフラインになります。新しいメインサーバーにアップグレードします。 、その後、新しいメインサーバーがオフラインのメインサーバーに置き換わり、コマンドリクエストの処理を続行します

模擬試験

• 1つのマスター、2つおよび3つのスレーブ

• 各サーバーに構成ファイルsentinel.confを作成します。名前が間違っていてはならず、sentinel.confを編集します。

  # sentinel monitor 被监控主机名（自定义） ip port 票数
  sentinel monitor redis141 192.168.204.141 6379 1
  

• サービスを開始する順序：マスターRedis->スレーブRedis-> Sentinel1 / 2/3

  redis-sentinel sentinel.conf
  

• ナンバーワンのボスを切ると、バックグラウンドが自動的に激しい投票を開始して新しいボスを選出します

  127.0.0.1:6379> shutdown
  not connected> exit
  

• 最終的な権利の割り当てを表示する

  • 3人が新しい上司になり、2人が弟になりました

• 元上司が再び戻ってきたらどうしますか？

  • No.1が再び戻ってきて、3に等しい自分でマスターになります。
  • 数秒後、歩哨によって1号機の帰還が検出されました。1号機で遊んでグループに入らないでください。ただし、新しいボスはすでに登場しており、子供として再びグループに入ることができます。

不利益

すべての書き込み操作はマスターで行われるため、

次に、スレーブに同期して、2台のマシン間の通信が遅延するようにします。

システムが非常にビジー状態の場合、遅延の問題が増加します。

スレーブマシンの数が増えると、問題は大きくなります