Mongoose: 切断後に再接続しないでください

+1、この問題に関連して過去5日間に2回の停止がありました。 現在の回避策は、 disconnectedイベントが発行されたときに、プロセスを明示的にクラッシュさせることです（ process.exit(0) ）。 その後、プロセスが再開され、接続が正常に再開されます。

私の推測では、mongooseは再接続を試みますが、 reconnectTries * reconnectInterval間隔内で失敗し、このリグレッションのためにerrorイベントは発行されません（https://github.com/Automattic/mongoose/pull / 4653）。 私が知らないのは、なぜマングース/モンゴがランダムに切断されるのかということです。以前はこのような動作はありませんでした。
どのモンゴホスティングを実行していますか？ mLab？

AWSでホストしています。 残念ながら、 process.exit(0)は私たちの選択肢ではありません。

＃4653で変更を適用し、同じ動作をしました。 数時間後の切断：

2016-10-27T11:26:42 pid:5276 MONGODB sync_reports_db connected successfully.
2016-10-27T11:26:42 pid:5276 MONGODB sync_reports_db opened successfully.
.... 2 hours later
2016-10-27T13:45:45 pid:5276 MONGODB sync_reports_db disconnected
2016-10-27T13:45:45 pid:5276 MONGODB CLOSE sync_reports_db

errorイベントは発行されませんか？ （ disconnectedから30秒後のはずです）

いいえ、問題の説明にあるコードをご覧ください。 私が何か間違ったことをしていない限り、 errorイベント用のイベントハンドラーがあります。 実際、プロセスはまだ実行中であり、マングースは他のイベントをトリガーしていません。

4.6.5以降、ここ数日同じ問題が発生しています。ランダムに切断されると、ノードプロセスがスタックします。 ただし、 errorイベントはありません。 4.5.3戻すと機能します。

@lorisはこれが4.6.6 https://github.com/Automattic/mongoose/commit/f7ebee0c992c45cdb27ba7f0675556b980cddaadに関連してい

@mckはい、 https：//github.com/Automattic/mongoose/commit/f7ebee0c992c45cdb27ba7f0675556b980cddaadは、mongodb接続の再試行メカニズムが失敗したときにerrorイベントが発行されない問題を修正しました。 しかし、そもそもなぜランダムな切断が発生しているのかわかりません。@ vkarpov15というアイデアはありますか？

fwiw、保存/更新操作（約650kbの書き込み）を実行しようとすると、40〜50％の確率で発生しました

ええ、私は本当に多くの良いアイデアを持っていません。 接続でclose()を呼び出してから、もう一度自分でconnect()呼び出すことができます。 @loris大量の保存/更新がこれを引き起こしているように見える、同様の経験がありますか？

私たちもこれに直面しています。 サービスの1つで、エラーイベント（ds0XXXXX-a0.mongolab.com:XXXXXへの接続Nがタイムアウト）が発生し、その後に切断イベントが発生します。 そして、接続が再確立されることはありません。 別のサービスでは、DBに対する大量の要求、つまり2Mレコードの削除後に、切断イベントが発生します。 そして、再接続できません（mongoose 4.6.6、DBバージョン3.0.12）。

数分前に、mLabでもmongodbを実行していることが再び発生しました（これが関連しているかどうかはわかりません）。 重いクエリを実行しましたが、タイムアウトしました（ unhandledRejection { MongoError: connection 0 to ds****-a0.mongolab.com:**** timed out } 、 disconnectedイベントは適切に発行されましたが、その後は何もありません、 error 、 reconnectedなどはありません。したがって、このWebサーバーはHTTPリクエストを実行および受信し続けましたが、バッファリングされて返されないマングースクエリを実行し続けたため、再起動するまですべてタイムアウトしました。

マングースのセットアップ（ノード7.0.0では4.6.5）：

