Mongoose: {useUnifiedTopology: true} leva ao erro de conexão do MongoDB: MongoTimeoutError: A seleção do servidor expirou após 30000 ms

Qual imagem do docker você usa? Além disso, você tem um rastreamento de pilha para a mensagem 'Tempo limite de seleção do servidor esgotado'?

Ei, apenas cutucando aqui para relatar que tive o mesmo problema.

Eu mesmo não estou usando Docker ou qualquer vm. Também é importante observar que isso não parece acontecer o tempo todo, no entanto, hoje não consegui recuperar nenhum dos meus dados devido a tempos limite (30k) e o problema foi resolvido imediatamente ao remover a sinalização useUnifiedTopology .

Estou me conectando a um cluster Atlas.

Mongoose é 5.7.1
MongoDb é 3.3.2
O nó é 12.9.1

Conectando assim:

mongoose.createConnection(uri,
    {
        useCreateIndex: true,
        useNewUrlParser: true,
        useUnifiedTopology: true, // commented out currently
        dbName: db_name
    });

O modelo é criado assim:

import mongoose from 'mongoose';
import * as db_conns from '../db-connections'; // this is an object of connections generated via createConnection

// ... schema definition, for a model called 'article' from a collection called 'article'

// `site_content` is the name of a connection
export default db_conns.connections.site_content.model(`article`, schema, `article`);

Em seguida, é obtido assim:

// ...
await query.model.find(query_expr).limit(30); // query_expr can change, however even an empty expression ({}) will cause the same issue
// ...

A chamada find trava e emite o erro de tempo limite.

@ vkarpov15 Estou usando a imagem mongo mais recente que fornece o MongoDB v4.2.0.
https://hub.docker.com/_/mongo

Também estou recebendo o mesmo erro depois de adicionar {useUnifiedTopology: true}, embora o erro esteja ocorrendo aleatoriamente. Há algo definitivamente errado. Estou usando a imagem mongo mais recente.

mangusto
.connect (process.env.MONGO_URI, {
useUnifiedTopology: true,
useNewUrlParser: true,
})
.então (() => console.log ('DB conectado!'))
.catch (err => {
console.log (Erro, err.message);
});
Quando começa, chego ao console:
[Função: Erro] {stackTraceLimit: 16, prepareStackTrace: undefined} conexão 0 para acccluster-shard-00-01-xx47j.mongodb. líquido: 27017 fechado

Alguma solução? Até eu estou enfrentando esse problema agora ...

Eu tenho o mesmo problema. Sou um programador júnior e é a primeira vez que uso nodejs-express-graphql-mongoose-mongodbAtlas.

(nó: 9392) UnhandledPromiseRejectionWarning: MongoTimeoutError: A seleção do servidor expirou após 30000 ms
em Timeout.setTimeout (MyAppPathgraphql2node_modulesmongodblibcoresdamtopology.js: 850: 16)
em ontimeout (timers.js: 436: 11)
em tryOnTimeout (timers.js: 300: 5)
em listOnTimeout (timers.js: 263: 5)
em Timer.processTimers (timers.js: 223: 10)
(nó: 9392) UnhandledPromiseRejectionWarning: Rejeição de promessa não tratada. Esse erro foi originado ao lançar dentro de uma função assíncrona sem um bloco catch ou ao rejeitar uma promessa que não foi tratada com .catch (). (id de rejeição: 1)
(nó: 9392) [DEP0018] Aviso de depreciação: Rejeições de promessa não tratadas foram descontinuadas. No futuro, as rejeições de promessa que não são tratadas encerrarão o processo Node.js com um código de saída diferente de zero.
events.js: 174
jogue er; // Evento de 'erro' não tratado
^

Erro: leia ECONNRESET
em TLSWrap.onStreamRead (internal / stream_base_commons.js: 111: 27)
Evento de 'erro' emitido em:
em TLSSocket.(MyAppPathnode_modulesmongodblibcoreconnectionconnection.js: 321: 10)
em Object.onceWrapper (events.js: 286: 20)
em TLSSocket.emit (events.js: 198: 13)
em emitErrorNT (internal / streams / destroy.js: 91: 8)
em emitErrorAndCloseNT (internal / streams / destroy.js: 59: 3)
em process._tickCallback (internal / process / next_tick.js: 63: 19)

Também estamos recebendo o mesmo erro em nosso servidor de produção após ativar useUnifiedTopology .

MongoTimeoutError: Server selection timed out after 30000 ms
    at Timeout.setTimeout [as _onTimeout] (/opt/app/node_modules/mongodb/lib/core/sdam/topology.js:850:16)
    at ontimeout (timers.js:498:11)
    at tryOnTimeout (timers.js:323:5)
    at Timer.listOnTimeout (timers.js:290:5)

Comecei a encontrar outro problema agora
MaxListenersExceededWarning: Possível vazamento de memória EventEmitter detectado. 11 ouvintes topologyDescriptionChanged adicionados.

Quando pesquisei este aviso, encontrei este documento mongoDB
https://jira.mongodb.org/browse/NODE-2123

Ele declara ambos os erros
"Tempo limite de seleção do servidor esgotado" e "MaxListenersExceededWarning" e ambos os erros são devidos à alteração da topologia unificada. Eu acho que essa foi uma mudança significativa que nunca foi mencionada.

Como estou encontrando esse erro em meu servidor ativo, não tenho escolha a não ser definir {useUnifiedTopology: false}. Espero que alguém da comunidade possa se concentrar neste problema e resolvê-lo ou fornecer algumas sugestões para resolvê-lo.

Também estou recebendo os dois erros (a seleção do servidor atingiu o tempo limite após 30000 ms e MaxListenersExceededWarning: possível vazamento de memória EventEmitter detectado. 11 ) ao usar useUnifiedTopology, então isso está acontecendo com todos que usam essa opção, eu acho.

Tentei reproduzir isso, mas não consegui reproduzir. Tentei algumas opções:

1) Matar o servidor antes de consultar

2) Consultando com uma conexão desconectada

3) Execução bem-sucedida de uma consulta

