この記事では、Redis の Sentinel メカニズムを理解し、sentinel を実行する 2 つの方法を紹介します。
Redis-Sentinel は、公式に推奨される高可用性 (HA) ソリューションです。 Redis ソリューションでは、Redis をマスター/スレーブの高可用性ソリューションとして使用する場合、マスターがダウンした場合、Redis 自体 (多くのクライアントを含む) は自動マスター/スレーブ切り替えを実装せず、Redis-sentinel 自体も独立しています。運用プロセスでは、複数のマスター/スレーブ クラスターを監視し、マスターがダウンしていることを検出した後に自己理解切り替えを実行できます。 [関連する推奨事項: Redis ビデオ チュートリアル ]
その主な機能は次のとおりです:
単一の Sentinel プロセスだけを使用して Redis クラスターを監視するのは明らかに信頼性がありません。 Sentinel プロセスがクラッシュすると (Sentinel 自体にも単一障害点があります)、クラスタ システム全体が期待どおりに動作できなくなります。したがって、センチネルをクラスター化する必要がありますが、これにはいくつかの利点があります:
4.
最初のタイプ
#上記 2 つの方法の両方で、Sentinel 構成ファイル Sentinel.conf を指定する必要があります。指定されていない場合、Sentinel は始まらない。 Sentinel はデフォルトでポート 26379 をリッスンするため、実行する前にポートが他のプロセスによって占有されていないことを確認する必要があります。
5.
sentinel モニター mymaster 127.0.0.1 6379 2
sentinel ミリ秒後のダウン mymaster 60000 Sentinel フェイルオーバー - timeout mymaster 180000 SentinelParallel-syncs mymaster 1 Sentinel Monitor resque 192.168.1.3 6380 4 Sentinel down-after-msends resque 10000 Sentinel failed over-timeout resque 180000 SentinelParallel-syncs resque 5
次に、上記の設定項目を 1 行ずつ説明します。上記の設定はitem は mymaster と resque という名前の 2 つのマスターを構成します。構成ファイルはマスター情報を構成するだけで済みます。スレーブは自動的に検出できるため、スレーブ情報を構成する必要はありません (マスター ノードにはスレーブに関するメッセージが含まれます)。設定ファイルは Sentinel の実行中に動的に変更されることに注意してください。たとえば、マスターとスレーブの切り替えが発生すると、設定ファイル内のマスターが別のスレーブに変更されます。このようにして、後で Sentinel が再起動された場合、この構成に基づいて以前に監視していた Redis クラスターのステータスを復元できます。
sentinel Monitor mymaster 127.0.0.1 6379 2
この行は、sentinel によって監視されているマスターの名前が mymaster で、アドレスが 127.0.0.1:6379 であることを表しています。行末の最後の 2 は何を意味しますか?ネットワークの信頼性が低いことはわかっています。センチネルは、ネットワークの輻輳によりマスター Redis が停止していると誤って認識することがあります。センチネルがクラスタ化されている場合、この問題の解決策は非常に簡単になります。複数のセンチネルが相互に通信する必要があるだけです。マスターが本当に死んでいるかどうかを確認するために通信します。この 2 は、クラスター内にマスターが死んだと考えているセンチネルが 2 人いる場合、マスターは本当に利用できないと見なせることを意味します。 (センチネル クラスター内の各センチネルも、ゴシップ プロトコルを通じて相互に通信します)。
プログラミング関連の知識について詳しくは、プログラミング ビデオをご覧ください。 !
以上がRedis の Sentinel メカニズムについて説明し、その使用法を紹介しましょう。の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。