Mongoose: 사용 가능한 기본 서버가 없습니다.

지금은 아무것도 튀어 나오지 않습니다. mongodb 서버가 충돌하지 않는 것이 확실합니까? 또한 셸을 사용하여 안정적인 연결을 유지할 수 있습니까?

오류가 발생하는 동안 db.runCommand( { replSetGetStatus : 1 } ) 명령을 실행하면 3 개 노드 모두에서 "health" : 1, 생성됩니다. 노드 중 하나에 기본 세트 "stateStr" : "PRIMARY", 있습니다.

DNS를 사용하여 동일한 연결 문자열을 사용하여 연결하고 있습니까? 또한 문제가 발생한 후 스토리지가 평평한 것처럼 보입니다. 컴퓨터 중 하나의 하드 드라이브 공간이 부족한지 다시 확인하고 확인할 수 있습니까?

DNS를 사용하여 동일한 연결 문자열을 사용하여 연결하고 있습니까?

동일한 연결 문자열을 사용하지 않았습니다. 프라이빗 EC2 IP 주소를 사용하면이 문제가 해결 될 것이라고 생각하십니까?

스토리지의 최대 원인이 무엇인지 확실하지 않지만 새 인스턴스를 부팅 한 후에도 사용 가능한 공간이 충분하면 기본 서버가없는 문제가 여전히 발생합니다.

복제본 세트가 구성된 방식에 따라 EC2 IP 주소가 도움이 될 수 있습니다. 쉘에서 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
}

복제 세트에서 특이한 것은 없습니다. 예를 들어 다른 관련 코드 샘플이 있습니까? 몽구스 연결 이벤트에 반응하는 코드가 있습니까?

고려할 가치가있는 또 다른 잠재적 인 문제는 최신의 새로운 유물 에이전트를 사용하고 있습니까? 나는 새로운 유물없이 실행을 시도하고 이것이 여전히 발생하는지 확인하고, 새로운 유물은 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"
 }
}

저는 이번 주 mongodb days 이벤트에 참석하여 일정을 잡고 MongoDB의 선임 엔지니어 중 한 명에게이 문제를 보여줄 수 있었지만 문제가 무엇인지 확신하지 못했습니다. 그들은 불행히도이 문제를 해결하지 못한 연결 문자열에 복제 세트와 최대 풀 크기를 추가하도록 언급했습니다.

또한 Keep alive를 비활성화하고 인스턴스에서 더 작은 값으로 설정하려고 시도했지만 해결되지 않은 것 같습니다.

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를 사용할 때 발생합니다. 연결 문자열에서 내부 ec2 IP를 사용할 때도 발생합니다.

내가 아직 시도하지 않은 유일한 방법은 connectWithNoPrimary 을 true 설정하는 것뿐입니다.

나는 또한 mongo-express 오프로 달리기를 시도 할 것입니다. 문제가 될 수 있습니다 ...

우리는 같은 문제에 직면하고 있습니다. 우리는 500-700rpm +에서 피크를 가진 약 100RPM의 지속적인 부하를 경험하고있는 사이트를 가지고 있습니다. 상대적으로 꽤 오랜 기간 동안에도 프로세스 전반에 걸쳐 이것을 보는 것 같습니다.

