Mongoose: 使用可能なプライマリサーバーがありません

現時点では何も飛び出していません。 どのmongodbサーバーもクラッシュしていませんか？ また、シェルを使用して安定した接続を維持できますか？

エラーの発生中にコマンドdb.runCommand( { replSetGetStatus : 1 } )を実行すると、3つのノードすべてで"health" : 1,れます。 ノードの1つにプライマリセット"stateStr" : "PRIMARY",もあります。

DNSを使用して、同じ接続文字列を使用して接続していますか？ また、問題が発生した後、ストレージがフラットラインになっているように見えますが、いずれかのマシンのハードドライブ容量が不足していないかどうかを再確認できますか？

DNSを使用して、同じ接続文字列を使用して接続していますか？

同じ接続文字列を使用していませんでした。 プライベートEC2IPアドレスを使用するとこれが解決すると思いますか？

そのようにストレージが最大になる原因はわかりませんが、新しいインスタンスを起動した後でも、十分な空き容量があるため、プライマリサーバーがないという問題が発生します。

レプリカセットの設定方法によっては、EC2IPアドレスが役立つ場合があります。 シェルからのrs.status()の

これは、接続が増加している間のrs.status（）です。

{
    "set" : "mongo2",
    "date" : ISODate("2015-12-04T23:39:32.520Z"),
    "myState" : 1,
    "members" : [
        {
            "_id" : 6,
            "name" : "mongo-8.loc.0600.mongodbdns.com:27000",
            "health" : 1,
            "state" : 2,
            "stateStr" : "SECONDARY",
            "uptime" : 444053,
            "optime" : Timestamp(1449272372, 32),
            "optimeDate" : ISODate("2015-12-04T23:39:32Z"),
            "lastHeartbeat" : ISODate("2015-12-04T23:39:32.507Z"),
            "lastHeartbeatRecv" : ISODate("2015-12-04T23:39:31.442Z"),
            "pingMs" : 0,
            "syncingTo" : "mongo-9.loc.0600.mongodbdns.com:27000",
            "configVersion" : 29
        },
        {
            "_id" : 7,
            "name" : "mongo-9.loc.0600.mongodbdns.com:27000",
            "health" : 1,
            "state" : 1,
            "stateStr" : "PRIMARY",
            "uptime" : 444056,
            "optime" : Timestamp(1449272372, 39),
            "optimeDate" : ISODate("2015-12-04T23:39:32Z"),
            "electionTime" : Timestamp(1449097485, 1),
            "electionDate" : ISODate("2015-12-02T23:04:45Z"),
            "configVersion" : 29,
            "self" : true
        },
        {
            "_id" : 8,
            "name" : "mongo-10.loc.0600.mongodbdns.com:27000",
            "health" : 1,
            "state" : 2,
            "stateStr" : "SECONDARY",
            "uptime" : 444053,
            "optime" : Timestamp(1449272371, 111),
            "optimeDate" : ISODate("2015-12-04T23:39:31Z"),
            "lastHeartbeat" : ISODate("2015-12-04T23:39:31.904Z"),
            "lastHeartbeatRecv" : ISODate("2015-12-04T23:39:30.903Z"),
            "pingMs" : 2,
            "syncingTo" : "mongo-8.loc.0600.mongodbdns.com:27000",
            "configVersion" : 29
        }
    ],
    "ok" : 1
}

レプリカセットで異常なことは何もありません。 他に関連するコードサンプルはありますか？たとえば、マングース接続イベントに反応するコードはありますか？

検討する価値のあるもう1つの潜在的な問題ですが、最新の新しいRelicエージェントを使用していますか？ 新しいレリックなしで実行してみて、これがまだ発生するかどうかを確認します。新しいレリックモンキーパッチがmongodbドライバーにパッチを適用するため、予期しない動作が発生する場合があります。

マングース接続イベントを出力しています。

['connecting', 'connected', 'open', 'disconnecting', 'disconnected', 'close', 'reconnected', 'error', 'fullsetup'].forEach(function(name) {
  mongoose.connection.on(name, function() {
    notifySlack('Mongoose event: ' + name);
  });
});

これはいくつかのログがどのように見えるかです

