Mongoose: Mongoose 4.6.2 produz o erro "MongoError: nenhum primário encontrado no replicaset" enquanto 4.4.19 funciona bem

Criado em 4 out. 2016  ·  82Comentários  ·  Fonte: Automattic/mongoose

Conexão simples a um conjunto de réplicas do MongoDB. Funciona muito bem no Mongoose 4.4.19, mas não no 4.6.2

mongoURI = " mongodb: // IP : 27017, IP: 27017 /" + dbName + "? replicaSet = my_replica_set";

Usando 4.6.2, tentei o seguinte:

  • definindo replset nas opções de conexão
  • connectWithNoPrimary: true
  • tentei mongoose.createConnection vs mongoose.connect
  • nó de árbitro incluído e excluído na string de conexão

Se a string de conexão usar apenas um banco de dados, ela funcionará bem. Estou realmente curioso para saber por que esse erro ocorre. Alguma ideia?

Erro Completo:

/Users/adeel/dev/navi/euler/node_modules/mongodb/lib/replset.js:360
process.nextTick (function () {throw err;})
^
MongoError: nenhum primário encontrado no replicaset
em /Users/adeel/dev/navi/euler/node_modules/mongodb-core/lib/topologies/replset.js:631:32
no .(/Users/adeel/dev/navi/euler/node_modules/mongodb-core/lib/topologies/replset.js:421:24)
em g (events.js: 286: 16)
em emitOne (events.js: 96: 13)
em emit (events.js: 188: 7)
no .(/Users/adeel/dev/navi/euler/node_modules/mongodb-core/lib/topologies/server.js:313:21)
em emitOne (events.js: 96: 13)
em emit (events.js: 188: 7)
no .(/Users/adeel/dev/navi/euler/node_modules/mongodb-core/lib/connection/pool.js:260:12)
em g (events.js: 286: 16)
em emitTwo (events.js: 106: 13)
em emit (events.js: 191: 7)
em Socket.(/Users/adeel/dev/navi/euler/node_modules/mongodb-core/lib/connection/connection.js:162:49)
em Socket.g (events.js: 286: 16)
em emitOne (events.js: 96: 13)
em Socket.emit (events.js: 188: 7)

needs clarification

Comentários muito úteis

@wayofthefuture você está se referindo ao CosmosDB? Também percebi que a conexão com o CosmosDB funcionava por meio do Mongoose 4.5.10 se você remover o & replicaset = globaldb no final.

Todos 82 comentários

+1

Você pode se conectar com o shell mongo?

Posso me conectar com o shell mongo. O DB está funcionando bem. Estamos em produção e muitos microsserviços estão conectados ao banco de dados usando a string do conjunto de réplicas.

No entanto, para novos projetos, a conexão usando a string do conjunto de réplicas parece não funcionar. E temos que usar apenas o endereço IP do nó mestre. A princípio pensei que era um problema de versão (4.6.2 vs 4.4.19).

No entanto, recentemente não consegui me conectar usando a string de réplica no 4.6.2 no novo projeto. Como solução temporária, decidi usar apenas o endereço IP do nó mestre (string de conexão com apenas um endereço IP).

Estou vendo problemas semelhantes. Realmente não posso adicionar mais esclarecimentos ou fornecer um bom exemplo de código.
Mas minha suspeita é que isso tenha a ver com uma incompatibilidade de uma das dependências.
A primeira vez que observei esse problema foi quando atualizei outros pacotes (mas não o mangusto que estava em 4.5.8 na época)

@zoellner Se você for capaz de postar uma lista de alguns dos pacotes que atualizou antes do início deste problema para você, posso compará-la com minha própria lista e podemos tentar identificar onde está a incompatibilidade.

Considerando que esse problema ocorre apenas em novos projetos para mim, é muito possível que seja devido à incompatibilidade do Mongoose com uma versão mais recente de um pacote npm diferente.

@adeelzaman Eu criei um diff do npm-shrinkwrap.json do meu projeto para o commit que começou a causar os problemas. É um pouco longo, então coloquei aqui:
https://gist.github.com/zoellner/eddd3d40291e150919bb025f452f9054

@adeelzaman Eu atualizei a essência acima agora com uma que confirmei estar causando o problema

@zoellner Eu não consigo dizer qual é a causa, você pode nos esclarecer?

Descobri que, para nós, o problema não ocorre no Mongoose 4.5.8. Temporariamente, bloqueamos nossos repositórios no 4.5.8 do Mongoose para resolver o problema.

