問題タブ [replicaset]

レプリカ セットの 1 つのメンバーとして機能する Docker コンテナーがあります。これらのうちの 3 つを正常に起動し、それらをレプリカ セットとして接続するためにそれらの内部でいくつかのシェル スクリプトを実行することができました。ホストマシンから各メンバーに個別に接続できることがわかりましたが、boot2docker IP で各メンバーをリストすることにより (私の場合は spring-data-mongodb を介して) レプリカセットに接続しようとすると、それぞれのポートで、どこかでアプリケーションが各コンテナー IP の boot2docker IP を交換し、その IP に直接接続しようとしていることがわかりました。

これは、最初の接続文字列が単なるシード リストであり、実際の構成がメンバー自身との通信によって提供されるために発生すると想定しています。もちろん、これらの IP はホスト マシン (アプリが実行されている場所) には存在せず、boot2docker VM 内にのみ存在するため、これは問題です。メンバーが個々の到達不能 IP ではなく boot2docker IP を報告するようにするにはどうすればよいですか?

私はelasticsearchで似たようなものに出くわし、network.publish_host変数を設定することで修正できました。mongodb にも同様の設定はありますか? おそらく bind_ip が正しいと思いましたが、それを機能させることができませんでした。間違って使用していますか? boot2docker IP に設定していたのですが、起動時にバインド エラーが発生しました。

また、ubuntu とネイティブ docker を実行している友人は問題なく接続できるため、これは boot2docker がミックスに投入された場合の問題にすぎないことを確認できます。

bind_ip を boot2docker vm に設定しようとしたときに表示されるエラーは次のとおりです。

私のSpring xmlの接続文字列は次のとおりです。

アプリで表示されるエラーは次のとおりです（bind_ipなどを変更せずに開始した場合）

これらの IP は各コンテナーの IP であり、実際には各コンテナーはポート 27017 で起動しますが、boot2docker VM でそれらのポートを 27017、27018、および 27019 として公開します。

ホストされた MEAN スタック アプリケーションでは、ホスティング会社のテクニカル サポートから報告されたように、MongoDB レプリカ セットで次のことが発生しました。

新しい予備選挙が簡単に選出される 3 分間のウィンドウがありました。ネットワークの問題により、プライマリがセカンダリへの接続を失ったようです。時間枠はわずか 3 分で、予備選挙は通常どおり再選されました。

すべてが正常に戻った後、Mongoose フレームワークを使用する Node.js アプリケーションがプライマリへの接続を再確立せず、「セカンダリに書き込めません」というエラーがログに記録されました。

質問: Mongoose および/またはそれが使用する MongoDB ドライバーを使用する場合、プライマリが元に戻った後の自動再接続を妨げる可能性のある設定は何ですか? （つまり、これが再び起こらないようにするにはどうすればよいですか？）

Mongoose v3.8.26 の使用

mongodb レプリカ セットをデプロイしようとしています。mongodb インスタンスをレプリカのプライマリにしました。今、レプリカのセカンダリとして、別の IP アドレスでホストされている別の mongodb インスタンスを追加しようとしていますが、次のエラーが発生しています:

私が間違っていることは何ですか？

mongodbをインストールした後、私mongodは

次に、mongoシェルに接続して実行しました

次に、ドキュメントをコレクションに挿入しようとしましたが、エラーが発生しました:

を見るとrs.status()、ステータスはREMOVED次のとおりです。

これを台無しにするために何ができたのかわかりません。これはうまくいったはずです。どうすればこれを乗り越えることができますか?

私は mongodb の専門家ではないので、現在のサーバーのセットアップについて少し確信が持てません。

私は、単一のインスタンスで mongo3.0.2 を wiretiger で実行しており、読み取り操作と書き込み操作の両方を受け入れています。クライアントからログを収集するので、書き込み負荷はそこそこあります。1 日に 1 回、このログを処理し、集計フレームワークを使用していくつかのメトリックを計算したいのですが、処理するデータ セットは先月のすべてのログのようなもので、すべての計算に約 5 ～ 6 時間かかります。コレクションのロックを回避するために、書き込みと読み取りを分割することを考えています (サーバーは読み取り中にログを書き込み続けます。新しく書き込まれたログはクエリと一致する可能性がありますが、100% の精度は必要ないためスキップできます) ）。

つまり、レプリケーションが継続的に実行されていないが、すべての読み取り操作が開始される前に、構成された時間またはそれ以上に開始される読み取り用のセカンダリを使用してセットアップを行いたいです。

私はnode.jsからすべての処理を行っているので、ここに表示される1つのオプションは、[昨日、今日]のようなある期間に作成されたデータをエクスポートし、それをインポートして自分でインスタンスを読み取り、インポートが完了した後に計算することです. 可能なセットアップとしてレプリカ セットとマスター/スレーブ レプリケーションを検討していましたが、説明されているシナリオを実現するための構成方法がわかりませんでした。だから多分私は間違っていて、ここで何かを見逃していますか？これを達成するための他のオプションはありますか？

タイトルのとおり、1 つのプライマリ、1 つのセカンダリ、1 つのアービターを含むレプリカセットがあり、プライマリに大きな DB を復元しました。これはセカンダリよりもはるかに高速なインスタンスです。現在、セカンダリは大幅に (時間) 遅れており、数時間前から回復状態にあります。何かできることはありますか？復旧の進捗状況を知ることはできますか?

サーバー 1 のプライマリ + アービター、サーバー 2 のセカンダリ + アービター、サーバー 3 の非表示のセカンダリ (バックアップ ノード) の 5 つのメンバーで構成されるレプリカ セットがあります。この構成は、1 つのサーバーがダウンしたり、接続が一時的に失われたりした場合に機能することを期待しています。

しかし、サーバー 2 (セカンダリ ノードとアービター ノードを備えたサーバー) がダウンしたとき、私は奇妙な問題に遭遇しました。PHP からレプリカ セットへの接続に 1 分以上かかっていました。接続文字列を変更して、ダウンしているサーバー (セカンダリ ノード) を除外しようとしましたが、役に立ちませんでした。

同時に、mongo コンソール経由での接続は問題なく機能しました。プライマリ ノードはプライマリのままでした。PHP エラー ログにはエラーが含まれていませんでした。

役に立った唯一のことは、レプリカ セットからダウンしたサーバー上のノードを削除することでした。

しかし、今は構成のフェイルオーバーが心配です。今気づいたように、セカンダリ ノードとアービター ノードを備えたサーバーがダウンすると、構成全体が適切に機能しなくなります。それを回避する方法はありますか？セカンダリ + アービター サーバーが使用可能かどうかに関係なく、PHP クライアントがプライマリに接続できるようにする必要があります。それを達成する方法は？

mongo PHP クライアント ライブラリのバージョンは 1.6.x、サーバーのバージョンは 3.0 です。

2 つのレプリカ セットを使用してシャード mongodb セットアップを取得しました。

ノード 10.133.250.140 がダウンしたので、別のものに置き換えました (IP アドレスが変更されました)。レプリカ セットの再構成は非常に簡単で、rs.remove() と rs.add() だけでした。次に、シャード rs01 のホスト構成を更新する必要があります。それを行う適切な方法は何ですか？

RF=3 のレプリカ セットで MongoDB を使用しています。ドキュメントには「ha」というイベントがあり、更新操作への影響は非常に大きいことがわかります。

私が見る限り、このイベントは mongodb-core からのものです。しかし、このイベントの意味は何ですか？レプリカ セットの接続は N 秒ごとに失われ、復元されますか?