​[4:30] Mongoose event: fullsetup
​[4:30] Mongoose event: reconnected
​[4:30] Mongoose event: open
​[4:30] Mongoose event: connected
​[4:30] Mongoose event: reconnected
​[4:30] Mongoose event: reconnected
​[4:30] Mongoose event: reconnected
​[4:30] Mongoose event: reconnected
​[4:30] Mongoose event: reconnected
​[4:30] Mongoose event: reconnected
​[4:30] Mongoose event: fullsetup
​[4:30] Mongoose event: connected
​[4:30] Mongoose event: open
​[4:30] 
{
 "err": {
   "name": "MongoError",
   "message": "no primary server available"
 }
}

私は今週のmongodbdaysイベントに参加しました。そこでは、時間をスケジュールして、この問題をMongoDBの上級エンジニアの1人に見せることができましたが、彼らは問題が何であるかを確信していませんでした。 彼らは、レプリケーションセットと最大プールサイズを接続文字列に追加することに言及しましたが、残念ながらこの問題は解決されていません。

また、キープアライブを無効にして、インスタンスで小さい値に設定しようとしましたが、これも解決されなかったようです。

newrelicバージョン1.24.0とmongo-express-patchバージョン0.21.1ます。 newrelicなしで実行して、これが解決するかどうかを確認します。

うーん、マングースが何らかの理由で再接続しているように見えます。 npm list | grep "mongoose"とnpm list | grep "mongo"の出力を見せていただけますか？

$ npm list | grep "mongoose"
├─┬ [email protected]

$ npm list | grep "mongo"
├─┬ [email protected]
│ ├─┬ [email protected]
│ │ ├─┬ [email protected]
├─┬ [email protected]
├─┬ [email protected]
│ ├─┬ [email protected]
│ │ ├── [email protected]

mongodb-coreを何に使用していますか？ また、prodでmongo-express有効にして実行していますか？

現在、 mongodb-coreは何にも使用していません。 マングースの依存関係間のバージョンの不一致が問題を引き起こしていると思いますか？

実稼働環境ではmongo-express有効になっています。

私が知っていることではありません。 この問題の原因となっている可能性のあるmongodbへの他の接続があるかどうかを確認しようとしています。 私は少しグーグルをしました-接続文字列にrs.status()表示されるものと同じDNS名を使用していますか？ これによると、レプリカセットが想定しているものとは異なるDNSを接続文字列に使用すると、同様の問題が発生する可能性があります。

このエラーは、接続文字列でrs.status()の「syncingTo」属性と同じDNSを使用している場合に発生します。 また、接続文字列で内部ec2IPを使用している場合にも発生します。

私がまだ試したことがないのは、 connectWithNoPrimaryをtrue設定することだけです。

また、 mongo-expressオフにして実行してみます。 それが問題を引き起こしている可能性があります...

同じ問題が発生しています。 約100RPMの持続的な負荷が発生し、500〜700 rpm +にピークがあるサイトがあります。 これは、比較的かなりの期間でも、プロセス全体で見られるようです。

環境：
Heroku-75 2x dynos-Node.JS 5.1.1
データベース-MongoLabs専用クラスターM4-バージョン3.0.7

接続文字列：
mongodb：// _： * _ @ ds043294-a0.mongolab。 com：43294 、ds043294-a1.mongolab。 com：43294 / heroku_hf8q79dt？replicaSet = rs-ds043294

NPM：

npm list | grep "mongoose"
├─┬ [email protected]
├── [email protected]
├── [email protected]
├─┬ [email protected]

Connection.js

// Mongoose import
var mongoose = require('mongoose');
var options = {
    server: {
        socketOptions: {
            keepAlive: 1,
            poolSize: 10,
            connectTimeoutMS: 30000,
            socketTimeoutMS: 30000
        }
    },
    replset: {
        socketOptions: {
            keepAlive: 1,
            poolSize: 10,
            connectTimeoutMS: 30000,
            socketTimeoutMS: 30000
        }
    }
};

mongoose.connect((process.env.MONGOLAB_URI || "mongodb://localhost/test"), options, function(error) {
    if (error) {
        console.log(error);
    }
});

module.exports = {
    mongoose: mongoose
};

ロギング：
これを試してデバッグするためにかなりの量の監視を有効にしたので、これがデバッグに役立つ場合でも、Raygunスタックトレースを含めました。 _注：_これは、 @ ChrisZiebaが上記のトレースで示したものとまったく同じ行番号です。