const mongoConnectOpts = { reconnectTries: 10, reconnectInterval: 500, socketOptions: { keepAlive: 300000, connectTimeoutMS: 30000 } };
mongoose.connect(process.env.MONGODB_URI, { server: mongoConnectOpts, replset: mongoConnectOpts });
mongoose.connection.on('error', err => {
  console.log({ event: 'mongoose:error', ...err });
  process.exit(0);
});
mongoose.connection.on('connected', () => console.log({ event: 'mongoose:connected' }));
mongoose.connection.on('disconnected', () => console.log({ event: 'mongoose:disconnected' }));
mongoose.connection.on('reconnected', () => console.log({ event: 'mongoose:reconnected' }));

一時的な回避策は、 disconnectedイベントでもprocess.exit(0)実行して、Webサーバーを強制的に再起動して新しいmongodb接続をセットアップすることです。 何か案は？

ええ、私は以前にmlabでこの種のことが起こっていると聞いたことがあります。 この場合、TBHはサーバーをクラッシュさせて再起動するだけで、本当に遅いむらのあるネットワークはmongodbドライバーに問題を引き起こす傾向があり、これをデバッグするにはmlabとの調整が必要になると思います。

現在何が問題なのか（mongoose、mongo driver、mlab、heroku）はわかりませんが、過去数日間、重いmongooseクエリを実行するWebリクエストを実行すると（応答に30秒以上かかる）、herokuリクエストがトリガーされますタイムアウト（これは、30秒以上かかるWebリクエストをタイムアウトするherokuのメカニズムです）。 そのWebリクエストがタイムアウトになると、マングースクエリを必要とするそのサーバー上の後続のWebリクエストもタイムアウトします。 実際の問題は、ZEROイベントがマングースによってトリガーされることです（ error 、 close 、 disconnectedなどはありません...）。そのため、を検出する方法がありません。サーバーを切断して再起動します。 マングースの設定方法は次のとおりです。

mongoose.Promise = global.Promise;
mongoose.set('debug', process.env.NODE_ENV === 'development');
const mongoConnectOpts = { reconnectTries: 10, reconnectInterval: 500, socketOptions: { keepAlive: 300000, connectTimeoutMS: 30000 } };
mongoose.connect(process.env.MONGODB_URI, { server: mongoConnectOpts, replset: mongoConnectOpts });
mongoose.connection.on('error', err => {
  logfmt.log({ event: 'mongoose:error', ...err });
  process.exit(0);
});
mongoose.connection.on('connected', () => logfmt.log({ event: 'mongoose:connected', uri: _.truncate(process.env.MONGODB_URI) }));
mongoose.connection.on('disconnected', () => {
  logfmt.log({ event: 'mongoose:disconnected' });
  process.exit(0);
});
mongoose.connection.on('close', () => logfmt.log({ event: 'mongoose:close' }));
mongoose.connection.on('reconnected', () => logfmt.log({ event: 'mongoose:reconnected' }));

// Setup Redis cache (Default cache TTL: 60 seconds)
cachegoose(mongoose, { engine: 'redis', client: redisCache }, process.env.NODE_ENV === 'development');

@Iorisは、

@ vkarpov15これをチェックしようとしますが、バグは本番環境を実行する余裕がないため、簡単ではありません。
@aartiles @ mck- @lushchick皆さんはマングースキャッシュプラグインを使用していますか？

これはhttps://github.com/christkv/mongodb-core/issues/148に関連している可能性があり

マングースキャッシュプラグインは使用していません。

私はまだそれを調査しています、私がこれまでにあなたに言うことができること：

• ローカルマシンで問題を再現することができました。毎秒高速クエリを実行して結果をログに記録するループを開始し、少し遅れて、重いクエリを実行します（100万行のコレクションに対するインデックスなしのクエリなど）。 すべてのクエリ（高速クエリも）はロック/タイムアウトされ、mongooseイベントは発生しません。
• この問題は4.6.5に表示され、 4.6.4 4.6.5にダウングレードすると、問題が修正されます（重いクエリの実行中も高速クエリが実行されます）
• それは何の関係もないようです：
  
  
  
  • マングースキャッシュプラグイン
  
  
  • レプリカセットを実行しているかどうか
  
  