Ainda não vi essa mensagem de erro em nenhum caso. Você pode modificar o script abaixo para demonstrar esse problema?

'use strict';

const mongoose = require('mongoose');

run().catch(err => console.log(err));

async function run() {
  mongoose.set('useUnifiedTopology', true);
  mongoose.set('useNewUrlParser', true);

  await mongoose.connect('mongodb://localhost:27017/test');

  const Model = mongoose.model('Test', new mongoose.Schema({ name: String }));

  console.log('Query...');
  await Model.findOne();
  console.log('Done');
}

Ou pelo menos forneça algumas informações sobre qual versão do Mongoose você está usando; se você está usando um servidor independente, conjunto de réplicas ou cluster fragmentado; e se você está usando o Mongoose diretamente ou por meio de outro módulo npm?

Estou bastante convencido de que este não é um problema do mangusto, mas do próprio Mongo.

@ vkarpov15 , por favor, veja meu comentário , eu delineei meu ambiente lá. Estou usando o mangusto diretamente.

@ vkarpov15 para mim, esse problema aparece aleatoriamente a cada 2-3 dias quando o servidor está em execução, portanto, mesmo que eu forneça o código, você terá que monitorar o servidor continuamente.

Alguém conseguiu contornar esse problema?

Alguém conseguiu contornar esse problema?

Você simplesmente não pode usar este sinalizador por enquanto. O Mongo irá avisá-lo que será desativado no futuro ou algo assim, mas por enquanto parece resolver totalmente o problema.

Alguém conseguiu contornar esse problema?

Você simplesmente não pode usar este sinalizador por enquanto. O Mongo irá avisá-lo que será desativado no futuro ou algo assim, mas por enquanto parece resolver totalmente o problema.

quando eu não uso a sinalização useUnifiedTopology: true, tenho este erro e o aplicativo parou,
versão do mangusto: 5.7.4

Posso confirmar que comentar useUnifiedTopology out resolve o problema na minha compilação. Também acontecendo de forma (aparentemente) aleatória.

@rpedroni Infelizmente, não é para nós ...

Também está acontecendo aqui. Nosso servidor de produção responde com a mensagem abaixo. Acho que vou comentar useUnifiedTopology por enquanto

Opções de conexão do MongoDB

var options = {
    useCreateIndex: true,
    useNewUrlParser: true,
    useFindAndModify: false,
    useUnifiedTopology: true,
    promiseLibrary: global.Promise
};

Log do servidor

MongoTimeoutError: Server selection timed out after 30000 ms 
Oct 16 12:56:31 app/web.1:     at Timeout.setTimeout (/app/node_modules/mongodb/lib/core/sdam/topology.js:850:16) 
Oct 16 12:56:31 app/web.1:     at Shim.applySegment (/app/node_modules/newrelic/lib/shim/shim.js:1424:20) 
Oct 16 12:56:31 app/web.1:     at Timeout.wrappedCallback [as _onTimeout] (/app/node_modules/newrelic/lib/shim/shim.js:1281:21) 
Oct 16 12:56:31 app/web.1:     at ontimeout (timers.js:436:11) 
Oct 16 12:56:31 app/web.1:     at tryOnTimeout (timers.js:300:5) 
Oct 16 12:56:31 app/web.1:     at listOnTimeout (timers.js:263:5) 
Oct 16 12:56:31 app/web.1:     at Timer.processTimers (timers.js:223:10) 

Também estamos tendo esse problema e não usamos mangusto. Parece ser um problema com o driver MongoDB para o próprio Node.js. O problema também foi relatado aqui https://jira.mongodb.org/browse/NODE-2249
A versão 3.3.3 do driver que foi publicada hoje deve adicionar mais detalhes ao MongoTimeoutError . Também é recomendado atualizar o driver devido a uma correção de bug.

Este erro é o resultado de o driver não conseguir se conectar a um servidor que satisfaça a preferência de leitura de uma determinada operação (ou conexão inicial). Isso pode ocorrer por vários motivos, incluindo a string de conexão ser inválida ou os nós do cluster inativos. Se você atualizar para a v3.3.3 mais recente do driver, incluímos um novo campo de motivo com o MongoTimeoutError, que nos ajudará a investigar seu problema. Além disso, esta versão inclui uma correção de bug que resultaria em um erro de tempo limite na conexão inicial se algum membro de um replicaset não estivesse disponível. Atualize seu driver e informe-nos se continuar enfrentando esse problema.

Citado em https://jira.mongodb.org/browse/NODE-2249?focusedCommentId=2485028&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment -2485028