Também devo mencionar que, ao tentar isolar o problema, criei um novo projeto com apenas um módulo de nó (mongoose) e tentei me conectar ao conjunto de réplicas usando 4.6.0 e obtive o mesmo erro.

Então, talvez não seja um erro de incompatibilidade, mas um erro com 4.6.0? Não consegui identificar mais nada sobre o que estava causando o erro. Eu pretendo investigar mais quando eu tiver algum tempo livre.

Acabei de encontrar o que tenho certeza de que é o mesmo problema em 4.6.2 e 4.6.4, recebo esta saída para minha conexão de replicaset, a mesma configuração de uri de configuração acima

Error: Uncaught, unspecified "error" event. ([object Object])
    at NativeConnection.emit (events.js:163:17)
    at /home/projects/xxx/xxx/node_modules/mongoose/lib/connection.js:466:17
    at NativeConnection.Connection.error (/home/projects/xxx/xxx/node_modules/mongoose/lib/connection.js:489:12)
    at /home/projects/xxx/xxx/node_modules/mongoose/lib/connection.js:520:15
    at /home/projects/xxx/xxx/node_modules/mongoose/lib/drivers/node-mongodb-native/connection.js:216:21
    at /home/projects/xxx/xxx/node_modules/mongodb/lib/db.js:229:14
    at .<anonymous> (/home/projects/xxx/xxx/node_modules/mongodb/lib/replset.js:357:9)
    at g (events.js:286:16)
    at emitOne (events.js:96:13)
    at emit (events.js:188:7)
    at Timeout.<anonymous> (/home/projects/xxx/xxx/node_modules/mongodb-core/lib/topologies/replset.js:507:14)
    at tryOnTimeout (timers.js:232:11)
    at Timer.listOnTimeout (timers.js:202:5)

Hmm estranho. Este é quase certamente um problema com o driver mongodb subjacente, porque o mongoose não faz nada com conjuntos de réplicas por conta própria. Houve alguns problemas com conjuntos de réplicas que foram corrigidos no driver mongodb 2.2.11 , atualizará para mongoose 4.6.5 e veja se isso corrige.

+1

@ mo4islona ainda acontecendo em 4.6.5?

+1 o mesmo problema (em 4.6.5 também).
Última versão funcional 4.5.9 após esta versão 4.6.0 e mais, recebo o erro "nenhum primário encontrado no replicaset"

@ vkarpov15 Sim 4.6.5 não funciona. Não tentei 4.5.9, mas 4.4.19 funciona.

mesmo problema aqui usando um uri como

mongodb://user:password<strong i="6">@server1</strong>,server2,server3/database?replicaSet=repname

funciona em 4.5.9, mas a versão mais recente apresenta erros

hoje fiz uma instalação no ubuntu 14 com mongoose 4.5.9 e recebi o mesmo erro
/node_modules/mongodb/lib/mongo_client.js:225 throw err ^ MongoError: no primary found in replicaset at /node_modules/mongodb-core/lib/topologies/replset.js:628:32 at Server.<anonymous> (test/node_modules/mongodb-core/lib/topologies/replset.js:420:24)

o mesmo código estava funcionando sem problemas no mac OSX

meu uri é o mesmo que dottodot

Esquisito. Você pode confirmar se pode se conectar usando o shell mongodb usando esse URI da mesma máquina?

@ vkarpov15 posso me conectar usando o shell mongodb e posso me conectar usando a forma URI padrão

@stampsrule qual é a forma URI padrão?

@ vkarpov15

mongodb://user:password<strong i="7">@server</strong>:port/database

Ok, então qual é o código de conexão que está falhando?

Estou tendo um problema semelhante, não consigo me conectar no mangusto> = 4.6.0. Reverter para 4.5.10 funciona. Minha string de conexão se parece com:

mongodb://username:password<strong i="7">@ip1</strong>:port1,ip2:port2/database?authSource=blah&replicaSet=rs0&ssl=true

Estou usando as seguintes opções de conexão:

{
   replSet: {
      sslValidate: false,
      sslCert: fs.readFileSync(`...`),
      sslKey: fs.readFileSync(`...`),
      sslCA: fs.readFileSync(`...`)
   }
}

Se eu definir um manipulador de erros para a conexão, assim:

 mongoose.connection.on('error', (err) => {
    console.log(err instanceof Error, err)
})