私はさらに掘り下げましたが、問題は[email protected]へのアップグレードにあり、バグのあるコミットはhttps://github.com/mongodb/node-mongodb-native/pull/1418にあり
タイプミスを修正したようですが、そのeventName（タイプミスあり）は一部の担当者によって使用されています

@loris間違ったイベント名を持つ残りの参照がどこにあるか知っていますか？ PRを作成して修正することはできますが、見つかりません。

@jakesjewsも参照を見つけることができないので、私のマシンで不一致のバージョンをチェックアウトした可能性がある原因について間違っている可能性があります。

同様の問題があります：切断後の再接続の失敗。 これは、mongoose db操作をハングアップすることでクライアントに現れます（操作バッファリングを介してタイムアウトします）。

@jakesjews私の問題はレプリカセットにも固有であり、単一ノード接続では発生しません。 コアreplset.jsを詳しく調べます。

node-mongodb-native内でデバッグログを有効にして、HA再接続が期待どおりに機能しているかどうかを確認しました。

attemptReconnect for replset with id successful resuming topologyMonitor 1

それは時に単一のノード非replsetの再接続を行うように、それが正常にattemptReconnectを行っ主張ノードMongoDBのネイティブドライバにもかかわらず、マングースは、接続または再接続イベントを発することはありません。

@lorisが述べたように、この問題はレプリカセットへの再接続に直接関連しているため、process.exit（0）->サービスの再起動は機能しますが（私の場合）、これも理想的ではありません。

マングース@ 4.6.8
[email protected]

@ mck-あなたと同じで、 4.5.3に

レプリカセットの再接続の問題が初めて発生する4.6.0で失敗し始める前に、4.5.10までアップグレードできます。 現在の推測では、mongodbドライバー2.2.9へのアップグレードに関連している可能性があります。

@lorisテストケースを提供して、試してみることができますか？

私はまだそれを見ています、私は以前にタイプミス修正コミットについて間違っていました。 犯人はhttps://github.com/christkv/mongodb-core/pull/146/commits/09caa9d1e5423acd2f8f154f7b7430028e77e57fのようです
テストケースの提供は、次のようにしか行われないため、少し複雑です。

• mongoose 4.6.8 、デフォルト設定でローカルホストmongodb（3.2）に接続
• 2つの高速ルート。1つは長時間実行のマングースクエリ（数秒）を実行し、もう1つは高速実行のマングースクエリを実行します（たとえば、setInterval / setTimeoutテストケースを使用して、ノードで直接マングースクエリを実行する場合は問題は発生しません。だから私の推測では、それはプール接続がどのように処理されるかに関連していると思います）
• 長時間の高速ルートを実行してから、高速の高速ルートをヒットしようとすると、高速の高速ルートは戻らずに実行を続けます
• poolSizeをデフォルトではなく50に設定して、問題を修正します
• mongodb-coreから前のコミットをチェックアウトすると、問題も修正されます（高速実行の高速ルートは、長時間実行ルートの処理中に数ミリ秒で戻ります）（デフォルトのプールサイズで）
• したがって、 https：//github.com/christkv/mongodb-core/pull/146/commits/09caa9d1e5423acd2f8f154f7b7430028e77e57fは、単一の長時間実行マングースがプール内の利用可能なすべての接続を使用する方法に何かを変えたと思います

この修正は、ちょうどこの問題を解決するかもしれませんMongoのコアに上陸しました。

@lorisええプールサイズを増やすと役に立ちます。 mongodbサーバーがpoolSize超えるリクエストを同時に処理できないという低速列車の問題が発生しているようです。 プールサイズを増やすと役立ちます。あまり大きくしないでください。そうしないと、WiredTigerでパフォーマンスの問題が発生し始めます。

やあ、
これに関する更新はありますか？ 同じ問題が発生しています。レプリカセットを使用すると、auto_reconnectが機能しません。 mongodb2.2.11でmongoose4.7.0を試しましたが、まだ再接続していません。 私はmongodバージョン3.2.10を使用しています。