O mesmo aqui, acontece tanto no desenvolvimento quanto na produção, conectando-se ao Mongo Atlas :(

Também tem esse problema ao se conectar ao atlas mongodb. Normalmente acontece depois que o atlas reinicia ou atualiza o servidor ou algo semelhante.

Ainda não consigo reproduzir isso localmente com um conjunto de réplicas. O script a seguir continua a executar consultas com êxito, mesmo com failover do conjunto de réplicas ou eliminando o primário. Não obtenha nenhum erro de tempo limite de seleção de servidor:

'use strict';

const mongoose = require('mongoose');

run().catch(err => console.log(err));

async function run() {
  mongoose.set('useUnifiedTopology', true);
  mongoose.set('useNewUrlParser', true);

  await mongoose.connect('mongodb://localhost:27017,localhost:27018,localhost:27019/test?replicaSet=rs');

  const Model = mongoose.model('Test', new mongoose.Schema({ name: String }));


  while (true) {
    console.log(new Date(), 'Query...');
    await Model.findOne();
    await new Promise(resolve => setTimeout(resolve, 5000));
  }
} 

Meu melhor palpite é que a explicação de @rvanmil está correta. Tente atualizar para [email protected] (que enviarei em algumas horas) e veja se o problema persiste.

Além disso, alguém sabe se há uma maneira de acionar uma reinicialização no Atlas? Talvez esse problema ocorra apenas se você estiver usando o Atlas?

@ vkarpov15 Acho que você precisa pausar / retomar o cluster para iniciar uma reinicialização. Só é possível em tamanhos M10 +.
Eu também me pergunto se isso pode ser um problema do Atlas. Ainda não consegui testar o driver MongoDB atualizado, mas apresentarei um relatório aqui assim que o fizer.

Também estou tendo o mesmo problema hoje com o nível gratuito do Atlas, independentemente do sinalizador useUnifiedTopology. Erro: MongoTimeoutError: Server selection timed out after 30000 ms

Posso obter uma conexão usando outro serviço MongoDB, como o mLab.

Eu estava com o mesmo problema e acabou sendo algo meio estúpido, mas vou compartilhar mesmo assim porque pode ajudar alguém que acaba aqui também.

Eu verifiquei o campo 'motivo' no MongoTimeoutError e ele disse 'MongoError: autenticação inválida Falha na autenticação.'
Foi quando percebi que estava usando a senha do mongoDB em minha string de conexão e não a senha do usuário.
Agora funciona bem.

Se você estiver usando o MongoDB Atlas, deve colocar seu endereço IP na lista de permissões.

Vá para Acesso à rede, edite o endereço IP atual e clique em Permitir acesso de qualquer lugar.

Estou apenas enfrentando esse problema ao usar o Atlas. Tentei adicionar 0.0.0.0/0 IP na lista de permissões, mas também não funcionou.

Estou usando:

• mangusto: 5.7.6
• nó: v10.16.3
• Nível gratuito Atlas

Não foi possível reproduzir no servidor mongodb local. Lá, todas as consultas funcionam com sucesso.

Isso não tem nada a ver com acesso. Eu tenho acesso 0/0/0/0 e isso ocorre
toda vez que o servidor for reiniciado no atlas. Você pode reproduzir fazendo um nó múltiplo
cluster (m10 +) e definir o tempo de manutenção programada. Em seguida, execute um longo
executando o serviço e deve produzir o erro ao reiniciar.

Na quarta-feira, 23 de outubro de 2019, 7h42, Mohammad Mazedul Islam, <
notificaçõ[email protected]> escreveu:

Estou apenas enfrentando esse problema ao usar o Atlas. Eu tentei adicionar
0.0.0.0/0 IP na lista de permissões, mas também não funcionou.

Estou usando:

• mangusto: 5.7.6
• nó: v10.16.3
• Nível gratuito Atlas

Não foi possível reproduzir no servidor mongodb local. Lá, cada consulta simplesmente funciona
com sucesso.

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/Automattic/mongoose/issues/8180?email_source=notifications&email_token=AAUHUCYYQIQ5U42IBYT7CQTQQA2B7A5CNFSM4IYQ3ZB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECBDC4I#issuecomment-545403249 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/AAUHUCY5SNFGGCPTGW6GH5DQQA2B7ANCNFSM4IYQ3ZBQ
.

Eu também costumava ter esse problema. Mas agora, depois de colocar 0.0.0.0/0 e meu endereço IP na lista de permissões do atlas, resolve o problema.

https://jira.mongodb.org/browse/NODE-2147

~ Este é apenas um problema com o MongoDB Atlas. ~

Tenho alguns problemas ao usar o MongoDB Atlas.

Eu tenho o mesmo problema ao usar o MongoDB normal.

Eu reproduzi com sucesso a condição que causa "MongoTimeoutError: Tempo limite de seleção do servidor esgotado após 30000" usando docker-compose.
https://github.com/anzairyo0127/mongodb-connection-bug

Primeiro inicie este aplicativo

$ docker-compose up -d
$ docker-compose exec a mongo /tmp/conf/init.js
$ docker-compose exec node sh
$ npm i && npm run build
$ npm run start

> 0times
> waiting ....
> {_id: 5db27454b77b210040f2f84e, id: 1, text: 'hogehoge'}
> 1times
> waiting ....
> {_id: 5db27454b77b210040f2f84e, id: 1, text: 'hogehoge'}
> xtimes
> waiting ....
> {_id: 5db27454b77b210040f2f84e, id: 1, text: 'hogehoge'}
> ......



md5-cc5c53b3c0322ef988c85b63b4bb6c4e



$ docker-compose restart a b c



md5-788ff0ed4e46daf35b1b8594351b929f



> xtimes
> waiting ....
> (node: 4360) UnhandledPromiseRejectionWarning: MongoTimeoutError: Server selection timed out after 30000 ms
> at Timeout.setTimeout [as _onTimeout] (/var/work/node_modules/mongodb/lib/core/sdam/topology.js:878:9)
> at ontimeout (timers.js: 436: 11)
> at tryOnTimeout (timers.js: 300: 5)
> at listOnTimeout (timers.js: 263: 5)
> at Timer.processTimers (timers.js: 223: 10)
> (node: 4360) UnhandledPromiseRejectionWarning: Unhandled promise rejection.This error originated either by throwing inside of an> async function without a catch block, or by rejecting a promise which was not handled with .catch (). (rejection id: 1)
> (node: 4360) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that
> are not handled will terminate the Node.js process with a non-zero exit code.

@ anzairyo0127 você pode tentar o mesmo com a biblioteca mongodb 3.3.3 mais recente?

@rvanmil posso reproduzi-lo na versão 3.3.3.

Parece que esse erro ocorre quando o mongoDB está em configuração de replicação e uma das instâncias (provavelmente a instância primária) recebe um comando antes de desligar ou logo após sua inicialização.
Acho que a razão pela qual isso acontece com frequência no MongoDB Atlas é que o MongoDB Atlas envia regularmente consultas ao cluster para monitoramento.

Alguma solução? Este problema é ....

O mesmo problema há mais de 1 mês e ainda não foi resolvido -_-

Atualizar para [email protected] resolveu para mim.

@octavioamu Você pode fornecer mais detalhes? Qual versão do banco de dados MongoDB [cluster] você estava executando antes da 4.2? Qual versão dos pacotes mongoose e mongodb npm você está usando e atualizou-os? Há quanto tempo você está executando a 4.2 para ter certeza de que está resolvido nesta versão?

desculpe, não sei qual versão foi instalada, provavelmente uma muito antiga já que eu não trabalhei com o mongo por um tempo.
A versão do mangusto está em @ 5.7.7
A mensagem era permanente para mim e assim que instalei o [email protected] (instalado via brew), a mensagem parou.

Se eu definir {useUnifiedTopology: false} , obtenho uma falha de autenticação

(node:19948) UnhandledPromiseRejectionWarning: MongoNetworkError: failed to connect to server [localhost:27017] on first connect [MongoError: Authentication failed.]

e se eu definir {useUnifiedTopology: true} , terei um tempo limite

(node:20213) UnhandledPromiseRejectionWarning: MongoTimeoutError: Server selection timed out after 30000 ms

A senha está definitivamente correta. Isso pode ser reproduzido em um sistema local com as versões mais recentes de tudo e LST Node.js. No entanto, o uso da string de conexão sem qualquer tipo de autenticação parece funcionar localmente. Portanto, se eu definir, por exemplo, const MONGODB_URI = "mongodb://localhost/fullstack" problema de tempo limite desaparece. Talvez esse problema tenha algo a ver com autenticação? Aqui está o MWE, que reproduz o problema na minha configuração local:

const mongoose = require('mongoose')
// const url = 'mongodb://fullstack:fullstack@localhost/fullstack'
const url = 'mongodb://localhost/fullstack'
console.log('Connection url = ', url, 'connecting')
mongoose.connect(url, { useNewUrlParser: true, useUnifiedTopology: true })
console.log('Connected.')
mongoose.connection.close()

Usei a imagem Docker mais recente para a configuração do MongoDB.

Também está acontecendo aqui. Nosso servidor de produção responde com a mensagem abaixo. Acho que vou comentar useUnifiedTopology por enquanto

Opções de conexão do MongoDB

var options = {
    useCreateIndex: true,
    useNewUrlParser: true,
    useFindAndModify: false,
    useUnifiedTopology: true,
    promiseLibrary: global.Promise
};

Log do servidor

MongoTimeoutError: Server selection timed out after 30000 ms 
Oct 16 12:56:31 app/web.1:     at Timeout.setTimeout (/app/node_modules/mongodb/lib/core/sdam/topology.js:850:16) 
Oct 16 12:56:31 app/web.1:     at Shim.applySegment (/app/node_modules/newrelic/lib/shim/shim.js:1424:20) 
Oct 16 12:56:31 app/web.1:     at Timeout.wrappedCallback [as _onTimeout] (/app/node_modules/newrelic/lib/shim/shim.js:1281:21) 
Oct 16 12:56:31 app/web.1:     at ontimeout (timers.js:436:11) 
Oct 16 12:56:31 app/web.1:     at tryOnTimeout (timers.js:300:5) 
Oct 16 12:56:31 app/web.1:     at listOnTimeout (timers.js:263:5) 
Oct 16 12:56:31 app/web.1:     at Timer.processTimers (timers.js:223:10) 

Também está acontecendo aqui. Nosso servidor de produção responde com a mensagem abaixo. Acho que vou comentar useUnifiedTopology por enquanto

Opções de conexão do MongoDB

var options = {
    useCreateIndex: true,
    useNewUrlParser: true,
    useFindAndModify: false,
    useUnifiedTopology: true,
    promiseLibrary: global.Promise
};

Log do servidor

MongoTimeoutError: Server selection timed out after 30000 ms 
Oct 16 12:56:31 app/web.1:     at Timeout.setTimeout (/app/node_modules/mongodb/lib/core/sdam/topology.js:850:16) 
Oct 16 12:56:31 app/web.1:     at Shim.applySegment (/app/node_modules/newrelic/lib/shim/shim.js:1424:20) 
Oct 16 12:56:31 app/web.1:     at Timeout.wrappedCallback [as _onTimeout] (/app/node_modules/newrelic/lib/shim/shim.js:1281:21) 
Oct 16 12:56:31 app/web.1:     at ontimeout (timers.js:436:11) 
Oct 16 12:56:31 app/web.1:     at tryOnTimeout (timers.js:300:5) 
Oct 16 12:56:31 app/web.1:     at listOnTimeout (timers.js:263:5) 
Oct 16 12:56:31 app/web.1:     at Timer.processTimers (timers.js:223:10) 

Estou usando o mongo db atlas e estamos enfrentando o mesmo problema.

dub-tools-jobs: orders - error MongoTimeoutError: Server selection timed out after 30000 ms 
Oct 29 13:16:30 app/worker.1:      at Timeout.setTimeout [as _onTimeout] (/app/node_modules/mongoose/node_modules/mongodb/lib/core/sdam/topology.js:850:16) 
Oct 29 13:16:30 app/worker.1:     at ontimeout (timers.js:436:11) 
Oct 29 13:16:30 app/worker.1:     at tryOnTimeout (timers.js:300:5) 
Oct 29 13:16:30 app/worker.1:     at listOnTimeout (timers.js:263:5) 
Oct 29 13:16:30 app/worker.1:     at Timer.processTimers (timers.js:223:10) +2m

tudo isso aconteceu com o comentário de useUnifiedTopology como uma recomendação sugerida

// mongodb connections
var options = {
    useCreateIndex: true,
    useNewUrlParser: true,
    useFindAndModify: false,
    // useUnifiedTopology: true,      
    promiseLibrary: global.Promise
};

usando mongoose e mongoDB atlas, certifique-se de que as opções sejam as seguintes:
mongoose.connect (DATABASE_URL, {useNewUrlParser: true, useUnifiedTopology: true})

Depois disso, se o tempo limite chegar, você precisará colocar seu endereço IP na lista de permissões do mongoDB acessando o acesso à rede no mongoDB

Como outros, esse erro trava meu aplicativo a cada poucos dias e posso confirmar que isso não está relacionado ao acesso ou à lista de permissões do endereço IP.

Estou usando:

• mangusto: 5.7.6
• nó: v10.16.3
• Nível gratuito Atlas

Por enquanto, comentarei useUnifiedTopology: true também. Parece que pode estar relacionado a Atlas ou mongo, como outros afirmaram.

Este é um problema com servidores de conjunto de réplicas MongoDB e uma solução está sendo trabalhada aqui por engenheiros do MongoDB

https://jira.mongodb.org/browse/NODE-2267

@ vkarpov15 provavelmente pode

quando seu endereço IP atual muda por algum motivo, a conexão falha, você deve editá-lo na lista de permissões de IP de acesso à rede e usar o IP atual

Oi! Meu nome é Matt e faço parte da equipe de motoristas do MongoDB. Sentimos muito pelas interrupções que vocês têm enfrentado e gostaria de fornecer uma pequena atualização sobre o problema:

Estamos tentando eliminar gradualmente nossos tipos de topologia legados, o que se revelou um processo muito cirúrgico. Eliminar esses tipos ajudará muito a reduzir a carga de manutenção do driver, e esperamos que isso signifique um driver mais estável e eficiente para nossos usuários. Em particular, ao apresentar a "Topologia Unificada", também não introduzimos a reescrita do pool de conexão em um esforço para reduzir o potencial de erro. Acontece que o pool de conexão estava mais fortemente acoplado aos tipos de topologia do que prevíamos e, como resultado, experimentamos algumas regressões, especialmente em torno do monitoramento do servidor.

Esta manhã eu empurrei um v3.3.4-rc0 do driver que deve resolver os problemas que você tem enfrentado. Ficaríamos extremamente gratos se você pudesse experimentar esta versão e relatar sua experiência. Deixei comentários sobre cada um dos tíquetes existentes relacionados a esse problema no NODE-2267 , mas sinta-se à vontade para abrir outros problemas lá, se você os tiver.

Posso confirmar que o 3.3.4-rc0 corrigiu o problema 👍 Fornecerei resultados de teste mais detalhados posteriormente.

depois que mudei minha versão mongodb em package.json para
"mongodb": "3.3.4-rc0",
Sempre recebo erros (esse erro não acontece quando a versão do mongodb está em 3.3.3):

=================================================
npm ERR! caminho / tmp / app / node_modules / npm / node_modules / abbrev
npm ERR! código ENOENT
npm ERR! errno -2
npm ERR! syscall renomear
npm ERR! enoent ENOENT: nenhum arquivo ou diretório, renomear '/ tmp / app / node_modules / npm / node_modules / abbrev' -> '/tmp/app/node_modules/npm/node_modules/.abbrev.DELETE'
npm ERR! enoent Isto está relacionado ao npm não ser capaz de encontrar um arquivo.
npm ERR! enoent
npm ERR! Um registro completo desta execução pode ser encontrado em:
npm ERR! /home/vcap/.npm/_logs/2019-11-06T17_19_55_661Z-debug.log
[31; 1m ERROR [0m Incapaz de construir dependências: sair do status 254
Falha ao compilar droplet: Falha ao executar todos os scripts de suprimentos: status de saída 14
Status de saída 223

======================================
minha versão npm é npm em 6.11.3.

Este erro está relacionado com esta nova compilação do mongodb v3.3.4-rc0?

@zhenwan, parece um problema ao baixar o pacote abbrev . Meu palpite é que há problemas com seu package-lock.json , tente excluir esse arquivo e executar npm install novamente.

Consegui reproduzir o erro e verificar se foi resolvido com o driver v3.3.4-rc0 usando a seguinte configuração:

• Node.js webserver expondo um http api GET /api/todos simples que consulta uma coleção todo MongoDB que contém alguns dados de amostra
• Script que chama a api a cada 500ms rodando localmente na minha máquina
• Assim que o script estiver em execução, acione um failover (reinicie o primário) no MongoDB (no Atlas, consegui fazer isso em um cluster M10 selecionando a opção de menu "Testar failover")

Os resultados deste teste foram os seguintes:

✅ Mongodb Node.js 3.3.2 useUnifiedTopology false

> MongoDB failover triggered
> MongoDB 'reconnect' event
> A few http calls with +/- 5000ms response times
> MongoDB failover finished
> Everything back to normal

❌ Mongodb Node.js 3.3.2 useUnifiedTopology true

> MongoDB failover triggered
> MongoDB 'close' event
> Many MongoNetworkError errors
    {
      "name": "MongoNetworkError",
      "stack": "Error: connect ECONNREFUSED <ip_redacted>:27017
          at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1128:14)",
      "errorLabels": [
        "TransientTransactionError"
      ]
    }
> EventEmitter memory leak warning
    (node:18) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 topologyDescriptionChanged listeners added to [NativeTopology]. Use emitter.setMaxListeners() to increase limit
> Many MongoTimeoutError errors
    {
      "name": "MongoTimeoutError",
      "stack": "MongoTimeoutError: Server selection timed out after 30000 ms
          at Timeout._onTimeout (/app/node_modules/mongodb/lib/core/sdam/topology.js:850:16)
          at listOnTimeout (internal/timers.js:531:17)
          at processTimers (internal/timers.js:475:7)"
    }
> MongoDB failover finished
> Server unable to recover MongoDB connection
> Server restarted manually
> Everything back to normal

⚠️ Mongodb Node.js 3.3.4-rc0 useUnifiedTopology true

> MongoDB failover triggered
> MongoDB 'reconnect' event expected but not seen
> A few http calls with +/- 5000ms response times
> A couple failed http calls:
    {
      "name": "MongoError",
      "stack": "MongoError: Cache Reader No keys found for HMAC that is valid for time: { ts: Timestamp(1573064656, 1) } with id: 6756219367492419585
          at Connection.<anonymous> (/app/node_modules/mongodb/lib/core/connection/pool.js:451:61)
          at Connection.emit (events.js:210:5)
          at processMessage (/app/node_modules/mongodb/lib/core/connection/connection.js:368:10)
          at TLSSocket.<anonymous> (/app/node_modules/mongodb/lib/core/connection/connection.js:537:15)
          at TLSSocket.emit (events.js:210:5)
          at addChunk (_stream_readable.js:308:12)
          at readableAddChunk (_stream_readable.js:289:11)
          at TLSSocket.Readable.push (_stream_readable.js:223:10)
          at TLSWrap.onStreamRead (internal/stream_base_commons.js:182:23)",
      "ok": 0,
      "errmsg": "Cache Reader No keys found for HMAC that is valid for time: { ts: Timestamp(1573064656, 1) } with id: 6756219367492419585",
      "code": 211,
      "codeName": "KeyNotFound"
    }
> MongoDB failover finished
> Everything back to normal

Portanto, parece funcionar com v3.3.4-rc0 , o servidor é capaz de recuperar a conexão e retomar o serviço de dados do MongoDB. No entanto, ainda existem dois problemas:

• O evento 'reconectar' parece estar faltando
• Algumas solicitações falham com a mensagem de erro "Leitor de cache Nenhuma chave encontrada para HMAC válida por tempo"

@mbroadst sim, deletar package-lock.json resolveu meu problema de falta de arquivo.

Mas ainda recebo o erro:
2019-11-06T12: 52: 10.35-0600 [CELL / 0] OUT O contêiner tornou-se íntegro
06-11-2019T12: 52: 39.06-0600 [APP / PROC / WEB / 0] ERR /home/vcap/app/node_modules/connect-mongo/src/index.js:135
2019-11-06T12: 52: 39.06-0600 [APP / PROC / WEB / 0] ERR lançar err
06-11-2019T12: 52: 39.06-0600 [APP / PROC / WEB / 0] ERR ^
2019-11-06T12: 52: 39.06-0600 [APP / PROC / WEB / 0] ERR Erro: a seleção do servidor expirou após 30000 ms
2019-11-06T12: 52: 39.06-0600 [APP / PROC / WEB / 0] ERR at Timeout.setTimeout [as _onTimeout] (/ home / vcap / app / node_modules / connect-mongo / node_modules / mongodb / lib / core /sdam/topology.js:878:9)
06-11-2019T12: 52: 39.06-0600 [APP / PROC / WEB / 0] ERR no ontimeout (timers.js: 469: 11)
06-11-2019T12: 52: 39.06-0600 [APP / PROC / WEB / 0] ERR em tryOnTimeout (timers.js: 304: 5)
2019-11-06T12: 52: 39.06-0600 [APP / PROC / WEB / 0] ERR at Timer.listOnTimeout (timers.js: 264: 5)
06-11-2019T12: 52: 39.35-0600 [APP / PROC / WEB / 0] SAÍDA Status de saída 1

@zhenwan parece que pode estar relacionado a não ser capaz de se conectar ao seu cluster na conexão inicial. Além disso, seu backtrace para topology.js:878 curiosamente não aponta para um lugar onde um erro é gerado, nem você está recebendo o tipo correto MongoTimeoutError .

Você pode abrir um novo tíquete da Jira para que possamos fazer a triagem do seu caso específico. Parece que precisaremos de mais detalhes do que os que você colou aqui. Obrigado!

@mbroadst
Obrigado por ajudar a resolver o problema. Só quero dizer que usar a v3.3.4-rc0 não está resolvendo meu problema. Eu ainda estou recebendo esta mensagem

MongoTimeoutError: Server selection timed out after 30000 ms
    at Timeout.setTimeout (api/node_modules/mongodb/lib/core/sdam/topology.js:899:9)
    at ontimeout (timers.js:498:11)
    at tryOnTimeout (timers.js:323:5)
    at Timer.listOnTimeout (timers.js:290:5)

No meu caso, estou usando loopback-connector-mongodb , mas configurei meu package.json para forçar o uso da última versão de mongodb em resolutions como segue

"resolutions": {
    "mongodb": "^3.3.4-rc0"
  }

meus parâmetros de conexão como segue

"host": "127.0.0.1",
 "port": 27017,
"database": "***",
"password": "***",
"user": "***",
"authSource": "***",
"useNewUrlParser": true,
"enableGeoIndexing": true

abaixo estão meus parâmetros de ambiente

MongoDB server version: 3.6.3 on localhost
yarn v1.19.1
node v8.16.2 

desde já, obrigado

atualizar
Também tentei adicionar useUnifiedTopology: true aos parâmetros de conexão, mas obtive o mesmo resultado.

Outra confirmação aqui, de alguém usando o mangusto diretamente, que useUnifiedTopology: false funciona para mim.

@mbroadst, obrigado pela atualização do final do MongoDB. Desculpe minha ignorância, mas a correção mencionada no mongodb v3.3.4-rc0 cairá em cascata para o mangusto em algum ponto? Um pouco desconfortável com a ideia de adotar recursos obsoletos como uma solução alternativa em um ambiente de produção.

@mmmmoj semelhante à pergunta de package-lock.json ? Você pode, por favor, preencher um tíquete de Jira para que possamos nos aprofundar nos detalhes do seu caso.

@bigsee (cara, o GitHub _não_ gosta de preencher automaticamente o seu nome!) Fico feliz em saber que funciona para você e você é bem-vindo para a atualização - nossa comunidade é muito importante para nós. Vou deixar @ vkarpov15 falar sobre o momento do lançamento, mas trabalhamos de perto e tenho certeza de que ele está interessado em consertar isso para vocês :)

@mbroadst
feito! Obrigado
NODE-2313

@mbroadst ha! desculpe pelo nome estranho!

Acontece que posso ter falado muito cedo, talvez devido à natureza aleatória do erro que apareceu. Em uma inicialização a frio do meu aplicativo, junto com o aviso de suspensão de uso esperado, agora vejo este erro um pouco mais assustador nos registros:

Unhandled rejection: { MongoNetworkError: failed to connect to server [myserver.mlab.com:55841] on first connect [{ MongoNetworkError: connection 0 to myserver.mlab.com:55841 timed out
    at Socket.<anonymous> (/var/task/node_modules/mongodb/lib/core/connection/connection.js:335:7)
    at Object.onceWrapper (events.js:313:30)
    at emitNone (events.js:106:13)
    at Socket.emit (events.js:208:7)
    at Socket._onTimeout (net.js:420:8)
    at ontimeout (timers.js:482:11)
    at tryOnTimeout (timers.js:317:5)
    at Timer.listOnTimeout (timers.js:277:5) name: 'MongoError', [Symbol(mongoErrorContextSymbol)]: {} }]
    at Pool.<anonymous> (/var/task/node_modules/mongodb/lib/core/topologies/server.js:431:11)
    at emitOne (events.js:116:13)
    at Pool.emit (events.js:211:7)
    at connect (/var/task/node_modules/mongodb/lib/core/connection/pool.js:580:14)
    at callback (/var/task/node_modules/mongodb/lib/core/connection/connect.js:109:5)
    at provider.auth.err (/var/task/node_modules/mongodb/lib/core/connection/connect.js:352:21)
    at _authenticateSingleConnection (/var/task/node_modules/mongodb/lib/core/auth/auth_provider.js:66:11)
    at sendAuthCommand (/var/task/node_modules/mongodb/lib/core/auth/scram.js:177:16)
    at Connection.errorHandler (/var/task/node_modules/mongodb/lib/core/connection/connect.js:321:5)
    at Object.onceWrapper (events.js:317:30)
    at emitTwo (events.js:126:13)
    at Connection.emit (events.js:214:7)
    at Socket.<anonymous> (/var/task/node_modules/mongodb/lib/core/connection/connection.js:333:10)
    at Object.onceWrapper (events.js:313:30)
    at emitNone (events.js:106:13)
    at Socket.emit (events.js:208:7)
  name: 'MongoNetworkError',
  errorLabels: [ 'TransientTransactionError' ],
  [Symbol(mongoErrorContextSymbol)]: {} }

Costumava ser MongoTimeoutError mas agora é MongoNetworkError ... ... alguma ideia?

@bigsee esse erro indicaria que você _não_ está usando a topologia unificada. Ative-o passando useUnifiedTopology: true para o seu MongoClient

@mbroadst está correto, o que eu acredito ser o ponto desta edição. Peço desculpas se estou errado nisso.

Quando eu passo useUnifiedTopology: true o aviso de descontinuação desaparece, mas meu aplicativo trava aleatoriamente com o erro de título deste problema MongoTimeoutError: Server selection timed out after 30000 ms .

Tal como acontece com @ vkarpov15 e outros acima, não consegui reproduzir este problema de forma consistente. O erro acontece algumas vezes por dia, resultando em erros 502 e UX horrível de vez em quando. Parece ser um novo problema.

Conforme relatado acima, a solução alternativa de definir useUnifiedTopology: false (ou comentar) evita o erro neste problema, mas restaura o aviso de depreciação e agora o MongoNetworkError um pouco mais assustador acima. À parte, isso não mata meu aplicativo, mas me preocupa que isso vá acontecer para um usuário em algum momento.

@bigsee o MongoNetworkError você está enfrentando não é novo e significa que o driver não conseguiu fazer uma conexão inicial com um cluster (incidentalmente, se algum tipo de condição de corrida entre o início do seu aplicativo e o início do cluster estiver causando isso, então a topologia unificada deve ajudar aqui também).

O ponto desse problema é que as pessoas estavam seguindo a orientação para usar a topologia unificada e, quando o faziam, estavam enfrentando erros de tempo limite espúrios. v3.3.4-rc0 foi lançado para resolver esse problema específico, então a orientação atual é usar essa versão que deve remover o aviso de depreciação e corrigir os problemas de tempo limite espúrios que as pessoas encontraram.

Devo dizer também: esta versão não evitará _todos_ os erros de tempo limite. Esse erro está sendo causado pela incapacidade do driver de fazer uma conexão inicial a um cluster, o que indicaria algum tipo de configuração (string de conexão) ou erro de rede de sua parte. Com a topologia unificada, isso aparecerá como um MongoTimeoutError com um campo reason indicando o erro de rede que causou o tempo limite na conexão inicial.

@mbroadst Não tive a MongoNetworkError fosse novo em meu último comentário, então desculpe se foi assim que se leu. É o `MongoTimeoutError que é novo. Para ser mais claro, espero que este tenha sido o meu processo:

1. o aplicativo foi configurado com useUnifiedTopology: true - tudo funcionando conforme o esperado
2. aplicativo começa a falhar aleatoriamente e apresenta um MongoTimeoutError correspondente ao título deste problema, bem como as primeiras linhas de um rastreamento de pilha apresentado acima
3. uma pesquisa no Google / SO eventualmente me traz aqui
4. Eu uso useUnifiedTopology: false solução alternativa sugerida
5. o erro MongoTimeoutError desaparece junto com o travamento do aplicativo. no entanto, ele foi substituído pelo aviso de reprovação inicialmente. então, mais tarde, por um adicional de MongoNetworkError não visto no aplicativo antes de definir useUnifiedTopology: false

Talvez, como você sugere, isso seja correlação, e não causalidade. Pareceu-me uma arma fumegante. Pelo menos o aplicativo não está travando agora. Só estou preocupado em deixar uma opção que está obsoleta.

@bigsee Ah! Desculpe, eu interpretei mal seu comentário original para significar que você estava confirmando que as v3.3.4-rc0 correções de bug resolveram seus problemas de v3.3.3 . Você já teve a chance de experimentar a nova versão?

Esta é minha primeira tentativa no Mongodb e estou tendo este erro. leia os comentários e mudei meu banco de dados para v3.3.4-rc0 e ainda não corrigiu o erro

Aviso de descontinuação: o mecanismo atual de descoberta e monitoramento do servidor foi descontinuado e será removido em uma versão futura. Para usar o novo mecanismo de descoberta e monitoramento do servidor, passe a opção {useUnifiedTopology: true} para o construtor MongoClient.
MongoNetworkError: falha ao conectar ao servidor [cluster0-shard-00-00-rhdve.mongodb. net: 27017 ] na primeira conexão [MongoNetworkError: conexão 3 ao cluster0-shard-00-00-rhdve.mongodb. líquido: 27017 fechado
em TLSSocket.(C: laragonwwwVue-express-mongodbnode_modulesmongodblibcoreconnectionconnection.js: 356: 9)
em Object.onceWrapper (events.js: 297: 20)
em TLSSocket.emit (events.js: 209: 13)
em net.js: 588: 12
em TCP.done (_tls_wrap.js: 479: 7) {
nome: 'MongoNetworkError',
errorLabels: [Array],
}]
em Pool.(C: laragonwwwVue-express-mongodbnode_modulesmongodblibcoretopologiesserver.js: 433: 11)
em Pool.emit (events.js: 209: 13)
em C: laragonwwwVue-express-mongodbnode_modulesmongodblibcoreconnectionpool.js: 562: 14
em C: laragonwwwVue-express-mongodbnode_modulesmongodblibcoreconnectionpool.js: 999: 9
no retorno de chamada (C: laragonwwwVue-express-mongodbnode_modulesmongodblibcoreconnectionconnect.js: 109: 5)
em C: laragonwwwVue-express-mongodbnode_modulesmongodblibcoreconnectionconnect.js: 129: 7
em Connection.errorHandler (C: laragonwwwVue-express-mongodbnode_modulesmongodblibcoreconnectionconnect.js: 321: 5)
em Object.onceWrapper (events.js: 297: 20)
em Connection.emit (events.js: 209: 13)
em TLSSocket.(C: laragonwwwVue-express-mongodbnode_modulesmongodblibcoreconnectionconnection.js: 354: 12) {
nome: 'MongoNetworkError',
errorLabels: ['TransientTransactionError'],
}
TypeError: Não é possível ler a propriedade 'encontrar' de indefinido
em C: laragonwwwVue-express-mongodbserverroutesapiposts.js: 12: 26

@ Syfon01 o erro que você está enfrentando é devido a algum tipo de erro de configuração, o driver está usando a topologia legada e falhou em fazer sua conexão inicial a um cluster após um padrão de 10s. Verifique sua string de conexão e configuração de rede e verifique se você consegue se conectar ao cluster (talvez com o shell mongo ). Se você ainda estiver tendo problemas, abra um tíquete jira para que possamos continuar a conversa lá e não confunda as pessoas olhando para este problema do GitHub

Para as pessoas que estão tendo esse problema, se você estiver usando a instância da nuvem do Mongo Atlas, verifique se seu endereço IP está especificado corretamente na guia Acesso à rede.

Tive o problema e parece que, uma vez que meu ISP fornece Novos IPs sempre que (DHCP) eu me reconecto à rede, o Mongo Atlas só estava na lista branca do endereço IP especificado anteriormente. Espero que isso ajude alguém.

atualização - não funciona

Consegui resolver esse problema alterando a estrutura do meu código, especificamente o retorno de chamada da seguinte maneira:

mongoose.connect(DATABASE_URL, {
    useNewUrlParser: true,
    useUnifiedTopology: true,
}).then(() => {
    console.log('Connected to DB');
    app.listen({ port: PORT }, () => {
        console.log(`Server running at http://localhost:${PORT}`)
    });
}).catch(err => console.log(err));