환경:
Heroku-75 2x 다이 노스-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
/app/node_modules/newrelic/lib/instrumentation/mongodb.js:185에 Object.wrapped
/app/node_modules/mongodb/lib/collection.js:2327의 Object.findAndModify
/app/node_modules/mongodb/lib/collection.js:2265의 Collection.Collection.findAndModify
Object.wrapped /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. (함수 내 익명) [as 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
unknown. [anonymous] in /app/node_modules/kareem/index.js:156
unknown. [anonymous] in /app/node_modules/kareem/index.js:18
Object.wrapped /app/node_modules/newrelic/lib/transaction/tracer/index.js:155
node.js : 430의 Object.doNTCallback0
node.js : 359의 process.process._tickCallback

모니터링 :

그 스택 추적은 실제로 1) 새로운 유물을 사용하고 있다는 것을 알려줍니다 (new 유물은 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는 연결 수가 증가함에 따라 "재 연결"이벤트를 계속해서 트리거합니다.

"사용 가능한 주 서버 없음"오류는 일반적으로 연결 수가 이미 증가하기 시작한 _after_를 트리거합니다.

우리도이 문제를 경험했습니다. MongoLab과 함께 Heroku에서 호스팅되는 Node 앱을 사용하십시오.
지난주에 갑자기 데이터베이스와의 연결이 끊어졌고 Error no primary server available 메시지가 계속 표시되었습니다. 앱을 다시 시작하면 문제가 해결되었습니다.
Heroku와 MonogLab 모두 로그에서 아무것도 보지 못했습니다.
누군가가 이것에 대한 해결책을 찾길 바랍니다.

범프-대규모 프로덕션 배포에서 node v4.2.3 mongoose v4.1.5 에서이 현상을 볼 수 있습니다. 이 문제를 해결하기는 어렵습니다.

• 지속적으로 오류가 발생하지 않아 조치를 취하지 못합니다 (프로세스 다시 시작 / 노드 제거).
• 무작위로 발생하며 mongo replset 상태와 관련이없는 것으로 보입니다.

@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

선물하기에는 너무 이르지 않습니다! :)

고정 버전은 이미 NPM https://www.npmjs.com/package/mongodb 에 게시되었습니다

더 이상 오류가 발생하지 않음을 확인할 수 있습니다. : tada :

mongodb 2.1.2에 대한 PR : https://github.com/Automattic/mongoose/pull/3712

mongoose를 mongo core 2.1.2 를 사용하는 4.3.4 업그레이드 한 후에도이 오류가 계속 표시됩니다. https://jira.mongodb.org/browse/NODE-622 가 재개되었습니다

+1 우리 프로덕션 서버에서도 이런 일이 발생하는 것을 확인했습니다. 나는 그 이유에 대한 어떤 패턴도 보지 못한다. mongoose 4.3.4 및 mongodb 3.0.8과 함께 노드 4.2.4 사용. mongodb의 MMS 서비스를 사용하여 클러스터를 모니터링하고 다음 메시지가 표시되는 동안 경고를 보지 못했습니다. MongoError : 사용할 수있는 기본 서버 없음

@ amit777 연결 문자열과 옵션을 게시 할 수 있습니까? 또한 데이터베이스에 대한 많은 쓰기와 같이 비정상적으로 무거운 워크로드 중에 이런 일이 발생 했습니까?

Chris, 쓰기 작업 중에 확실히 발생하지만 부하가 특히 무겁다 고 말하지는 않습니다. 클러스터에는 각 노드가 독립적으로 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에 여러 연결 종료 메시지가 표시됩니다.

연결 / 연결 해제가 시간이 지남에 따라 더 빠르고 빠르게 증폭되는 것 같습니다 (여전히 확인하려고 노력 중임).

이것을 일으키는 전형적인 상황은 다음과 같습니다.

Replicaset에 드라이버가 확인할 수없는 호스트가 포함되어 있습니다. 드라이버가 연결되면 복제 세트를 모든 연결의 표준 소스로 사용합니다. 재 연결은 해당 주소를 사용합니다. 운전자가 해결할 수 있어야합니다.

또한 이와 같은 많은 문제의 원인이되는 IP 주소 사용을 피해야합니다. 완전한 호스트 이름 (짧은 이름 없음)을 사용하십시오.

@christkv OS가 호스트를 확인할 수있는 경우 (예 : ping 수행)), 이것은 드라이버도 해결할 수 있어야 함을 의미합니까?

그래야하지만 항상 텔넷 호스트 이름 포트를 사용하여 확인할 수 있습니다.