私はすべてを単一のホスト（ラップトップ）で実行しており、mongodの3つのインスタンスが異なるデータベースディレクトリの異なるポートで実行されています。 それが問題になるはずではないようですが、私はmongo / mongoose / node / javascriptを初めて使用します。 マングースを使用したノードアプリも同じホストで実行されています。

すべてのmongodプロセスをシャットダウンするだけでこれを再現できます
（launchctl stop mongod01; launchctl stop mongod02; launchctl stop mongod03）
接続が閉じられたというメッセージを待ってから再起動します（launchctlコマンドの「stop」を「start」に置き換えます）。 私のアプリはmongoに再接続しません。

レプリカセットとして構成されていないmongodの単一インスタンスで同じテストを実行すると、mongooseは正常に再接続します。

ログを提供するか、それが役立つ場合はパッチを試してみてください。

いくつか掘り下げた後、私は問題の1つの原因を見つけたかもしれないと思います。 autoreconnectがtrueの場合、接続バッファがアクティブになることは想定されていないようですhttps://github.com/Automattic/mongoose/blob/master/lib/drivers/node-mongodb-native/connection.js#L153接続時にイベントを閉じます。 ただし、mongodb-native https://github.com/mongodb/node-mongodb-native/blob/2.2/lib/replset.jsのreplsetクラス内にautoReconnectプロパティが設定されていないため、1つのノードからのすべてのクローズイベントバッファが永続的に有効になります。 コミットhttps://github.com/eflexsystems/mongoose/commit/5ac12727f34b41791f94643b66c8cc88aff4d66aで運が良かったのですが、プルリクエストを行う前に、他の問題が発生したかどうかを確認するためにもう少し時間をかけたいと思います。

@joeldodsonあなたは私が経験したのと同じ問題を説明しています。 4.6.0以上のヘッズアップリリースに問題が含まれているようです。 その間、4.5.10を試してみますが、それはreplsetに再接続されており、単一の接続で問題ありません。

@jakesjewsと@ kog13に感謝します

4.5.10を試しましたが、レプリカセットを再起動した後、mongooseが再接続します。 ただし、レプリカセット内のすべてのインスタンスが停止した後、db.readyStateがクリアされていないようです。 リクエストを拒否するかどうかを判断するためにそれをチェックしています（アプリがDBに再接続するのを待ってキューに入れないようにします）。 また、4.5.10では切断または接続が閉じられたという通知が届きませんでした。

アプリの起動時にDBが利用できない場合に接続を試みるために、5秒のタイマーでループに入るロジックがすでにあります。 db.on（ 'closed'、function（）{...}）ハンドラーでそれを呼び出してみましたが、正常に機能しているようです。 しかし、私の懸念は、明示的に接続しようとすると、内部の再接続ロジックと競合するかどうかです。 レプリカセットでは再接続が行われていないようですので、大丈夫だと思います。 また、サーバーとreplsetの両方の接続オプションでauto_reconnectをfalseに設定します。

@ jakesjews-上記のパッチを試しましたが、再接続できませんでした。 何かを見逃したかもしれませんが、そのパッチは、closeイベントが生成され、readyStateが更新されるようにすることに関するもののようでした。

誰かが持っているなら、auto_reconnectのパッチをこれ以上試してみてうれしいです。 私も掘り下げていきます。

ありがとう。

上記のパッチに加えて、 @ joeldodsonは、レプリカセットモニター接続が存続することを確認するための修正が含まれているmongo-coreの最新リリースに依存する必要があります。 あなたが私のフォークを試してみるなら、それはすでにそれを持っているはずです。

マングースでのタイムアウトとフェイルオーバーに関しては、かなり良い場所にいると思います。 他の誰かがそれを試してみたい場合は、socketOptionsでsocketTimeoutを0に設定することに加えて、私のマングースのフォークを使用することをお勧めします。