então, curiosamente, err instanceof Error é falso, e a saída do registro err é:

 ReplSet {
  domain: null,
  _events: 
   { reconnect: [Function],
     timeout: { [Function: g] listener: [Function] },
     error: { [Function: g] listener: [Function] },
     connect: { [Function: g] listener: [Function: connectHandler] } },
  _eventsCount: 4,
  _maxListeners: undefined,
  id: 1,
  s: 
   { options: 
      { disconnectHandler: [Object],
        cursorFactory: [Object],
        reconnect: false,
        emitError: true,
        size: 5,
        rejectUnauthorized: false,
        cert: <Buffer  ... >,
        key: <Buffer  ... >,
        ca: <Buffer  ... >,
        socketOptions: {},
        setName: 'rs0',
        ssl: true,
        clientInfo: [Object] },
     bson: BSON {},
     Cursor: 
      { [Function: Cursor]
        super_: [Object],
        define: [Object],
        INIT: 0,
        OPEN: 1,
        CLOSED: 2,
        GET_MORE: 3 },
     logger: Logger { className: 'ReplSet' },
     seedlist: [ [Object], [Object] ],
     replicaSetState: 
      ReplSetState {
        domain: null,
        _events: [Object],
        _eventsCount: 3,
        _maxListeners: undefined,
        topologyType: 'ReplicaSetNoPrimary',
        setName: 'rs0',
        set: {},
        id: 1,
        logger: [Object],
        index: 0,
        acceptableLatency: 15,
        heartbeatFrequencyMS: 10000,
        primary: null,
        secondaries: [],
        arbiters: [],
        passives: [],
        ghosts: [],
        unknownServers: [],
        maxElectionId: null,
        maxSetVersion: 0,
        replicasetDescription: [Object] },
     connectingServers: [],
     haInterval: 10000,
     minHeartbeatFrequencyMS: 500,
     disconnectHandler: Store { s: [Object], length: [Getter] },
     index: 0,
     connectOptions: { forceServerObjectId: false, w: 1, promiseLibrary: [Object] },
     debug: false,
     clientInfo: 
      { driver: [Object],
        os: [Object],
        platform: 'Node.js v6.7.0, LE, mongodb-core: 2.0.13' } },
  authProviders: 
   { mongocr: MongoCR { bson: BSON {}, authStore: [] },
     x509: X509 { bson: BSON {}, authStore: [] },
     plain: Plain { bson: BSON {}, authStore: [] },
     gssapi: GSSAPI { bson: BSON {}, authStore: [] },
     sspi: SSPI { bson: BSON {}, authStore: [] },
     'scram-sha-1': ScramSHA1 { bson: BSON {}, authStore: [], id: 0 } },
  initialConnectState: { connect: false, fullsetup: false, all: false },
  state: 'destroyed',
  haTimeoutId: 
   Timeout {
     '0': null,
     _called: true,
     _idleTimeout: -1,
     _idlePrev: null,
     _idleNext: null,
     _idleStart: 1969,
     _onTimeout: null,
     _repeat: null },
  authenticating: false,
  ismaster: null }

Alguns outros detalhes:

  • Usando mangusto 4.6.8 , mas o problema parece se aplicar a 4.6.2 e mais
  • mongoose.connection.readyState é 2 enquanto tenta se conectar, então 0 quando a conexão falha
  • Embora eu tenha ativado a depuração, não há saída
  • Usando o nó 6.7.0

use [email protected] , a última versão não funciona.i teve o mesmo problema (repset).

@adeelzaman seu conjunto de réplicas está hospedado em um ambiente onde você pode ter mais de um endereço para acessar cada um dos membros do conjunto de réplicas, por exemplo, interno e externo?

@dustywusty Não, não importa. Um endereço IP por membro do conjunto de réplicas.

Eu tenho esse problema acontecendo com 4.6.0 e mais recentes, 4.5.10 é a última versão funcional para mim.

Reveja se este problema é semelhante a - https://github.com/Automattic/mongoose/issues/4834

Estou usando a versão mais recente e registrei self.s.replicaSetState no momento do erro e encontrei este:
topologyType: 'ReplicaSetNoPrimary', setName: 'rs0', set: { 'mongo1:27017': { type: 'Unknown', electionId: null, setName: null, setVersion: null }, 'mongo2:27017': { type: 'PossiblePrimary', setVersion: null, electionId: null, setName: null }, 'mongo3:27017': { type: 'Unknown', electionId: null, setName: null, setVersion: null }, 'database4ca:27017': { type: 'RSSecondary', electionId: undefined, setName: 'rs0', setVersion: 5 }, 'mongoarb:27017': { type: 'Unknown', electionId: null, setName: null, setVersion: null } },