メッセージ：使用可能なプライマリサーバーがありません
/app/node_modules/mongodb-core/lib/topologies/replset.js:860のObject.pickServer
/app/node_modules/mongodb-core/lib/topologies/replset.js:437のReplSet.ReplSet.command
/app/node_modules/mongodb/lib/replset.js:392のReplSet.ReplSet.command
/app/node_modules/mongodb/lib/db.js:281のObject.executeCommand
/app/node_modules/mongodb/lib/db.js:305のDb.Db.command
Object.wrapped in /app/node_modules/newrelic/lib/instrumentation/mongodb.js:185
/app/node_modules/mongodb/lib/collection.js:2327のObject.findAndModify
/app/node_modules/mongodb/lib/collection.js:2265のCollection.Collection.findAndModify
Object.wrapped in /app/node_modules/newrelic/lib/transaction/tracer/index.js:155
/app/node_modules/newrelic/lib/instrumentation/mongodb.js:218のObject.wrappedQuery
Object.wrapped in [as findAndModify]（/ app / node_modules / newrelic / lib / instrumentation / mongodb.js：188
NativeCollection.NativeCollection。（関数内で匿名）[findAndModifyとして]（/ app / node_modules / mongoose / lib / drivers / node-mongodb-native / collection.js：136
/app/node_modules/mquery/lib/collection/node.js:79のNodeCollection.NodeCollection.findAndModify
/app/node_modules/mongoose/lib/query.js:1833のQuery.Query._findAndModify
/app/node_modules/mongoose/lib/query.js:1621のQuery.Query._findOneAndUpdate
不明。[匿名] /app/node_modules/kareem/index.js:156
不明。[匿名] /app/node_modules/kareem/index.js:18
Object.wrapped in /app/node_modules/newrelic/lib/transaction/tracer/index.js:155
node.js：430のObject.doNTCallback0
node.js：359のprocess.process._tickCallback

モニタリング：

そのスタックトレースは、1）新しいレリックを使用していること（新しいレリックはmongodbドライバーのモンキーパッチを大量に実行するため、非常に疑わしい）、および2）mongodbドライバーがプライマリがないと考えていることを示しているだけです。利用可能ですが、理由はわかりません。

接続オプションにreplset: { loggerLevel: 'debug' }を追加して、mongodbドライバーのデバッグモードを有効にしてみてください。

var options = {
    server: {
        socketOptions: {
            keepAlive: 1,
            poolSize: 10,
            connectTimeoutMS: 30000,
            socketTimeoutMS: 30000
        }
    },
    replset: {
        loggerLevel: 'debug',
        socketOptions: {
            keepAlive: 1,
            poolSize: 10,
            connectTimeoutMS: 30000,
            socketTimeoutMS: 30000
        }
    }
};

これにより、多くのドライバーデバッグデータがstdoutに記録され、何が問題になっているのかを把握するのに役立ちます。 この「プライマリサーバーが見つかりません」エラーが発生したときに、このデータをキャプチャできますか？

ありがとう@ vkarpov15 、

これを追加し、別のトリガーが発生したらすぐに報告します。

乾杯、
ロイ

ここではnewrelicが問題になるとは思いません。 それなしで実行しようとしましたが、この問題は解決しません。 loggerLevel: 'debug'からいくつかのログデータを収集し、ここに投稿します。

おかげで、エラーの詳細を把握できた場合はお知らせください。

別のデータポイント：接続数が増えると、Mongooseは「再接続」イベントを何度もトリガーします。

「使用可能なプライマリサーバーがありません」エラーは通常、接続数がすでに増加し始めた後のトリガーになります。

私たちもこの問題を経験しました。 MongoLabを使用してHerokuでノードアプリをホストします。
先週、突然データベースとの接続が失われ、 Error no primary server availableメッセージが表示され続けました。 アプリを再起動すると問題が解決しました。
HerokuとMonogLabの両方がログに何も表示しませんでした。
誰かがこれに対する解決策を見つけてくれることを願っています。

バンプ-これは、大規模な本番デプロイメントのnode v4.2.3 mongoose v4.1.5られます。 この問題をそのまま解決するのは難しい：

• 一貫してエラーが発生しないため、アクションを実行できません（プロセスの再開/ノードの取り出し）
• ランダムに発生し、mongoreplsetステータスとは無相関のようです

