0

書き込みマスターと 2 つの読み取りレプリカを持つ AWS 上の Elasticache クラスターに対して Predis を実行しています。Predis は、大まかに次のようにマスター/スレーブ レプリケーション用に構成されます。

self::$client = new Predis\Client(
[
    'tcp://' . REDIS_MASTER  . '?alias=master',
    'tcp://' . REDIS_SLAVE01 . '?alias=slave-01',
    'tcp://' . REDIS_SLAVE02 . '?alias=slave-02'
],
['replication' => true]
);

現在、自動フェールオーバー リカバリを構成中です。Elasticache は、読み取りスレーブを昇格させ、マスター ノードのホスト名の dns レコードを更新することにより、マスター ノードの障害回復をサポートします。障害が発生した場合、マスターのホスト名は変更されないため、Predis は上記の構成で賢明ではないはずです。

ただし、上記の構成では、問題が発生します。人間が介入するまで (または何らかの英雄的なコードが作成されるまで)、3 ノード クラスターから 2 ノード クラスターに効果的に移行します。

私の主張を明確にするために..失敗する前に..

REDIS_MASTER -> node1
REDIS_SLAVE01 -> node2
REDIS_SLAVE01 -> node3

失敗後... (node1 が失敗し、node2 が昇格します)

REDIS_MASTER -> node2
REDIS_SLAVE01 -> node2
REDIS_SLAVE01 -> node3

これは限られた時間であれば問題ありませんが、理想的にはこれを解決したいと考えています。

復元が完了すると、elasticache は node1 を読み取りレプリカとして復元します。利用可能になり次第、リードレプリカとして機能を開始したいと考えています。

Predisを次のように構成することで、これを回避できると考えていました..

self::$client = new Predis\Client(
[
    'tcp://' . REDIS_MASTER  . '?alias=master',
    'tcp://' . REDIS_SLAVE01 . '?alias=slave-01',
    'tcp://' . REDIS_SLAVE02 . '?alias=slave-02',
    'tcp://' . REDIS_SLAVE03 . '?alias=slave-03'
],
['replication' => true]
);

...ここで、REDIS_SLAVE03 は REDIS_MASTER と同じ基礎となるインスタンスを指しますが、障害イベントで変更されないホスト名によって指します。事実上、すべてのノードは常に読み取りスレーブとして動作し、書き込みのマスターへの「ポインター」は Predis の知らないうちにシフトされます。

そこでいくつか質問...

1) スレーブが応答しなくなったときの Predis の動作は? その構成を無視し、読み取りを他の応答性の高いスレーブにルーティングしますか?

2) マスター redis インスタンスは読み取り操作の 2 倍になりますか? （おそらく答えはイエスです）

3) このアプローチには、私が見逃している欠陥がありますか?

4) より良いアイデアはありますか?

あらゆるアドバイスをいただければ幸いです。

4

1 に答える 1

0

この考え全体に欠陥があります。読み取りエンドポイントでレプリカを参照すると、aws が復旧プロセス中にこれらの名前の dns も更新するため、問題が解決します。

于 2015-07-16T16:35:08.723 に答える