socketTimeoutを0に設定する理由は、mongo-coreにバグがあり、それでも問題を報告する必要があるためです。 この問題は、接続プールが動的に縮小/拡大することが原因で発生します。 プールが機能する方法は、新しい接続を追加するたびに、その接続が30秒間非アクティブになると閉じることです。 タイムアウトイベントは、プールからの削除をトリガーし、タイムアウトの数を30回の接続試行の制限と比較するチェックも実行します。 2秒ごとに実行され、タイムアウトの数をクリアするハートビートがありますが、30以上のリクエストが並行してキューに入れられると、ハートビートの間にすべてのリクエストがタイムアウトし、接続プールが破壊されます。 今のところ、接続のタイムアウトを0に設定すると、接続が非アクティブの場合にプールに戻されるのを防ぎ、問題を回避します。 問題を再現する場合は、接続プールのサイズを約50に設定し、50の並列クエリを実行してみてください。 その後、プールは約30秒で破壊されます。 タイムアウトには独自のタイムアウトがあるため、タイムアウトはレプリカセットをチェックするハートビートに影響を与えないことに注意してください。

私は最近仕事に忙殺されているので、これらすべての変更をまとめる機会はありませんでしたが、すぐにそれを手に入れたいと思っています。

もう一度@jakesjewsに感謝します。 私はあなたのマングースとmongodb-coreリポジトリを引き込みました。 再接続は機能しました。 Mongoの単一インスタンスを使用した場合に発生しますが、「connected」イベントと「reconnected」イベントは取得されませんでした。 また、readyStateはリセットされていないようで、再接続後も0のままです。

ログのテストや収集をお手伝いできてうれしいです。

まだ[email protected]

この問題に関して何か新しいことはありますか？

ここでも問題を体験します。 接続の問題のため、マングースバージョンのアップグレードを元に戻す必要がありました。 現在、数秒かかるクエリは接続をタイムアウトしますが、以前はそうではありませんでした。

この問題に対処する必要があります。そうしないと、パッケージを使用できません。
時間があれば、おそらく@jakesjewsソリューションを試して

問題がmongo-coreのバグである場合、これは実際にはmongooseの問題ではありません。 最新バージョンのマングースで問題が発生した場合、 mongodb-coreリポジトリで問題を報告できますか？

問題のあるmongodb-coreのバージョンに依存するように更新されているため、実際にはmongooseの問題です。 たぶんmongooseは以前のバージョンのmongodb-core復元する必要があります。

ことを見て@jakesjews [email protected]が依存する[email protected]順次に依存し、 [email protected]あなたからの修正を適用し、フォークは、この問題を修正するために必要とされるすべてのだろう一見副作用はありませんか？

そしてあなたのフォークを見ると、このコミットは4.7.xおよび/または4.8.x PRに必要な唯一の変更ですか？

@Koslunフォークは

これが私のソケットオプションが今どのように見えるかです。

    var opts = {
      server: {
        socketOptions: {
          keepAlive: 1,
          socketTimeout: 0
        }
      },
      replSet: {
        socketOptions: {
          keepAlive: 1,
          socketTimeout: 0
        }
    }

@jakesjewsわかりました、迅速な説明に感謝します:)。

このバグの修正が表示されるmongodb-coreのバージョンを知っていますか？ または、追跡できる問題、PR、またはコミットがありますか？

@Koslunコメントに関する更新は

この問題の更新はありますか？

この問題は2016年からまだ開いています：open_mouth：

この問題は、mongodbドライバー3.3.4を搭載したmongoose 5.xとバージョン4.xのMongoDBサーバーでも発生する可能性があるのでしょうか？ ：考え：

再接続が成功したときにreconnectTriesがリセットされるかどうか、誰か知っていますか。

Foxインスタンス、reconnectTriesが30に設定されている場合、切断されたマングースは5回試行し、接続は成功します。
次回接続が失われたとき、再試行のカウンターは何になりますか？
30回再接続を試みますか？
または25回？

@ szabolcs-szilagyiはい。ただし、 useUnifiedTopologyをtrue設定しない場合に限ります。

@ bhaveshvyas007はいそうです。 関連するコードは次のとおりです

後世のために：

useUnifiedTopologyなしでMongoose 5.xを実行している場合は、 MongoDB接続を管理するためのこのガイドをお読み

useUnifiedTopologyでMongoose 5.xを実行している場合、この問題は影響しません。