@sansmischeviaはmongolab + herokuも使用していますか？

^ Cloud Managerを介してセルフホストされたmongodbサーバーを使用した、AWS EC2での大規模な本番デプロイで、この問題が発生しています。

こんにちは、

チャイムもしたいです。
node v0.12.8 、 mongo v2.6.11をmongoose v4.1.11ます。

$ npm list | grep "mongo"
├─┬ [email protected]
│ └─┬ [email protected]
│   ├─┬ [email protected]
├─┬ [email protected] 
│ ├─┬ [email protected]
│ │ ├─┬ [email protected]
└─┬ [email protected]
  └─┬ [email protected]
    ├─┬ [email protected]

$ npm list | grep "mongoose"
├─┬ [email protected]

多くのクエリを含む、データベースをシードする操作中に再現できることがよくあります。 これが発生した後、アプリケーションは影響を受けていないようです。 この間、mongoログにエラーはなく、3ノードのレプリカセットは正常です。

loggerLevel: 'debug'を試して、報告します。

@ vkarpov15 mongolab replsets + ec2を直接使用しています

私はmongolabでもこの問題を経験しています。

MongoLabとModulusでもこの問題が発生しています。

https://jira.mongodb.org/browse/NODE-622をご覧になり、誰かがログの完全なセットを提供できる場合は、それを再現できるようにするために非常に役立ちます。

ここでチャイムを鳴らします。マングースではなく、ネイティブのMongoDBクライアントを使用しています。 ここで同じno primary server availableエラーが発生します。 プライベートVPC内のEC2インスタンスでレプリカセットを実行しています。接続文字列はインスタンスのプライベートIPアドレスです。 MongoDB v3.0.3 。 通常の使用ではエラーが発生しないため、クエリのスループットが高い場合にこれが発生するように思われます。

            serverOpts = {
                server: {
                    sslValidate: false,
                    sslCA: ca,
                    socketOptions: {
                        connectTimeoutMS: 30000,
                        socketTimeoutMS: 180000
                    }
                },
                replSet: {
                    connectWithNoPrimary: false,
                    sslValidate: false,
                    sslCA: ca,
                    socketOptions: {
                        connectTimeoutMS: 30000,
                        socketTimeoutMS: 180000
                    }
                }
            };

今後のドライバーリリースでこれに対する修正があるようです： NODE-622

プレゼントには早すぎることはありません！ :)

修正バージョンはすでにNPMhttps ： //www.npmjs.com/package/mongodbで公開されてい

エラーが発生しなくなったことを確認できます。 ：多田：

ここでmongodb2.1.2のPR： https ：

mongooseを4.3.4にアップグレードした後も、このエラーが表示されます。これは、mongoコア2.1.2ます。 https://jira.mongodb.org/browse/NODE-622が再開されました

+1これが本番サーバーでも発生していることに気づきました。 理由のパターンは見当たりません。 ノード4.2.4をmongoose4.3.4およびmongodb3.0.8で使用します。 mongodbのMMSサービスを使用してクラスターを監視していますが、次のメッセージが表示されている間、アラートは表示されません。MongoError：使用可能なプライマリサーバーがありません

@ amit777接続文字列とオプションを投稿できますか？ また、これは、データベースへの大量の書き込みなど、異常に重いワークロード中に発生しましたか？

クリス、それは間違いなく書き込み操作中に発生しますが、私たちの負荷が特に重いとは言えません。 クラスター内にいくつかのノードがあり、各ノードは独立してmongoに書き込みます。

接続方法は次のとおりです。

var mongoose = require('mongoose');
var mongodb = {};

var connect = function () {
mongodb.db = "mongodb://node1:27017,node2:27017,node3:27017/myapp";
mongodb.dbOptions = {
      "db": {"native_parser": true},
      "replSet": {
        "rs_name": "mongocluster",
        "socketOptions": { "keepAlive": 1, "connectTimeoutMS": 30000, "socketTimeoutMS": 60000 }
        }
    };
  mongoose.connect(config.get('mongodb.db'), config.get('mongodb.dbOptions'));
};
connect();

また、mongodログが接続メッセージと切断メッセージで非常に速くいっぱいになっていることに気づきました。