os valores nulos estão causando o erro?

esse foi 100% o problema, quando coloquei mongo1.example. com: 27017 ele não conectava mesmo que o IP funcionasse. quando resolvi o problema de URL e substituí meu mongodb: // URI por URLs, tudo funcionou.

vi o comentário de @wparsons-360insights e experimentei. Confirmando que exatamente a mesma conexão db para o conjunto de réplicas funciona em 4.5.10, mas não em 4.7.1

Oi,

Eu estou enfrentando o mesmo problema.

mangusto ":" ^ 4.7.6 "

config:
config.mongoose = {
uri: " mongodb: // Appinv-db : 27017, Appinv-db1: 27017, Appinv-db2: 27017, Appinv-db3: 27017 / nexgtv_16? replicaSet = rs0",
// uri: " mongodb: // localhost / nexgtv_16 ",
opções: {
bd: {native_parser: true},
replset: {
// auto_reconnect: false,
poolSize: 10,
socketOptions: {
keepAlive: 1000,
connectTimeoutMS: 30000
},
reconnectInterval: 2000, // O padrão é 1000 ms
reconnectTries: 60 // O padrão é 30
},
servidor: {
tamanho da piscina: 5,
socketOptions: {
keepAlive: 1000,
connectTimeoutMS: 30000
},
reconnectInterval: 2000, // O padrão é 1000 ms
reconnectTries: 60 // O padrão é 30
}
}
}

Conexão:
mongoose.connect (config.mongoose.uri, config.mongoose.options);

Erro:
MongoError: conexão 3 para Appinv-db3: 27017 fechada
em Function.MongoError.create (/etc/scripts/push-notifications/node_modules/mongodb-core/lib/error.js:29:11)
em Socket.(/etc/scripts/push-notifications/node_modules/mongodb-core/lib/connection/connection.js:198:22)
em Socket.g (events.js: 291: 16)
em emitOne (events.js: 96: 13)
em Socket.emit (events.js: 188: 7)
em TCP._handle.close [as _onclose] (net.js: 498: 12)
erro de conexão: {MongoError: nenhum primário encontrado no replicaset
em /etc/scripts/push-notifications/node_modules/mongodb-core/lib/topologies/replset.js:659:32
no servidor.(/etc/scripts/push-notifications/node_modules/mongodb-core/lib/topologies/replset.js:442:24)
em Server.g (events.js: 291: 16)
em emitOne (events.js: 96: 13)
em Server.emit (events.js: 188: 7)
em Object.cb (/etc/scripts/push-notifications/node_modules/mongodb-core/lib/topologies/server.js:259:55)
em Connection.(/etc/scripts/push-notifications/node_modules/mongodb-core/lib/connection/pool.js:243:32)
em Connection.g (events.js: 291: 16)
em emitTwo (events.js: 106: 13)
em Connection.emit (events.js: 191: 7)
em Socket.(/etc/scripts/push-notifications/node_modules/mongodb-core/lib/connection/connection.js:197:12)
em Socket.g (events.js: 291: 16)
em emitOne (events.js: 96: 13)
em Socket.emit (events.js: 188: 7)
em TCP._handle.close [as _onclose] (net.js: 498: 12)
nome: 'MongoError',
mensagem: 'nenhum primário encontrado no replicaset'}

Por favor, sugira qualquer solução

Tendo um problema semelhante com o mLab no heroku com a réplica no uri corrigido usando a versão 4.5.10

Estamos enfrentando esse problema também, mas uma atualização recente do MongoDB 3.0 -> 3.4 parece permitir que a versão mais recente do mongoose funcione de maneira estável.

(Não tenho certeza se é devido a 4.7.8 ou 3.4 ou uma combinação dos dois)

Eu tive o mesmo problema.
Adicionar os nomes de host dos membros dos replicasets (como se estivessem no replset hostsfile) ao webservers hostsfile corrigiu o problema para mim.