예, 호스트와 포트로 텔넷을 연결할 수 있습니다. (모든 데이터베이스 호스트에는 응용 프로그램 서버에 / etc / hosts 항목이 있습니다).

앱이 시작되고 연결 풀이 생성 된 후 네트워크 문제가없는 경우 연결이 끊겼다가 다시 연결되어야합니까? 아니면 mongodb 로그에서 볼 수있는 정상적인 연결 시간 초과 및 다시 연결이 있습니까?

문제는 전체 로그 세트없이 문제를 이해하고 재현하려고 시도하기 위해 이러한 것들을 상호 연관시키는 것이 불가능하다는 것입니다 (https://jira.mongodb.org/browse/NODE-622에 대한 마지막 댓글 참조).

소켓 시간 초과 창에 모든 연결을 실행하기에 충분한 작업이없는 경우 풀이 닫히고 다시 연결됩니다. 따라서 30 초 창과 10 개의 연결이 있지만 5 개의 작업 만있는 경우 30 초마다 다시 연결 이벤트가 발생합니다.

풀에 대한 모든 연결이 종료됩니까? 아니면 운동하지 않은 연결 만? 30 초 이내에 모든 연결을 실행하면 다음 30 초 동안 동일한 검사가 수행됩니까?

mongodb 티켓에서 요청한 로그를 얻으려고 노력할 것입니다 .. 도와 주셔서 감사합니다.

모두. socketTimeout 창에서 풀의 모든 연결을 실행하면 node.js는 소켓을 시간 초과하지 않고 풀 재 연결을 강제로 닫지 않습니다.

팁 많은 연결은 병렬로 실행되는 작업이 많을 때만 유용합니다. 더 많은 CPU 컨텍스트 전환이 발생합니다.

mongodb-core의 다음 주요 개정판은 느린 열차 문제를 최소화하기 위해 몇 가지 다른 근본적인 변화뿐만 아니라 풀이 성장하도록 변경합니다. 그러나 그것은 몇 달 후에 MongoDB 3.4 작업과 함께 묶일 것입니다.

엄청난 양의 연결 해제 / 재 연결로 인해 간헐적으로 주 서버를 사용할 수없는 문제가 발생할 가능성이 있습니까?

예, 세트에 서버가 없을 수있는 짧은 기간이 있습니다.

@christkv 다른 티켓에 로그를 보낼 때까지 기다렸습니다. 우리 클러스터는 실제로 지난 몇 주 동안 안정적이었으며이 오류를 보지 못했습니다.

@ChrisZieba 재미있게 항상 그런 일이 일어나는 것 같네요 ㅋㅋ : +1 : 지금은 티켓을 jira에 열어두고 우리가 무엇을 알아낼 수 있는지 봅니다.

@christkv 안녕하세요 Christian, 트래픽이 낮은 경우 해결 방법에 대한 포인터가 있는지 궁금합니다. 풀 크기를 줄이고 제한 시간을 늘리는 것을 생각하고있었습니다.

다른 사람에게 도움이된다면 소켓 시간 초과를 제거하고 keepAlive를 200으로 늘리고 풀 크기를 3으로 줄였습니다. 연결 해제 / 재 연결이 훨씬 적은 것 같습니다.하지만 여전히 가끔 발생합니다.

누구에게나 도움이된다면 socketTimeout 및 connectionTimeout 및 keepAlive를 포함한 거의 모든 몽구스 설정을 제거하고 연결이 안정되기 시작했습니다. 우리의 poolSize는 200입니다.
권장되는 접근 방식인지 확실하지 않지만 지금은 작동합니다. 우리는 그것이 유지되는지 확인하기 위해 여전히 그것을 모니터링하고 있습니다.

몽구스 v4.4.2
노드 4
몽고 3.0

느린 작업이 엄청나게 많습니까? 그렇지 않으면 20 소켓 풀과 500 풀 사이의 차이를 눈치 채지 못할 것입니다.

죄송합니다. 200입니다. 댓글을 수정했습니다.

그리고 네 말이 맞아요. 우리는 큰 차이를 느끼지 못하지만 풀 크기가 더 작습니다.

연결이 계속 열리고 닫히지 않을 때의 실제 문제. 이것은 몽구스 타임 아웃과 keepAlive 설정을 모두 제거 할 때까지 발생했습니다. 왜 이것들이 mongoose / mongo-driver에 의해 처리되고 OS가 그것을하지 못하게하는지 궁금합니다.

Well 2.1.7 이상에는이를 방지하는 재 설계된 풀이 있습니다. socketTimeout 0을 설정하면 OS에 위임하지만 10 분 정도의 연결이 끊길 수 있습니다.

확인. 흥미 롭군요. 이제 keepAlive 및 socketTimeout 설정을 제거 했으므로 기본 설정은 무엇입니까?

몽구스가 특정 설정을 기본값으로 설정했는지 확실하지 않습니다. 드라이버에서 MongoClient.connect 메서드를 사용하는 경우 연결 및 소켓 시간 초과 모두에 대해 30 초입니다.

우리는 connect 하지만 수동으로 30 초를 설정하면 연결이 쌓이기 시작합니다.

500 개의 연결을 사용하려면 socketTimeout 기간 내에 최소 500 개의 작업이 필요합니다. 그렇지 않으면 풀이 닫히고 다시 연결됩니다. 그러나 풀이 성장 / 축소 모델이기 때문에 2.1.7에서 변경됩니다.

mongodb 3.2.6 및 mongoose 4.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에 넣어야합니다.

나는 노드-몽고가 내가 URI에 넣은 것에 따라 연결한다고 생각했지만 그렇지 않습니다.

node-mongo는 Mongo URI에서 IP 또는 이름으로 연결 한 다음 요청에 응답 한 첫 번째 MongoDB 노드에서 다른 복제본 구성원의 호스트 이름을 가져 오는 것 같습니다. 예를 들어 mongodb-2gb-fra1-03 를 가져와 해결을 위해 OS에 전달합니다. OS가 mongodb-2gb-fra1-03 에 대해 아무것도 모르는 경우 "Error no primary server available"이 발생합니다.

도움이되기를 바랍니다.

@adriank 예 맞습니다. 복제 세트 구성에서 다시 가져온 연결의 연결입니다. 그 이유는 이것이 복제 세트에 대한 진실의 표준 소스이기 때문입니다. 이는 또한 드라이버가 올바르게 장애 조치하고 세트에서 추가 및 제거되는 서버를 감지 할 수 있도록 복제 세트 구성의 모든 주소를 드라이버가 확인할 수 있어야하는 이유이기도합니다. 이전 드라이버는 SDAM 사양을 구현하지 않았으며 더 느슨했습니다. 그러나 이것은 프로덕션 환경에서 문제를 일으킬 수 있습니다.

@christkv 그러나 그것은 우리 같은 도구에 대한 악몽 MongoSpector . 이로 인해 하나의 호스트에서 둘 이상의 복제본에 안전하게 연결하는 데 문제가 있습니다. DigitalOcean은 거의 아무도 변경하지 않는 물방울에 이름을 자동 생성하며 그 결과 많은 클라이언트가 PRIMARY로 mongodb-2gb-fra1-01 를 사용합니다. :) 우리가 뭔가 알아낼 수 있기를 바랍니다.

https://jira.mongodb.org/browse/SERVER-1889 에서 서버 티켓을 추적하고

또한 DigitalOcean에 그들이 저지른 실수와 사용자에게 미치는 영향을 지적하는 티켓을 제출해야합니다.

그런데 새 이름이 ips 인 replicaset 구성원을 제거하고 다시 추가 할 수 있습니다.

비슷한 문제가 발생하여 약 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" }