Mongoレプリカセットでフェールオーバーが動作しないのはなぜですか？

Question

私たちの設定では、合計6つのMongodサーバがあります。そのうちの3つ（3.0.6）、新しいデータセンターから3つの新しいデータセンターを追加しました（v3.2.6）。これは、古いものから古いものへの使用を移行する良い方法であると考えていました。新しい。これらの新しい箱は数週間回転していて、最新の状態になっています。いずれのボックスも0以上のスレーブ遅延を持っていません。

1つの元のサーバーの優先度は2で、残りの5の優先度は1です。それ以外の場合、各サーバーの設定は同じです。投票目的のサーバーはありません。

私たちのアプリケーションは6つのアドレスをすべて使用しているため、自分でフェールオーバーします。

今日、私たちはすべてを考えていたと考えて、元の3つのサーバーでmongodプロセスを停止しました。

新しいボックスのどれもプライマリにならないでしょう。彼らはすべて二次的に残っていた。そこで元のプライマリに戻ってすぐに再びプライマリになりました。問題が優先されていると考えて、元のプライマリを1に減らし、新しいボックスの1つを2にしました。設定を保存し、新しいボックスがプライマリになりました。

私たちはそれを舐めたと思って、もう一度元のプライマリをシャットダウンします。

新しいボックスはすぐにセカンダリに戻り、プライマリは残されませんでした。

私たちは古いプライマリをバックアップし始めました。新しいボックスはすぐに再びプライマリになりました。

したがって、現在、古いボックスの優先度を0に設定して、実行したままにしておきます。

しかし、私たちはそのように走り続けることはできません。なぜ新しいマシンの1つがプライマリに自動的に昇格しなかったのですか？私たちが古い箱を取り除くと、なぜそれは降りるだろうか？

Answer 1

回答が簡単：6 - 3 = 3、これは4より小さく、クォーラムを構築する必要があります。 3台のサーバーを稼動させるだけで、残りの稼働メンバーはクォーラム（レプリカセット構成で定義されているサーバーの数を数えます）を構築することはできません。プライマリは確実に決定することができないので、セカンダリ状態に戻ります。これは、ネットワークパーティション化が行われている可能性があります。選挙を定足数以下で成功させることは、恐ろしいスプリット・ブレイン状況を可能にするでしょう。

これはpriority、btwとは関係ありません。 ちょうどあなたがしていることを知っていない限り、あなたはそれを試してはいけません。

しかし、あなたの問題は十分に簡単なはずの解決：

重要：すべての「新しい」メンバーがいずれかの二次または主要な状態になっていることを確認しに

1. 接続を進める前に、プライマリー。
2. 使用rs.remove()必要な場合は、新しいサーバプライマリのものを作るとに接続するためにrs.stepDown()を使用し、（それはあなたの説明から私には明確ではない）のレプリカセット構成
3. から停止して、古いメンバーを削除しますそれ
4. 使用再びrs.remove()レプリカから最後の「古い」メンバーを削除するにはあなたの中に残っているan odd number of voting membersで

を設定rレプリカセットでは、クォーラムとelect a new primaryを構築できます。