rs.conf();
{
    "_id" : "cwreplset0",
    "version" : 348189,
    "protocolVersion" : NumberLong(1),
    "members" : [
        {
            "_id" : 0,
            "host" : "cwmongo1:27017",
            "arbiterOnly" : false,
            "buildIndexes" : true,
            "hidden" : false,
            "priority" : 2,
            "tags" : {

            },
            "slaveDelay" : NumberLong(0),
            "votes" : 1
        },
        {
            "_id" : 1,
            "host" : "cwmongoArbiter:27017",
            "arbiterOnly" : true,
            "buildIndexes" : true,
            "hidden" : false,
            "priority" : 1,
            "tags" : {

            },
            "slaveDelay" : NumberLong(0),
            "votes" : 1
        },
        {
            "_id" : 2,
            "host" : "cwmongo2:27017",
            "arbiterOnly" : false,
            "buildIndexes" : true,
            "hidden" : false,
            "priority" : 1,
            "tags" : {

            },
            "slaveDelay" : NumberLong(0),
            "votes" : 1
        }
    ],
...
cwmongo1 /etc/hosts:
127.0.0.1   cwmongo1
XXX cwmongo2
XXX cwmongoArbiter

cwmongo2 /etc/hosts:
127.0.0.1   cwmongo2
XXX cwmongo1
XXX cwmongoArbiter

cwmongoArbiter /etc/hosts:
127.0.0.1   cwmongoArbiter
XXX cwmongo2
XXX cwmongo1
webservers /etc/hosts:

XXX cwmongo1
XXX cwmongo2

Surpreendentemente, problema corrigido para mim com replicaSet param no mLab MONGODB_URI após atualizar para a versão mais recente 4.8.1 .

dado o comentário de @dazwiafl , é possível que o erro ocorra quando o "host" na configuração do replicaset no servidor mongodb não corresponde aos nomes do servidor na string de conexão? Por exemplo, quando nomes DNS ou endereços IP personalizados (internos) são usados?
Analisando os comentários anteriores, parece ser o caso de todos que mencionaram seus nomes de host.
Nesse caso, # 4834 seria o mesmo problema sugerido por @flipflopapp
EDITAR: # 3634 também pode estar relacionado

Confirmando que mongoose 4.8.1 funciona para nós (com mongodb 3.4.2) se e somente se usarmos os nomes DNS completos (externos) na string de conexão.

Anteriormente, usamos um nome dns interno (que foi resolvido para um endereço IP EC2 privado em nosso VPC). Isso não funciona quando os nomes de host em rs.conf () estão configurados para os nomes DNS externos.
Não testei todas as configurações, mas minha intuição neste ponto me diz que a versão mongoose / mongodb realmente não importa.
Este problema deve ser resolvido ao usar os nomes DNS completos.

@zoellner Eu tenho uma configuração semelhante em que estou me conectando ao mongo via rede privada, então não há acesso externo, então como você contorna isso? Antes eu só conseguia me conectar usando os endereços IP privados. Tenho tentado encontrar uma resposta, mas sem muita sorte.

Fiz algumas alterações de infraestrutura para permitir "acesso externo" (limitado aos servidores que precisam). Não é uma solução ideal, mas funcionará por um tempo até que haja uma maneira melhor. Eu acho que é realmente um problema a ser levantado com o pessoal da mongodb para lidar melhor com esse cenário bastante comum

@dottodot Você deve ser capaz de definir sslAllowInvalidCertificates e sslAllowInvalidHostnames no lado do cliente e definir o certificado autoassinado para usar localhost ou 127.0.0.1 para o FQDN. Isso está funcionando para mim com IPs como o campo de host no replicaset e ainda estou acessando os hosts por meio de um nome de host que não corresponde ao nome de host do host ou FQDN definido no certificado. Não testei o uso de IPs no mongo uri para acessar o cluster. Se fosse benéfico para você, eu poderia testar isso ...

Existe alguma correção para esse problema no mongoose v4.8.4?

4.5.10 e 4.4.12 não resolvem o problema para mim. Executando um conjunto de réplicas do google compute com o nome do conjunto de réplicas rs0.

Eu tive o mesmo problema ao usar a v4.6.5, a atualização para a v4.8.5 resolveu o problema sem alterar nenhuma configuração.

Acabei de tentar 4.8.5 sem sorte :(

Como você se conecta ao conjunto de réplicas?

Nós estamos usando:

mongodb://root:[email protected]:27017,mongo1.dev.domain.com:27017,mongo2.dev.domain.com:27017/main?replicaSet=rs0&authSource=admin

Eu li em algum lugar que só é necessário passar o endereço principal e os 2 secundários não são necessários. Isso é verdade? Obrigado.

Experimente isso. NOTE que não há necessidade de se conectar ao árbitro mongo, apenas 2 réplicas:

mongoose.connect ("mongodb: //mongo1.dev.domain.com,mongo2.dev.domain.com/main? replicaSet = rs0 & authSource = admin", {
usuário: 'MONGO_USERNAME',
passar: 'MONGO_PASSWORD'
});

Se isso NÃO funcionar, você tem alguns problemas de configuração de réplica, por exemplo, talvez a porta mongo à qual você está se conectando esteja fechada.

Encontrei esta mensagem de erro ao se conectar a um mongo RS em um Kubernetes StatefulSet. Não qualificou os nomes DNS na string de conexão com o nome SS e obteve o "nenhum erro primário".

Portanto, para um SS chamado mongo, "mongo-0" deveria ser "mongo-0.mongo". O erro foi embora.

@edgarmarkosov Não estamos usando um árbitro. Estamos usando 3 instâncias completas. Foi recomendado nos documentos do Mongo que ter 3 instâncias completas era melhor do que 2 com um árbitro. Estamos usando a implantação de réplica bitnami padrão do Google Cloud. Bastante alguns cliques e está instalado e funcionando.

Tentei conexão usando o método acima, mas não funcionou. Tenho certeza de que é algum tipo de problema estranho. Li algures que o primário irá enviar os endereços dos outros 2 secundários. Espero que seja assim, então podemos apenas usar o endereço do primário na string de conexão.

@wayofthefuture "Li em algum lugar que o primário enviará os endereços dos outros 2 secundários."
Você tem uma fonte. Bcos isso não funcionou para mim nem qualquer outra solução sugerida aqui. Estou preso na mesma situação como op. : /

Às vezes eu me pergunto se seria melhor usar a API do Mongo diretamente? É realmente mais benéfico ficar preso a problemas como esses porque queríamos algo que fosse mais fácil de trabalhar? Às vezes, parece uma camada de abstração desnecessária.

@wayofthefuture concordou, estamos planejando isso, mas ainda não o fizemos.

Pode confirmar este problema em 4.9.0.

Execução do mongo no Kubernetes com 3 nós em um controlador de replicação. Meu servidor de nó usando mongooose está se conectando ao meu cluster mongo em um namespace diferente.

Se meu nodeserver e cluster mongo estiverem no mesmo namespace (sem resolução de dns necessária), ele funcionará.

Conseguiu descobrir o problema, graças a mensagens de erro mais específicas com as atualizações de driver mais recentes (agora usando o mongoose 4.9.2). O problema era que o mongoose estava tentando se conectar a cada host especificado na configuração do conjunto de réplicas do mongo, em vez de usar os hosts que eu especifiquei em minha string de conexão do mongoose. E como meu servidor de nó e cluster mongo estão sendo executados em namespaces separados, meu servidor de nó não conseguiu resolver o DNS para esses hosts.

Você pode explicar o que você fez para resolver o problema? Meu Mongo Cluster também está sendo executado em um namespace separado. Obrigado.

@wayofthefuture Não tenho certeza se fiz isso da melhor maneira, mas acabei de editar o arquivo /etc/hosts no meu host onde o servidor de nó está sendo executado.

Portanto, por exemplo, digamos que os hosts especificados na configuração do conjunto de réplicas sejam db1.example.com e db2.example.com . Mas então, por algum motivo (como configuração de firewall), o host em que seu servidor de nó está sendo executado não pode resolver esses dois nomes de host. Portanto, em sua string de configuração de conexão do mongoose, você está usando diferentes nomes de host ou endereços IP (por exemplo 10.0.0.1 e 10.0.0.2 ). Se for esse o caso, você pode editar o arquivo /etc/hosts (no mesmo host em que o servidor do nó está em execução) para incluir as linhas:

10.0.0.1 db1.example.com
10.0.0.2 db2.example.com

Pelo menos esse era o meu problema - não tenho certeza se isso se aplica a isso também se aplica à sua situação. Estranho que uma versão diferente do driver mongo pudesse causar um problema como esse. De qualquer forma, espero que ajude.

Confirme o mesmo erro:
Erro de conexão padrão do Mongoose: MongoError: nenhum primário encontrado no replicaset.

Usando mangusto 4.9.3. e docker compose. Não tenho certeza se docker tem algo a ver com isso, mas reverter para 4.5.10 resolveu o problema.

Alguém pode dar uma olhada séria neste problema, visto que foi levantado há 7 meses, sem nenhuma solução além de reverter para 4.5.10.

@asabhaney Você está certo ... agora ele está tentando se conectar aos endereços IP internos de cada nó do cluster. No entanto, isso ainda parece um bug para mim, porque se eu especificar um nome de domínio com um IP estático, ele deve usar esse IP estático e não tentar usar o IP interno em outra sub-rede. A correção de / etc / hosts é uma solução, mas parece uma correção temporária para um problema maior, certo? Obrigado.

Estou me perguntando se isso é um problema subjacente com o driver mongodb nativo? Também estou vendo problemas ao conectar-se a conjuntos de réplicas por meio do Heroku. É apenas um bombardeio não conseguir encontrar um primário.

Eu não olhei, mas a menos que o driver nativo mongodb sendo usado entre as versões funcional e não funcional do mongoose tenha sido alterado, a falha não pode ser apenas do driver nativo.

+1 Revertendo para v4.5.10 funciona.

Versões de nó testadas contra

v7.7.3
v7.10.0
lts / boro

Versões do Mongoose testadas e falharam com "Nenhum primário encontrado"

5.6.2
5.7.0
5,8,5

Versões Mongo

3,2
2,6

Reprodutibilidade

Consistente

Alguma pista de onde começar a procurar por trás desse bug?

Este problema está relacionado a https://github.com/Automattic/mongoose/issues/4517? Embora esse problema esteja marcado como fechado, não tenho certeza se ele foi resolvido. As versões mais recentes ainda apresentam esse problema.

Eu verifiquei que esse erro existe no Azure CosmosDB usando a versão 4.9.10 do driver. Ele também existe no driver 4.5.10 com CosmosDB, a menos que você especifique &readPreference=secondary no final da string de conexão - então ele funciona bem.

@dtzar fair warning, apoiar CosmosDB / DocumentDB é atualmente um não objetivo para o mangusto. Se você optar por usar o mongoose com esses bancos de dados, você estará por conta própria.

O problema ainda existe no Mongoose 4.10.2

Eu conectei usando o driver nativo mongo e o problema ainda ocorria. Não é mangusto, mas sim os endereços IP das configurações do arquivo de configuração em cada um dos computadores do cluster. Você deve alterar o endereço IP para o endereço IP externo público e não o IP interno. Quando usei o serviço oficial Mongo Atlas, ele já estava configurado e pronto para funcionar, nenhuma modificação necessária no que diz respeito aos IPs.

@wayofthefuture você está se referindo ao CosmosDB? Também percebi que a conexão com o CosmosDB funcionava por meio do Mongoose 4.5.10 se você remover o & replicaset = globaldb no final.

O problema ainda existe no Mongoose 4.10.2
Qualquer atualização?

Este problema não está mais presente com a versão mais recente do Mongoose, pelo que posso ver ao conectar ao CosmosDB usando a API do MongoDB, desde que você especifique a string de conexão no seguinte formato:

mongodb://myservername:[email protected]:10255/mydbname?ssl=true&replicaSet=globaldb

É importante ressaltar o fato de que mydbname não está presente por padrão no portal do Azure e deve ser inserido ou a conexão IRÁ falhar com o problema mencionado acima. Não importa o valor fornecido para mydbname, mas ele deve estar lá.

Tente corrigir o nome do host do servidor mongodb em /etc/hosts , por exemplo:

1.2.3.4 mdb01 mdb01.example.com
1.2.3.5 mdb02 mdb02.example.com
1.2.3.6 mdb03 mdb03.example.com

Espero que esta ajuda!

Usando V. 4.11.5 no Heroku. - No começo eu tive os mesmos problemas, resolvi apenas adicionando replicaSet à string de conexão:

mongodb://user:[email protected],mongolayer.com/database?replicaSet=database

Observe que o valor passado como replicaSet é igual ao nome do banco de dados. Não tentei usar nomes diferentes.

Eu espero que isso ajude.

Solução:

    options.replset = {
      socketOptions: {
        connectTimeoutMS: 60000, 
        keepAlive: 120
      }
    };

configurar / etc / hosts funciona para mim

Eu acho que você pode abrir a conexão de bússola e cluster na guia da web e escolher conectar-se à bússola e o aplicativo de bússola detecta automaticamente a conexão :)

Recebo o mesmo erro no Nó 8. O Nó 6 funciona bem. Alguma ideia?

Erro: não é possível determinar o estado do servidor
em canCheckoutReader (PATH_TO / node_modules / connect-mongo / node_modules / mongodb / lib / mongodb / connection / server.js: 779: 12)
em Server.checkoutReader (PATH_TO / node_modules / connect-mongo / node_modules / mongodb / lib / mongodb / connection / server.js: 793: 16)
em Cursor.nextObject (PATH_TO / node_modules / connect-mongo / node_modules / mongodb / lib / mongodb / cursor.js: 748: 48)
em Collection.findOne (PATH_TO / node_modules / connect-mongo / node_modules / mongodb / lib / mongodb / collection / query.js: 162: 10)
em PATH_TO / node_modules / connect-mongo / lib / connect-mongo.js: 223: 18
em MongoStore._get_collection (PATH_TO / node_modules / connect-mongo / lib / connect-mongo.js: 156: 21)
em MongoStore.get (PATH_TO / node_modules / connect-mongo / lib / connect-mongo.js: 222: 10)
na sessão (PATH_TO / node_modules / express-session / index.js: 367: 11)
em Layer.handle [como handle_request] (PATH_TO / node_modules / express / lib / router / layer.js: 82: 5)
em trim_prefix (PATH_TO / node_modules / express / lib / router / index.js: 269: 13)
em PATH_TO / node_modules / express / lib / router / index.js: 236: 9
em Function.proto.process_params (PATH_TO / node_modules / express / lib / router / index.js: 311: 12)
em PATH_TO / node_modules / express / lib / router / index.js: 227: 12
em Function.match_layer (PATH_TO / node_modules / express / lib / router / index.js: 294: 3)
a seguir (PATH_TO / node_modules / express / lib / router / index.js: 188: 10)
em cookieParser (PATH_TO / node_modules / cookie-parser / index.js: 48: 5)

Versão do Nó
v6.13.0 -> TRABALHOS
v8.10.0 -> Lança esse erro. O mongoose é compatível com o Node8?

lista npm | mangusto grep
├─┬ [email protected]
│ ├── [email protected]

lista npm | grep mongodb
│ └── [email protected] estranho
├─┬ [email protected] inválido
│ └── [email protected] estranho
│ ├─┬ [email protected]
│ │ └─┬ [email protected]

O Mongoose se conecta ao Mongos na porta 26000. Posso me conectar ao Mongodb com Robomongo

@sravzpublic, por favor, olhe atentamente para o rastreamento da pilha, ele mostra que o erro está no connect-mongo e não tem nada a ver com o mongoose. FWIW, o mangusto oferece suporte ao nó 8.

Também experimentamos isso no Mongoose 5.2.12 ( muito mais recente do que o relatado aqui ) no NodeJS 6.x - Não tive muito tempo para aprofundar ainda: /

Estou recebendo este problema em "mongoose": "^ 5.4.19" e forneci exemplos em um stackoverflow aberto aqui: https://stackoverflow.com/questions/55637808/mongoerror-no-mongos-proxy-available-when -conectando ao conjunto de réplicas. É preocupante que este pareça ser um problema aberto por tanto tempo e até mesmo através de uma atualização de versão. Hmm....

PS: Se alguém descobrir isso, você pode fornecer um exemplo completo de trabalho? Há recomendações para soluções neste tópico onde eu nem sei qual versão eles estão usando ...

Enfrentei esse problema no nó 8, atualizei para o nó 10 e tenho esses pacotes e reestruturei minha lógica de conexão mongodb abaixo. Funcionou.

cat package.json | grep mongo
"connect-mongo": "^ 2.0.1",
"mongodb": "> = 3.0.4",
"mangusto": "> = 5.0.11",

node -v
v10.4.1

db.version ()
3.4.15

config.db = mongodb://user:pass<strong i="14">@host</strong>:26000/dbname?ssl=true

// Get Mongoose to use the global promise library
mongoose.Promise = global.Promise;
var db = mongoose.connect(config.db, {
    auto_reconnect: true,
    socketTimeoutMS: 0,
    connectTimeoutMS: 0
  },
  function (err) {
    if (err) {
      console.error(chalk.red('Could not connect to MongoDB!' + err));
      console.log(chalk.red(err));
    }
  });

// When successfully connected
mongoose.connection.on('connected', function () {
 };

// If the connection throws an error
mongoose.connection.on('error', function (err) {
  console.log('Mongoose default connection error: ' + err);
});

// When the connection is disconnected
mongoose.connection.on('disconnected', function () {
  console.log('Mongoose default connection disconnected');
});

process.on('SIGINT', function () {
  mongoose.connection.close(function () {
    console.log('Mongoose default connection disconnected through app termination');
    process.exit(0);
  });
});

Acho que o problema está no host: (cluster0-shard Budap-vmyny.mongodb.net) use o principal.

Vou fechar isso, parece que o problema é com o connect-mongo, não com o mongoose.

Esta página foi útil?
0 / 5 - 0 avaliações