mongoose.connect(DATABASE_URL, { 
    useNewUrlParser: true, 
    useUnifiedTopology: true,
}, () => {
    console.log('Connected to DB');
    app.listen({ port: PORT }, () => {
        console.log(`Server running at http://localhost:${PORT}`);
    });
}).catch(err => console.log(err));

@ mtn2bay que não faz nenhum sentido você basicamente usou a função de retorno de chamada em vez da promessa, o resultado ainda é o mesmo, a única diferença é que na função de retorno de chamada você obtém a conexão e o erro na função de retorno de chamada que você não está registrando em vez de depender de .then e .catch, então sua função está registrando conectado ao db e iniciando o aplicativo de qualquer maneira, mesmo se houver um erro. tente isso ao invés

mongoose.connect(DATABASE_URL, { 
    useNewUrlParser: true, 
    useUnifiedTopology: true,
}, (err, connection) => {
if(err) {
console.error(err)
return
}    
console.log('Connected to DB');
    app.listen({ port: PORT }, () => {
        console.log(`Server running at http://localhost:${PORT}`);
    })

@khaledosman obrigado pela correção. Você está certo, eu estava apenas ignorando o erro, em vez de corrigi-lo. Na verdade, tive um problema com meu caminho de banco de dados.

Eu estava enfrentando o mesmo problema, atualizei o pacote mongoose npm de 5.6.9 para 5.7.6 e o ​​problema desapareceu.

Para as pessoas que estão tendo esse problema, se você estiver usando a instância da nuvem do Mongo Atlas, verifique se seu endereço IP está especificado corretamente na guia Acesso à rede.

Tive o problema e parece que, uma vez que meu ISP fornece Novos IPs sempre que (DHCP) eu me reconecto à rede, o Mongo Atlas só estava na lista branca do endereço IP especificado anteriormente. Espero que isso ajude alguém.

resolveu meu problema
UnhandledPromiseRejectionWarning: MongoTimeoutError: Server selection timed out after 30000 ms at Timeout.setTimeout (C:\Users\Umer MIB\Desktop\Chatbots2\mongobot\node_modules\mongodb\lib\core\sdam\topology.js:878:9) at ontimeout (timers.js:436:11) at tryOnTimeout (timers.js:300:5) at listOnTimeout (timers.js:263:5) at Timer.processTimers (timers.js:223:10) (node:4304) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1) (node:4304) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code

Não sei como isso resolveu um problema, mas baixei o Compass e conectei ao banco de dados, apenas copiei o link. Depois de conectado, o erro desapareceu. A topologia ainda é verdadeira em meu código. Talvez ele tenha configurado algumas opções com o Compass que não estavam certas com a instalação usual do mongodb. Agora posso me conectar sem Compass e tudo parece funcionar, apenas uma vez no início.

Eu tive o mesmo problema e, graças a este fórum, consegui passar comentando a configuração de useUnifiedTopology. No entanto, eu descomentei essa configuração, mas agora ela ainda funciona bem ... bastante confuso ...

O Mongoose v5.7.11 usa o driver MongoDB 3.3.4 recém-lançado, portanto, encerrarei este problema. Se você estiver recebendo uma mensagem de erro semelhante, abra um novo problema e siga o modelo de problema.