0

mongodbノードの大半がプライマリデータセンターにあるmongoレプリカセットをシームレスにフェールオーバーする方法があるかどうかを確認しようとしています。私の現在の制限は2つのデータセンターで、第3のデータセンターは問題外です。私が持っている問題は、データセンター1がダウンした場合、データセンター2のセカンダリノードは手動介入なしにプライマリに昇格しないということです。2つのデータセンターでのMongodbアーキテクチャとフェールオーバー

データセンター1(プライマリ): Mongoのノード(プライマリ) Mongoのノード(アービタ)

データセンター2(セカンダリ):私はMongoDBのを見てきました Mongoのノード(セカンダリ)

dc1が失われた場合、dc2プライマリにmongodbインスタンスを作成するためには、手動の介入が必要です。

私の質問は、データセンター1を失う可能性があり、手動での介入や再設定なしで書き込みを有効にしてデータセンター2引き継ぎを実行できるようにするためのアーキテクチャまたは構成があるかどうかです。これは、3つのデータセンターアーキテクチャのパスを下げることなく可能ですか?各サイトの2つの3つのレプリカセットを同期させ、接続するアプリケーションのネットワークレベルでフェールオーバーを実行することは可能ですか?

ありがとうございました。

答えて

2

あなたが私に2つのデータセンターを持って行くのが最も簡単な解決策は、プライマリでのみ失敗することです。良いニュースは、スレーブが死んでいる場合です - あなたは待つ必要があります。

プライマリへのアクセスが失敗した場合、スレーブをプライマリに強制するコールバックプロシージャが必要です。このスイッチは、クエリをバッファしてスイッチからのコールバックを待つゲートウェイを作成するために時間を費やさなければ、アプリケーションのダウンタイムを引き起こします。このようにして、タイムアウトを増やして遅くするだけです。

プライマリが再びライブになった後で、スレーブノードが信頼できないため、再び接続する必要があります。これによりダウンタイムが再び発生します。プライマリが生きているか(データセンター2から)それはトリガーイベントであり、コールバックを続行します。

スレーブをプライマリにする手動の介入をスクリプトにラップすることができます。

ここで私にとって最善の解決策は、アービターが滞在する第3のデータセンターに行くことです。それをスキップしてアプリケーションロジックを置く努力は価値がありません。 Mongoの自動フェールオーバーは非常にうまく動作し、信頼性が高い。アプリケーションロジックを2つのデータセンターで実現するには、多くの問題を抱えているかもしれません...私はむしろ推奨事項に従います。

1

最初に気づいたように、2つのノードで自動フェールオーバーを行うことはできません。第二に、 "3番目の"データセンターだと思うと、お金は本当の問題ではありません。あなたはなぜ、または「どのように」尋ねることができますか? ご存知のとおり、アービタが必要です。アービタは本当にリソースを必要としません。小さなLinuxマシンはうまくいくでしょう。小型のVPSマシンはそれほどコストがかかりません。 Here you can find machine 1 x 2.40 GHz, 512 MB, 20 GBは月額わずか1,24ユーロです。 From here you get beefier machine with 1.99€/month.

実際には、これらの場所は両方とも、これらの「小型の」マシンでかなり大きなモンゴーを実行する可能性があります。

関連する問題