2016-01-13T13:32:15.418-0500 I NETWORK  [conn91700536] end connection 192.168.1.50:33189 (5558 connections now open)
2016-01-13T13:32:15.418-0500 I NETWORK  [conn91700534] end connection 192.168.1.50:33187 (5558 connections now open)
2016-01-13T13:32:15.418-0500 I NETWORK  [conn91700540] end connection 192.168.1.50:33193 (5557 connections now open)
2016-01-13T13:32:15.418-0500 I NETWORK  [conn91700538] end connection 192.168.1.50:33191 (5558 connections now open)
2016-01-13T13:32:15.418-0500 I NETWORK  [conn91700542] end connection 192.168.1.50:33195 (5557 connections now open)
2016-01-13T13:32:15.418-0500 I NETWORK  [conn91700532] end connection 192.168.1.50:33185 (5556 connections now open)
2016-01-13T13:32:15.419-0500 I NETWORK  [conn91700533] end connection 192.168.1.50:33186 (5552 connections now open)
2016-01-13T13:32:15.419-0500 I NETWORK  [conn91700535] end connection 192.168.1.50:33188 (5552 connections now open)
2016-01-13T13:32:15.419-0500 I NETWORK  [conn91700537] end connection 192.168.1.50:33190 (5552 connections now open)
2016-01-13T13:32:15.419-0500 I NETWORK  [conn91700541] end connection 192.168.1.50:33194 (5551 connections now open)
2016-01-13T13:32:15.419-0500 I NETWORK  [conn91700543] end connection 192.168.1.50:33196 (5551 connections now open)
2016-01-13T13:32:15.419-0500 I NETWORK  [conn91700539] end connection 192.168.1.50:33192 (5552 connections now open)
2016-01-13T13:32:15.548-0500 I NETWORK  [initandlisten] connection accepted from 192.168.1.50:36754 #91705950 (5548 connections now open)
2016-01-13T13:32:15.549-0500 I NETWORK  [initandlisten] connection accepted from 192.168.1.50:36755 #91705951 (5549 connections now open)
2016-01-13T13:32:15.550-0500 I NETWORK  [initandlisten] connection accepted from 192.168.1.50:36756 #91705952 (5550 connections now open)
2016-01-13T13:32:15.550-0500 I NETWORK  [initandlisten] connection accepted from 192.168.1.50:36757 #91705953 (5551 connections now open)
2016-01-13T13:32:15.550-0500 I NETWORK  [initandlisten] connection accepted from 192.168.1.50:36758 #91705954 (5552 connections now open)
2016-01-13T13:32:15.551-0500 I NETWORK  [initandlisten] connection accepted from 192.168.1.50:36760 #91705955 (5553 connections now open)
2016-01-13T13:32:15.551-0500 I NETWORK  [initandlisten] connection accepted from 192.168.1.50:36759 #91705956 (5554 connections now open)
2016-01-13T13:32:15.551-0500 I NETWORK  [initandlisten] connection accepted from 192.168.1.50:36762 #91705957 (5555 connections now open)
2016-01-13T13:32:15.551-0500 I NETWORK  [initandlisten] connection accepted from 192.168.1.50:36761 #91705958 (5556 connections now open)
2016-01-13T13:32:15.553-0500 I NETWORK  [initandlisten] connection accepted from 192.168.1.50:36763 #91705959 (5557 connections now open)
2016-01-13T13:32:15.553-0500 I NETWORK  [initandlisten] connection accepted from 192.168.1.50:36764 #91705960 (5558 connections now open)
2016-01-13T13:32:15.554-0500 I NETWORK  [initandlisten] connection accepted from 192.168.1.50:36765 #91705961 (5559 connections now open)

デバッグに役立つ可能性のある追加情報を次に示します。接続プールに関連するバグがある可能性があると思い始めています。 ノードプロセスを再起動すると、mongod.logに多数の新しい接続が表示されます。 その後、約1分後、mongod.logに多数の接続終了メッセージが表示されます。

接続/切断は時間の経過とともにどんどん速く増幅するようです（私はまだそれを確認しようとしていますが）。

これを引き起こす典型的な状況は次のようなものです。

レプリカセットには、ドライバーで解決できないホストが含まれています。 ドライバが接続すると、すべての接続の正規ソースとしてレプリカセットが使用されます。 再接続ではこれらのアドレスが使用されます。 それらはドライバーによって解決可能でなければなりません。

