問題タブ [redis-sentinel]

Windows 10 PCにUbuntu Bashをインストールしました。その後、コマンドを使用してRedisをインストールした後、apt-get installコマンドを使用してredisに接続できredis-cli、情報に詳細が表示されました

その後、それに接続できるレプリカを作成しました

フォルダーからインストールされるデフォルトの構成ファイルを使用して Sentinel を開始したことを投稿し/etc/redis/ます。

redisを起動するために使用したコマンドはsudo redis-server /etc/redis/sentinel1.conf --sentinel

しかし、redis-cli -p 26379コマンドを使用して接続しようとすると、このエラーが発生します

指定されたポートが26379であるsentinel.confファイルを確認しました

redis-sentinel /path/to/sentinel.conf しかし、同じエラーでセンチネルを開始しようとしました。

仮想マシンで実行されている Ubuntu でも同じセットアップが正常に機能します。

編集

Windows 10 BashでUbuntuを実行しているため、netstat -tunlpaコマンドはこれを示しています

そして、ps aux| grep redisコマンド出力はこれです

Sentinel がポート 26379 で実行されていることを示しています

私は Redis を使用しており、c# で stackexchange クライアント ライブラリを使用しています。「Redis inside」と呼ばれるサードパーティ ライブラリを使用して、いくつかの統合テスト ケースを作成しました。

次に、センチネル フェールオーバー ケースの統合テスト ケースを作成する必要があります。

誰もこれに取り組んだことがありますか？

ありがとう！

私たちのセットアップ

• 各 AWS シドニー AZ に 1 つずつ、3 つの redis センチネル
• AWS Auto-scaling グループ ポリシーを使用して水平方向に自動的にスケーリングするマスターと複数のスレーブを備えた 2 ～ 500 個の redis ノード
• トラフィックをマスターにプッシュする 1x 書き込み ELB
• トラフィックをスレーブにプッシュする ELB の読み取り x 1
• Sentinel にトラフィックをプッシュする 1x Sentinel ELB
• ファシリテーター x 1 (詳細は以下を参照)

このセットアップは、メタデータとキャッシュと呼ばれるもののために 2 つのクラスターに複製されます。より多くのクラスターを展開したいと考えています。

ファシリテーター

Sentinels pub/sub にサブスクライブし、+switch-masterメッセージをリッスンする、私たちが構築した Python デーモンです。ファシリテーターが実行するアクションは次のとおりです。

1. +switch-master によってトリガーされたマスター フェイルオーバーを検出し、マスターします。
2. 次を使用して、新しいマスターのセンチネルを照会しますSENTINEL get-master-addr-by-name mymaster
3. RedisClusterNodeRole = slave で古いマスターにタグを付けます
4. RedisClusterNodeRole = master で新しいマスターにタグを付けます
5. 書き込み ELB に新しいマスターを追加します
6. 読み取り ELB から新しいマスターを削除します
7. 書き込み ELB から古いマスターを削除します
8. 古いマスターを読み取り ELB に追加しようとします (サーバーがダウンしている場合、これは失敗しますが、問題ありません)。

問題

スレーブはトラフィックに応じて 1 日に複数回出入りする可能性があるため、両方のクラスターのセンチネルに属する一部のスレーブが同じスレーブをめぐって争うことになります。これは、IP プールがクラスター間で共有されているために発生します。私たちが知る限り、スレーブ ID はそれらの IP です。

複製する方法は次のとおりです。

1. クラスタ キャッシュには IP 172.24.249.152のマスターがあります
2. クラスター キャッシュには、IP 172.24.246.142のスレーブをマスターに昇格させるマスター フェールオーバーがあります。IP 172.24.249.152 のノードがオフになりました
3. クラスター メタデータがスケールアップし、DHCP が IP 172.24.249.152 (クラスター キャッシュ上の以前のマスター) を割り当てます。
4. クラスター キャッシュは、以前のマスターが起動していることを認識し、172.24.246.142 (キャッシュ クラスターの新しいマスター)のスレーブとして再構成しようとします。
5. クラスター メタデータは 172.24.246.142 で +sdown をトリガーし、しばらくして -sdown に続いて +slave-reconf-sent をトリガーし、メタデータ クラスターのスレーブとして再構成を試みます。
6. クラスタ キャッシュは、クラスタ メタデータがポイント 5 で行っているのと同じことをしようとします。

センチネルは、そのリソースを永遠に奪い合うこの無限ループに陥ります。異なるマスター名を持つ両方の redis クラスターを管理するセンチネル グループしかない場合でも、これは発生します。これにより、センチネルは異なるクラスター間のリソースを認識しておらず、クラスターごとに論理的なことを個別に実行していると考えられます。

試した解決策

1. +sdown イベントの後に a をトリガーSENTINEL reset mymasterして、センチネルにそのノードを忘れさせようとします。これに関する問題は、そのクラスターがマスター フェイルオーバーを実行している場合に競合状態が発生する可能性があることです。私たちはこの仮定をうまく複製し、1 つのマスターを指し、他の 2 つが別のマスターを指しているという、非同期のセンチネルを残しました。
2. クラスターごとに 1 つの IP のプールにネットワークを分離します。これは、IP が再利用されないため機能しますが、新しいクラスターが必要な場合に、機敏性が大幅に低下し、複雑になります。これが最終的な解決策ですが、可能であれば回避したいと考えています。

理想的なソリューション

1. Redis Sentinel はSENTINEL removeslave 172.24.246.142 mymaster、スレーブで +sdown イベントが発生するたびに実行できる を提供します。これにより、そのクラスタは、a が持つ副作用を作成することなく、そのスレーブが存在していたことを忘れますSENTINEL reset mymaster。

2. IP だけでスレーブの一意性を識別するのをやめます。おそらく、redisサーバーの開始タイムスタンプまたはその他のトークンを追加して、シャットダウンされたスレーブと、同じIPで再起動された新しいスレーブが同じノードとして表示されるのを防ぎます。

質問

redis センチネル コードの変更を伴わず、クラスター間で IP プールを分離する必要のない他のソリューションを考えられますか?

マスターとスレーブでredisを使いたいです。すなわち、いくつかの破片。各シャードには、1 つのマスターと複数のスレーブがあります。

マスターを使用して書き込み、スレーブを読み取りに使用するように temproxy を構成することは可能ですか? それとも、すべての要求がマスターに送信されますか?

A、B、C の 3 つの異なるマシンで実行されている 3 つのレプリケートされた Redis インスタンスがあります。最初に A をマスターとして選択します。また、A を監視する 3 つのセンチネル (各マシンに 1 つ) があります。

A がダウンした場合、センチネルにフェールオーバー先の特定のマスター (B など) を選択してもらいます。センチネルの選出メカニズムに任せるのではなく、特定のマスターを選択する方法はありますか?

この質問はどこにも見つからなかったので、標準的な手順ではないと思うので、その理由を説明します。私のアプリケーションは、ロード バランサーの背後にある A、B、および C で実行されています。マスターは、他の 2 つのスレーブにレプリケートされたローカルのRedis データベースを使用します。

A に障害が発生すると、ロード バランサーは B をマスターとして選択し、Redis センチネルは C を Redis マスターとして選択できます。先ほど言ったように、インスタンスをローカルにする必要があるため、B を Redis マスターとして指定する必要があります。