2

3 ノードの redis クラスターで自動フェイルオーバー システムをセットアップしようとしています。これらのノードのそれぞれに redis-sentinel をインストールしました (この人のように: http://www.symantec.com/connect/blogs/configuring-redis-high-availability )。2 つまたは 3 つのノードがあれば、すべて問題ありません。問題は、ノードが 1 つしか残っておらず、それがスレーブである場合、自動的にマスターとして選出されないことです。クォーラムは 1 に設定されているため、最後のノードはマスターの odown を検出しますが、過半数がないためフェイルオーバーに投票できません。

この (驚くべき) 問題を克服するために、他のノードにマスターを要求する小さなスクリプトを作成しました。応答がない場合は、現在のノードをマスターとして設定します。このスクリプトは、通知スクリプトとして redis-sentinel.conf ファイル内で呼び出されます。しかし... redis-sentinel サービスが開始されるとすぐに、この設定は「消去」されます! /etc の構成ファイルを見ると、「sentinel notification-script」行が消えています (redis-sentinel はその構成ファイルを書き換えます)。しかし、私が書いた構成は利用できなくなりました。

1)  1) "name"
    2) "mymaster"
    3) "ip"
    4) "x.x.x.x"
    5) "port"
    6) "6379"
    7) "runid"
    8) "somerunid"
    9) "flags"
   10) "master"
   11) "pending-commands"
   12) "0"
   13) "last-ping-sent"
   14) "0"
   15) "last-ok-ping-reply"
   16) "395"
   17) "last-ping-reply"
   18) "395"
   19) "down-after-milliseconds"
   20) "30000"
   21) "info-refresh"
   22) "674"
   23) "role-reported"
   24) "master"
   25) "role-reported-time"
   26) "171302"
   27) "config-epoch"
   28) "0"
   29) "num-slaves"
   30) "1"
   31) "num-other-sentinels"
   32) "1"
   33) "quorum"
   34) "1"
   35) "failover-timeout"
   36) "180000"
   37) "parallel-syncs"
   38) "1"

これは、sentinel-masters コマンドの結果です。唯一のことは、以前に「ダウンアフターミリ秒」を5000に、「フェイルオーバータイムアウト」を10000に設定したことです...

誰かが似たようなものに会ったかどうかわかりませんか？まあ、誰かが何が起こっているのかについて少し考えているなら、私はそれについてうれしいです;）

4

2 に答える 2

3

これが、センチネルを redis インスタンス ノードに配置しない理由です。それらを監視エージェントと考えてください。Web サイトを実行しているノードと同じノードに Web サイト モニターを配置して、ノードの死をキャッチすることを期待することはありません。Sentinel でも同じことが予想されます。

センチネル監視への適切なルートは、理想的にはクライアントから実行することです。それが不可能または機能しない場合は、できるだけクライアントに近い専用ノードから実行します。

antirez が言ったように、選挙を行うには十分な歩哨が必要です。2 つの選択があります: 1: 新しいマスターを決定し、2: どのセンチネルが昇格を処理するかを決定します。あなたのシナリオでは、センチネルは 1 つしかありませんが、プロモーションを処理するセンチネルを選出するには、センチネルの定足数からの投票が必要です。この数は、見られたすべての歩哨の過半数です。あなたの場合、選挙が行われる前に、投票するために2人の歩哨が必要です。このクォーラム数は構成可能ではなく、クォーラム設定の影響を受けません。これは、複数のマスターの可能性を減らすために用意されています。

また、定足数をセンチネルの半分 + 1 未満に設定しないことを強くお勧めします。これにより、マスターが 2 つあるスプリット ブレイン操作が発生する可能性があります。または、あなたの場合、3つ持つことができます。マスターと 2 つのスレーブの間の接続が失われたが、クライアントがまだ接続を維持している場合、設定でスプリット ブレインがトリガーされる可能性があります。つまり、スレーブが昇格され、新しい接続がそのマスターと通信している間に、既存の接続が元の接続と通信し続けます。したがって、互いに競合する可能性のある 2 つのマスターに有効なデータがあります。

そのシマンテックの記事の著者は、ノードではなく、Redis デーモンの停止のみを考慮しています。したがって、実際には HA セットアップではありません。

于 2014-12-22T19:47:36.940 に答える