また、このような多くの問題の原因となるIPアドレスの使用は避け、完全修飾ホスト名（短縮名なし）を使用する必要があります。

@christkv OSがホストを解決できる場合（つまり、pingを実行することによって））、これはドライバーも解決できるはずだという意味ですか？

はいのはずですが、いつでもtelnetホスト名ポートを使用して確認できます。

ええ、私はホストとポートにtelnetで接続できます。（すべてのデータベースホストには、アプリケーションサーバーに/ etc / hostsエントリがあります）。

アプリが起動して接続プールが作成された後、ネットワークの問題がない場合、切断と再接続が発生する必要がありますか？ または、mongodbログに表示される通常の接続タイムアウトと再接続はありますか？

問題は、ログの完全なセットなしで問題を理解して再現しようとするためにこれらのものを相互に関連付けることが不可能であるということです（https://jira.mongodb.org/browse/NODE-622に関する私の最後のコメントを参照してください）

ソケットタイムアウトウィンドウにすべての接続を実行するのに十分な操作がない場合、プールは閉じて再接続します。 したがって、30秒のウィンドウと10の接続があり、5 opsしかない場合、30秒ごとに再接続イベントが発生します。

プールへのすべての接続を閉じますか？ それとも、行使されていない接続のみですか？ 30秒以内にすべての接続を実行した場合、次の30秒のウィンドウで同じチェックが実行されますか？

私はあなたがリクエストしたログをmongodbチケットで取得しようとします。

すべて。 socketTimeoutウィンドウでプール内のすべての接続を実行することに成功した場合、node.jsはソケットをタイムアウトせず、プールを強制的に再接続しません。

多数の接続は、実行速度の遅い操作が多数並行して行われている場合にのみ役立ちます。それ以外の場合は、MongoDBがソケットごとにスレッドを使用するため、プールが小さい方が適しています。つまり、数千の接続ではサーバーに割り当てられたメモリが多く必要になります。より多くのCPUコンテキストスイッチを引き起こします。

mongodb-coreの次のメジャーリビジョンでは、プールが成長するように変更されるほか、低速列車の問題を最小限に抑えるためのその他の基本的な変更がいくつか行われます。 ただし、それは数か月後になり、おそらくMongoDB3.4の作業と結びつくでしょう。

大量の切断/再接続が断続的にプライマリサーバーが利用できないという問題を引き起こす可能性があると思いますか？

セットにサーバーがない可能性がある短い期間があるため、はい

@christkvこれが再び発生するまで、他のチケットのログを送信するのを待っていました。 私たちのクラスターは実際には過去数週間安定しており、このエラーは発生していません。

@ChrisZiebaおかしいですそれはいつも起こっているようです笑：+1：私は今のところjiraでチケットを開いたままにして、私たちが何を理解できるか見てみましょう。

@christkvこんにちはクリスチャン、トラフィックが少ない場合の回避策について何か

それが他の誰かに役立つ場合は、ソケットタイムアウトを削除し、keepAliveを200に増やし、プールサイズを3に減らしました。切断/再接続がはるかに少ないようですが、それでも時々発生します。

誰かに役立つ場合は、socketTimeout、connectionTimeout、keepAliveなど、ほぼすべてのマングース設定を削除し、接続が安定し始めました。 poolSizeは200です。
推奨されるアプローチかどうかはわかりませんが、現在は機能しています。 それが保持されていることを確認するために、私たちはまだそれを監視しています。

マングースv4.4.2
ノード4
Mongo 3.0

遅い操作が大量にありますか？ そうしないと、20ソケットのプールと500ソケットのプールの違いに気付かないと思います。

申し訳ありません... 200です。コメントを修正しました。

そして、ええ、あなたは正しいです。 大きな違いは感じませんが、プールのサイズは小さいよりも大きいです。

接続が開いたままで閉じない場合の本当の問題。 これは、マングースのタイムアウトとキープアライブの設定をすべて削除するまで発生していました。 なぜこれらはmongoose / mongo-driverによって処理され、OSに処理させないのでしょうか。

さて2.1.7以降には、これを回避するように再設計されたプールがあります。 socketTimeout 0を設定すると、OSに委任されますが、接続がハングするのに10分ほどかかる場合があります。

OK。 面白い。 キープアライブとsocketTimeoutの設定を削除したので、デフォルト設定は何ですか？

それは、マングースが特定の設定をデフォルトとして設定したかどうかはわかりません。 ドライバでMongoClient.connectメソッドを使用する場合、接続タイムアウトとソケットタイムアウトの両方で30秒です。

connect使用しますが、30秒を手動で設定すると、接続が蓄積し始めます。

500接続の場合、プールを開いたままにするには、socketTimeout期間内に少なくとも500 opsが必要です。そうしないと、プールが閉じて再接続が強制されます。 ただし、プールは拡大/縮小モデルであるため、これは2.1.7で変更されます。

私はmongodb3.2.6とmongoose4.3.4で同じ問題を抱えています。 これについて何か助けはありますか？

@ 15astroは、 socketTimeoutとconnectionTimeoutの設定を削除して、問題が解決するかどうかを確認してください。

@refaelos Ok..willl試してみてください..keepAlive = 6000で試してみましたが、役に立ちませんでした。 socketTimeoutとconnectionTimeoutを削除するとどのように役立つか知りたいだけですか？

ええ、私たちはさまざまな値でそれを試しました、そして私たちがこれらの設定を完全に削除したときだけ、物事はうまくいき始めました。

@refaelos ：これらの設定を削除してもうまくいきませんでした。 私が見逃している他の何か？

@ 15astro男はいない。 ごめんなさい。 今日の設定は次のようになります。

mongo   : {
    uri    : process.env.MNG_URL || 'mongodb://localhost/myDB',
    options: {
      user   : process.env.MNG_USER,
      pass   : process.env.MNG_PASS,
      replset: {
        poolSize: 200
      }
    }

  }

私の場合、それは/ etc / hostsでのIPから名前へのバインディングの欠如に関連していました。

IPの代わりに名前を使用してレプリカセットを設定し、MongoDBノードの/ etc / hostsに次のようなものがある場合：

10.10.10.10 mongodb-2gb-fra1-02 10.10.10.11 mongodb-2gb-fra1-01 10.10.10.12 mongodb-2gb-fra1-03

次に、それをすべてのアプリサーバーの/ etc / hostsに配置する必要もあります。

node-mongoは、URIに入力した内容に従って接続すると思いましたが、そうではありません。

node-mongoはMongoURIからIPまたは名前で接続し、リクエストに応答した最初のMongoDBノードから他のレプリカメンバーのホスト名を取得しているようです。 たとえば、 mongodb-2gb-fra1-03を取得し、解決のためにOSに渡します。 OSがmongodb-2gb-fra1-03について何も知らない場合、「使用可能なプライマリサーバーがありません」というエラーがスローされます。

お役に立てば幸いです。

@adriankはい、それは正しいです。それは、レプリカ

@christkvただし、 MongoSpectorのようなツールにとっては悪夢です。 そのため、1つのホストから複数のレプリカに安全に接続する際に問題が発生します。 DigitalOceanは、ほとんど誰も変更しない名前をドロップレットに自動生成します。その結果、多くのクライアントがプライマリとしてmongodb-2gb-fra1-01を使用します。 :)私たちは何かを理解できることを願っています。

ここhttps://jira.mongodb.org/browse/SERVER-1889でサーバーチケットを追跡してい

また、DigitalOceanにチケットを提出して、彼らが犯している間違いと、それがユーザーにどのように影響しているかを指摘する必要があります。

ちなみに、新しい名前がipsであるレプリカセットメンバーを削除して再度追加することができます

同様の問題があり、接続してから約12〜24時間後に、「プライマリサーバーが利用できません」というエラーが表示されます。

通常、再起動すると問題が解決します。

接続：
{ "url": "mongodb://user:password@cluser-shard-00-00, cluser-shard-00-01, cluster-shard-00-02/settings?ssl=true&replicaSet=primarycluster-shard-0&authSource=admin&retryWrites=true", "options": { "db": { "w": 1, "wtimeout": 3000, "fsync": true }, "authSource": "admin", "server": { "poolSize": 3, "socketOptions": { "autoReconnect": true, "keepAlive": 60000, "connectTimeoutMS": 7000, "socketTimeoutMS": 15000 } } }, "password": "password", "username": "username" }