Mongoose: { useUnifiedTopology: true } führt zu MongoDB-Verbindungsfehler: MongoTimeoutError: Zeitüberschreitung der Serverauswahl nach 30000 ms

Welches Docker-Image verwendest du? Haben Sie auch einen Stack-Trace für die Meldung 'Serverauswahl Zeitüberschreitung'?

Hey, schaue nur hier rein, um zu berichten, dass ich das gleiche Problem hatte.

Ich selbst verwende weder Docker noch eine VM. Zu beachten ist auch, dass dies nicht die ganze Zeit zu passieren scheint, aber heute konnte ich aufgrund von Zeitüberschreitungen (30k) keine meiner Daten abrufen, und das Problem wurde sofort behoben, als das useUnifiedTopology Flag entfernt wurde .

Ich verbinde mich mit einem Atlas-Cluster.

Mungo ist 5.7.1
MongoDB ist 3.3.2
Knoten ist 12.9.1

Anschließen wie folgt:

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

Das Modell wird wie folgt erstellt:

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`);

Dann wird es so geholt:

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

Der find Aufruf bleibt hängen und gibt den Timeout-Fehler aus.

@vkarpov15 Ich verwende das neueste mongo Image, das MongoDB v4.2.0 bereitstellt.
https://hub.docker.com/_/mongo

Ich erhalte auch den gleichen Fehler, nachdem ich { useUnifiedTopology: true } hinzugefügt habe, obwohl der Fehler zufällig auftritt. Da stimmt definitiv etwas nicht. Ich verwende das neueste Mongo-Image.

Mungo
.connect(process.env.MONGO_URI, {
useUnifiedTopology: wahr,
useNewUrlParser: true,
})
.then(() => console.log('DB verbunden!'))
.catch(err => {
console.log(Fehler, err.message);
});
Beim Start erhalte ich an der Konsole:
[Funktion: Fehler] { stackTraceLimit: 16, PrepareStackTrace: undefined } Verbindung 0 zu acccluster-shard-00-01-xx47j.mongodb. Netz:27017 geschlossen

Irgendwelche Lösungen? Auch ich stehe jetzt vor diesem Problem...

Ich habe das gleiche Problem. Ich bin ein Junior-Programmierer und benutze zum ersten Mal nodejs-express-graphql-mongoose-mongodbAtlas.

(node:9392) UnhandledPromiseRejectionWarning: MongoTimeoutError: Zeitüberschreitung der Serverauswahl nach 30000 ms
at Timeout.setTimeout (MyAppPathgraphql2node_modulesmongodblibcoresdamtopology.js:850:16)
bei ontimeout (timers.js:436:11)
bei tryOnTimeout (timers.js:300:5)
bei listOnTimeout (timers.js:263:5)
bei Timer.processTimers (timers.js:223:10)
(node:9392) UnhandledPromiseRejectionWarning: Nicht behandelte Ablehnung von Zusagen. Dieser Fehler entstand entweder durch das Einfügen in eine asynchrone Funktion ohne einen catch-Block oder durch das Zurückweisen eines Promises, das nicht mit .catch() verarbeitet wurde. (Ablehnungs-ID: 1)
(node:9392) [DEP0018] DeprecationWarning: Nicht behandelte Promise-Ablehnungen sind veraltet. Zukünftig wird der Node.js-Prozess bei Ablehnungen von Zusagen, die nicht verarbeitet werden, mit einem Exit-Code ungleich Null beendet.
events.js:174
werfen ähm; // Unbehandeltes 'Fehler'-Ereignis
^

Fehler: ECONNRESET lesen
bei TLSWrap.onStreamRead (intern/stream_base_commons.js:111:27)
Ausgegebenes 'Fehler'-Ereignis bei:
bei TLSSocket.(MyAppPathnode_modulesmongodblibcoreconnectionconnection.js:321:10)
bei Object.onceWrapper (events.js:286:20)
bei TLSSocket.emit (events.js:198:13)
at emitErrorNT (internal/streams/destroy.js:91:8)
at emitErrorAndCloseNT (internal/streams/destroy.js:59:3)
at process._tickCallback (internal/process/next_tick.js:63:19)

Wir erhalten den gleichen Fehler auch auf unserem Produktionsserver, nachdem wir useUnifiedTopology aktiviert haben.

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)

Ich habe jetzt ein anderes Problem festgestellt
MaxListenersExceededWarning: Möglicher EventEmitter-Speicherverlust erkannt. 11 topologyDescriptionChanged-Listener hinzugefügt.

Als ich nach dieser Warnung suchte, stieß ich auf dieses mongoDB-Dokument
https://jira.mongodb.org/browse/NODE-2123

Es gibt beide Fehler an
"Server selection timed out" sowie "MaxListenersExceededWarning" und beide Fehler sind auf die einheitliche Topologieänderung zurückzuführen. Ich denke, das war eine bahnbrechende Änderung, die nie erwähnt wurde.

Da dieser Fehler auf meinem Live-Server auftritt, habe ich keine andere Wahl, als { useUnifiedTopology: false } zu setzen. Ich hoffe, jemand aus der Community kann sich auf dieses Problem konzentrieren und es lösen oder einige Vorschläge zur Lösung machen.

Ich erhalte auch beide Fehler ( nach 30000 ms abgelaufen und ich useUnifiedTopology verwende, wahrscheinlich jedem, der diese Option verwendet.

Ich habe versucht, dies zu reproduzieren, aber ich konnte nicht repro. Ich habe ein paar Möglichkeiten ausprobiert:

1) Beenden des Servers direkt vor der Abfrage

2) Abfragen bei unterbrochener Verbindung

3) Erfolgreiches Ausführen einer Abfrage

Diese Fehlermeldung habe ich auf jeden Fall noch nicht gesehen. Können Sie bitte das folgende Skript ändern, um dieses Problem zu demonstrieren?

'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');
}

Oder geben Sie zumindest einige Informationen darüber, welche Version von Mongoose Sie verwenden; unabhängig davon, ob Sie einen eigenständigen Server, einen Replikatsatz oder einen Shard-Cluster verwenden; und ob Sie Mongoose direkt oder über ein anderes npm-Modul verwenden?

Ich bin ziemlich überzeugt, dass dies kein Problem mit Mungo ist, sondern mit Mongo selbst.

@vkarpov15 , siehe meinen Kommentar , ich habe dort meine Umgebung skizziert. Ich verwende Mungo direkt.

@vkarpov15 für mich tritt dieses Problem zufällig alle 2-3 Tage auf, wenn der Server läuft. Selbst wenn ich Ihnen den Code zur Verfügung

Hat jemand dieses Problem umgangen?

Hat jemand dieses Problem umgangen?

Sie können dieses Flag vorerst nicht verwenden. Mongo wird Sie warnen, dass es in Zukunft deaktiviert wird oder so, aber vorerst scheint es dieses Problem vollständig zu lösen.

Hat jemand dieses Problem umgangen?

Sie können dieses Flag vorerst nicht verwenden. Mongo wird Sie warnen, dass es in Zukunft deaktiviert wird oder so, aber vorerst scheint es dieses Problem vollständig zu lösen.

Wenn ich das Flag useUnifiedTopology: true nicht verwende, habe ich diesen Fehler und die App wurde gestoppt.
Mungo Version: 5.7.4

Kann bestätigen, dass das Auskommentieren von useUnifiedTopology das Problem in meinem Build löst. Auch geschieht in einer (scheinbar) zufälligen Weise.

@rpedroni Leider nicht für uns...

Auch hier passiert. Unser Produktionsserver antwortet mit der folgenden Nachricht. Ich denke, ich werde vorerst useUnifiedTopology kommentieren

MongoDB-Verbindungsoptionen

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

Serverprotokoll

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) 

Wir haben dieses Problem auch und verwenden keinen Mungo. Es scheint ein Problem mit dem MongoDB-Treiber für Node.js selbst zu sein. Das Problem wurde auch hier gemeldet https://jira.mongodb.org/browse/NODE-2249
Die heute veröffentlichte Version 3.3.3 des Treibers soll dem MongoTimeoutError weitere Details hinzufügen. Es wird auch empfohlen, den Treiber aufgrund eines Bugfixes zu aktualisieren.

Dieser Fehler ist darauf zurückzuführen, dass der Treiber keine Verbindung zu einem Server herstellen kann, der die Lesepräferenz einer bestimmten Operation (oder anfänglichen Verbindung) erfüllt. Dies kann verschiedene Gründe haben, darunter eine ungültige Verbindungszeichenfolge oder ausgefallene Knoten in Ihrem Cluster. Wenn Sie auf die neueste Version 3.3.3 des Treibers aktualisieren, fügen wir dem MongoTimeoutError ein neues Ursachenfeld hinzu, das uns hilft, Ihr Problem weiter zu untersuchen. Darüber hinaus enthält diese Version eine Fehlerbehebung, die zu einem Zeitüberschreitungsfehler bei der ersten Verbindung führen würde, wenn ein Mitglied eines Replikatsatzes nicht verfügbar war. Bitte aktualisieren Sie Ihren Treiber und teilen Sie uns mit, wenn dieses Problem weiterhin auftritt.

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

Das Gleiche passiert hier sowohl in der Entwicklung als auch in der Produktion, die Verbindung zu Mongo Atlas :(

Habe auch dieses Problem beim Verbinden mit Mongodb Atlas. Dies geschieht normalerweise, nachdem Atlas einen Serverneustart oder ein Update oder ähnliches durchgeführt hat.

Daher kann ich dies immer noch nicht lokal mit einem Replikatsatz reproduzieren. Das folgende Skript führt Abfragen weiterhin erfolgreich aus, auch wenn ein Replikatsatz-Failover oder ein Beenden des primären Systems erforderlich ist. Keine Zeitüberschreitungsfehler bei der Serverauswahl erhalten:

'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));
  }
} 

Meine beste Vermutung ist, dass die Erklärung von [email protected] zu aktualisieren (das ich in ein paar Stunden versende) und prüfen Sie, ob dieses Problem weiterhin besteht.

Weiß jemand, ob es eine Möglichkeit gibt, einen Neustart in Atlas auszulösen? Vielleicht tritt dieses Problem nur auf, wenn Sie Atlas verwenden?

@vkarpov15 Ich denke, Sie müssen den Cluster
Ich frage mich auch, ob dies möglicherweise stattdessen ein Atlas-Problem ist. Ich konnte den aktualisierten MongoDB-Treiber noch nicht testen, werde mich aber hier wieder melden, sobald ich dies getan habe.

Ich habe heute auch das gleiche Problem mit der kostenlosen Atlas-Stufe, unabhängig von der useUnifiedTopology-Flagge. Fehler: MongoTimeoutError: Server selection timed out after 30000 ms

Ich kann eine Verbindung mit einem anderen MongoDB-Dienst wie mLab herstellen.

Ich hatte das gleiche Problem und es war etwas dumm, aber ich werde es trotzdem teilen, weil es jemandem helfen kann, der auch hier landet.

Ich habe das Feld 'Grund' im MongoTimeoutError überprüft und es sagte 'MongoError: Bad Auth Authentication failed.'
Da wurde mir klar, dass ich das mongoDB-Passwort in meiner Verbindungszeichenfolge und nicht das Benutzerpasswort verwendet habe.
Jetzt funktioniert es gut.

Wenn Sie MongoDB Atlas verwenden, sollten Sie Ihre IP-Adresse auf die Whitelist setzen.

Gehen Sie zu Netzwerkzugriff, bearbeiten Sie die aktuelle IP-Adresse und klicken Sie auf Zugriff von überall zulassen.

Ich habe dieses Problem nur, wenn ich Atlas verwende. Ich habe versucht, 0.0.0.0/0 IP in der Whitelist hinzuzufügen, aber es hat auch nicht funktioniert.

Ich benutze:

• Mungo: 5.7.6
• Knoten: v10.16.3
• Kostenlose Atlas-Stufe

Konnte auf lokalem Mongodb-Server nicht reproduziert werden. Dort funktioniert jede Abfrage einfach erfolgreich.

Das hat nichts mit Zugang zu tun. Ich habe 0/0/0/0 Zugriff und das passiert
jedes Mal, wenn der Server auf Atlas neu gestartet wird. Sie können reproduzieren, indem Sie einen Multi-Node erstellen
Cluster (m10+) und Einstellen der geplanten Wartungszeit. Dann lauf lange
Ausführen des Dienstes und es sollte den Fehler erzeugen, wenn es neu gestartet wird.

Am Mi., 23.10.2019, 7:42 Uhr Mohammad Mazedul Islam, <
[email protected]> schrieb:

Ich habe dieses Problem nur, wenn ich Atlas verwende. Ich habe versucht hinzuzufügen
0.0.0.0/0 IP in Whitelist, aber es hat auch nicht funktioniert.

Ich benutze:

• Mungo: 5.7.6
• Knoten: v10.16.3
• Kostenlose Atlas-Stufe

Konnte auf lokalem Mongodb-Server nicht reproduziert werden. Dort funktioniert jede Abfrage einfach
erfolgreich.

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/Automattic/mongoose/issues/8180?email_source=notifications&email_token=AAUHUCYYQIQ5U42IBYT7CQTQQA2B7A5CNFSM4IYQ3ZB2YY3PNVWWK3TUL52HS4DFVREXG43VMVZJKTORDN5
oder abmelden
https://github.com/notifications/unsubscribe-auth/AAUHUCY5SNFGGCPTGW6GH5DQQA2B7ANCNFSM4IYQ3ZBQ
.

Das Problem hatte ich auch mal. Aber jetzt, nachdem ich sowohl 0.0.0.0/0 als auch meine IP-Adresse auf die Whitelist von Atlas gesetzt habe, löst sich das Problem.

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

~Dies ist nur ein Problem mit MongoDB Atlas.~

Ich habe ein Problem mit MongoDB Atlas.

Ich habe das gleiche Problem mit normaler MongoDB.

Ich habe erfolgreich die Bedingung reproduziert, die "MongoTimeoutError: Server selection timed out after 30000" mit docker-compose verursacht.
https://github.com/anzairyo0127/mongodb-connection-bug

Starten Sie zuerst diese Anwendung

$ 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 können Sie dasselbe mit der neuesten 3.3.3 mongodb-Bibliothek versuchen?

@rvanmil Ich kann es in Version

Es scheint, als ob dieser Fehler auftritt, wenn sich die mongoDB in der Replikationskonfiguration befindet und eine der Instanzen (wahrscheinlich die primäre Instanz) einen Befehl erhält, kurz bevor sie herunterfährt oder direkt nach ihrem Start.
Ich denke, der Grund, warum dies bei MongoDB Atlas häufig vorkommt, ist, dass MongoDB Atlas regelmäßig Anfragen zur Überwachung an den Cluster sendet.

Irgendwelche Lösungen? Dieses Problem ist ....

Das gleiche Problem seit mehr als 1 Monat und es ist noch nicht gelöst -_-

Ein Update auf

@octavioamu Können Sie genauere Angaben machen? Welche Version der MongoDB-Datenbank [Cluster] haben Sie vor 4.2 ausgeführt? Welche Version der mongoose- und mongodb-npm-Pakete verwenden Sie und haben Sie diese aktualisiert? Wie lange laufen Sie schon mit 4.2, um sicher zu sein, dass es in dieser Version gelöst ist?

tut mir leid, weiß nicht welche Version installiert war, wahrscheinlich eine sehr alte, da ich eine Weile nicht mit mongo gearbeitet habe.
Die Mungo-Version ist auf @5.7.7
Die Nachricht war für mich permanent und sobald ich die [email protected] installiert hatte (über brew installiert), hörte die Nachricht auf.

Wenn ich {useUnifiedTopology: false} setze, erhalte ich einen Authentifizierungsfehler

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

und wenn ich {useUnifiedTopology: true} setze, bekomme ich eine Zeitüberschreitung

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

Das Passwort ist definitiv richtig. Dies kann auf einem lokalen System mit den neuesten Versionen von Everything und LST Node.js reproduziert werden. Die Verwendung einer Verbindungszeichenfolge ohne Authentifizierung scheint jedoch lokal zu funktionieren. Wenn ich also zB const MONGODB_URI = "mongodb://localhost/fullstack" setze, verschwindet das Zeitüberschreitungsproblem. Hat dieses Problem vielleicht etwas mit der Authentifizierung zu tun? Hier ist MWE, das das Problem in meinem lokalen Setup reproduziert:

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()

Ich habe das neueste Docker-Image für das MongoDB-Setup verwendet.

Auch hier passiert. Unser Produktionsserver antwortet mit der folgenden Nachricht. Ich denke, ich werde vorerst useUnifiedTopology kommentieren

MongoDB-Verbindungsoptionen

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

Serverprotokoll

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) 

Auch hier passiert. Unser Produktionsserver antwortet mit der folgenden Nachricht. Ich denke, ich werde vorerst useUnifiedTopology kommentieren

MongoDB-Verbindungsoptionen

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

Serverprotokoll

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) 

Ich benutze Mongo DB Atlas und wir stehen vor dem gleichen Problem.

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

Dies alles geschah mit dem Kommentar useUnifiedTopology, wie eine Empfehlung vorgeschlagen wurde

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

Stellen Sie mit mongoose und mongoDB Atlas sicher, dass die Optionen wie folgt sind:
mongoose.connect(DATABASE_URL, { useNewUrlParser: true, useUnifiedTopology: true })

Wenn danach eine Zeitüberschreitung auftritt, müssen Sie Ihre IP-Adresse von mongoDB auf die Whitelist setzen, indem Sie in mongoDB zum Netzwerkzugriff wechseln

Wie bei anderen stürzt dieser Fehler alle paar Tage meine App ab und ich kann bestätigen, dass dies nicht mit dem Zugriff oder der Whitelisting der IP-Adresse zusammenhängt.

Ich benutze:

• Mungo: 5.7.6
• Knoten: v10.16.3
• Kostenlose Atlas-Stufe

Im Moment werde ich auch useUnifiedTopology: true auskommentieren. Es scheint, dass es entweder mit Atlas oder Mongo zusammenhängt, wie andere gesagt haben.

Dies ist ein Problem mit MongoDB-Servern mit Replikatsätzen, und hier wird von MongoDB-Ingenieuren an einer Lösung gearbeitet

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

@vkarpov15 kann dieses Problem wahrscheinlich schließen, da es nichts mit

Wenn sich Ihre aktuelle IP-Adresse aus irgendeinem Grund ändert, schlägt die Verbindung fehl, Sie sollten sie in der IP-Whitelist für den Netzwerkzugriff bearbeiten und die aktuelle IP-Adresse verwenden

Hi! Mein Name ist Matt und ich bin im Fahrerteam von MongoDB. Es tut uns sehr leid für die Ausfälle, mit denen Sie konfrontiert waren, und ich wollte ein kleines Update zu diesem Problem geben:

Wir sind dabei, unsere alten Topologietypen auslaufen zu lassen, was sich als sehr chirurgischer Prozess herausgestellt hat. Das Auslaufen dieser Typen wird dazu beitragen, den Wartungsaufwand des Treibers erheblich zu reduzieren, und wir hoffen, dass dies für unsere Benutzer einen stabileren und effizienteren Treiber bedeutet. Insbesondere haben wir bei der Einführung der "Unified Topology" nicht auch das Rewrite des Connection Pools eingeführt, um das Fehlerpotential zu reduzieren. Es stellte sich heraus, dass der Verbindungspool enger an die Topologietypen gekoppelt war, als wir erwartet hatten, und infolgedessen erlebten wir einige Rückschritte, insbesondere bei der Serverüberwachung.

Heute Morgen habe ich eine gepusht , die die Probleme NODE-2267 hinterlassen, aber bitte

Ich kann bestätigen, dass 3.3.4-rc0 das Problem behoben hat 👍 Genauere Testergebnisse werde ich später liefern.

nachdem ich meine mongodb-Version in package.json zu . geändert habe
"mongodb": "3.3.4-rc0",
Ich erhalte immer einen Fehler (dieser Fehler tritt nicht auf, wenn die mongodb-Version auf 3.3.3 ist):

=============================================
npm ERR! Pfad /tmp/app/node_modules/npm/node_modules/abbrev
npm ERR! Code ENOENT
npm ERR! Fehler -2
npm ERR! Systemaufruf umbenennen
npm ERR! enoent ENOENT: keine solche Datei oder kein solches Verzeichnis, benennen Sie um in '/tmp/app/node_modules/npm/node_modules/abbrev' -> '/tmp/app/node_modules/npm/node_modules/.abbrev.DELETE'
npm ERR! enoent Dies hängt damit zusammen, dass npm eine Datei nicht finden kann.
npm ERR! enoent
npm ERR! Ein vollständiges Protokoll dieses Laufs finden Sie unter:
npm ERR! /home/vcap/.npm/_logs/2019-11-06T17_19_55_661Z-debug.log
[31;1m FEHLER [0m Abhängigkeiten können nicht aufgebaut werden: Exit-Status 254
Droplet konnte nicht kompiliert werden: Fehler beim Ausführen aller Versorgungsskripte: Beendigungsstatus 14
Ausgangsstatus 223

==================================
meine npm-Version ist npm bei 6.11.3.

Bezieht sich dieser Fehler auf diesen neuen mongodb v3.3.4-rc0-Build?

@zhenwan das sieht nach einem Problem beim Herunterladen des abbrev Pakets aus. Ich vermute, dass es Probleme mit Ihrem package-lock.json gibt. Bitte versuchen Sie, diese Datei zu löschen und npm install erneut auszuführen.

Ich konnte den Fehler reproduzieren und prüfen, ob er mit dem v3.3.4-rc0-Treiber mit folgendem Setup behoben wurde:

• Node.js-Webserver, der eine einfache http-API GET /api/todos bereitstellt, die eine todo MongoDB-Sammlung abfragt, die einige Beispieldaten enthält
• Skript, das die API alle 500 ms aufruft und lokal auf meinem Computer ausgeführt wird
• Sobald das Skript ausgeführt wird, lösen Sie ein Failover (Starten Sie das primäre) auf MongoDB aus (auf Atlas konnte ich dies auf einem M10-Cluster tun, indem ich die Menüoption "Failover testen" auswählte).

Die Ergebnisse dieses Tests waren wie folgt:

✅ 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

Es scheint also mit v3.3.4-rc0 zu funktionieren, der Server ist in der Lage, die Verbindung wiederherzustellen und die Bereitstellung von Daten von MongoDB wieder aufzunehmen. Es gibt jedoch noch zwei Probleme:

• Das Ereignis 'reconnect' scheint zu fehlen
• Einige Anfragen schlagen mit der Fehlermeldung "Cache Reader Keine Schlüssel für HMAC gefunden, die für eine Zeit gültig sind" fehl

@mbroadst ja, das Löschen von package-lock.json hat mein Problem mit fehlenden Dateien gelöst.

Aber ich bekomme immer noch den Fehler:
2019-11-06T12:52:10.35-0600 [CELL/0] OUT Container wurde fehlerfrei
2019-11-06T12:52:39.06-0600 [APP/PROC/WEB/0] FEHLER /home/vcap/app/node_modules/connect-mongo/src/index.js:135
2019-11-06T12:52:39.06-0600 [APP/PROC/WEB/0] ERR Wurffehler
2019-11-06T12:52:39.06-0600 [APP/PROC/WEB/0] FEHLER ^
2019-11-06T12:52:39.06-0600 [APP/PROC/WEB/0] ERR-Fehler: Serverauswahl nach 30000 ms abgelaufen
2019-11-06T12:52:39.06-0600 [APP/PROC/WEB/0] ERR bei Timeout.setTimeout [as _onTimeout] (/home/vcap/app/node_modules/connect-mongo/node_modules/mongodb/lib/core /sdam/topology.js:878:9)
2019-11-06T12:52:39.06-0600 [APP/PROC/WEB/0] ERR bei ontimeout (timers.js:469:11)
2019-11-06T12:52:39.06-0600 [APP/PROC/WEB/0] ERR bei tryOnTimeout (timers.js:304:5)
2019-11-06T12:52:39.06-0600 [APP/PROC/WEB/0] ERR bei Timer.listOnTimeout (timers.js:264:5)
2019-11-06T12:52:39.35-0600 [APP/PROC/WEB/0] OUT Ausgangsstatus 1

@zhenwan es sieht so aus, als ob es damit zusammenhängt, dass Sie beim ersten Verbinden keine Verbindung zu Ihrem Cluster herstellen können. Auch Ihr Backtrace zu topology.js:878 seltsamerweise nicht auf eine Stelle, an der ein Fehler generiert wird, noch erhalten Sie den richtigen Typ MongoTimeoutError .

Können Sie bitte ein neues Jira-Ticket eröffnen, damit wir Ihren speziellen Fall

@mbroadst
Vielen Dank für Ihre Hilfe bei der Behebung des Problems. Ich möchte nur sagen, dass die Verwendung von v3.3.4-rc0 mein Problem nicht löst. Ich bekomme immer noch diese Nachricht

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)

In meinem Fall verwende ich loopback-connector-mongodb , aber ich richte mein package.json , dass die Verwendung der letzten Version von mongodb in resolutions wie folgt erzwungen wird

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

meine Verbindungsparameter wie folgt

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

Unten sind meine Umgebungsparameter

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

Danke im Voraus

aktualisieren
Ich habe auch versucht, den Verbindungsparametern useUnifiedTopology: true hinzuzufügen, habe aber das gleiche Ergebnis erhalten.

Eine weitere Bestätigung hier von jemandem, der direkt Mungo verwendet, dass useUnifiedTopology: false für mich funktioniert.

@mbroadst danke für das Update vom Ende von MongoDB. Entschuldigen Sie meine Unwissenheit, aber wird der oben genannte Fix in Mongodb v3.3.4-rc0 irgendwann auf Mungo herunterfallen? Etwas unbehaglich mit der Idee, veraltete Funktionen als Workaround in einer Produktumgebung zu verwenden.

@mmmmoj Ähnlich wie bei der obigen Frage von package-lock.json entfernen? Können Sie bitte ein Jira-Ticket einreichen, damit wir uns mit den Besonderheiten Ihres Falles

@bigsee (man GitHub mag es _nicht_, deinen Namen automatisch zu vervollständigen!) Freut mich zu hören, dass es für dich funktioniert, und du bist willkommen für das Update - unsere Community ist uns sehr wichtig. Ich lasse @vkarpov15 für den Zeitpunkt der Veröffentlichung sprechen, aber wir arbeiten eng zusammen und ich bin sicher, dass er daran interessiert ist, dies für euch alle zu beheben :)

@mbroadst
getan! Vielen Dank
KNOTEN-2313

@mbroadst ha! sorry für den komischen namen!

es stellte sich heraus, dass ich möglicherweise zu früh gesprochen habe, vielleicht angesichts der zufälligen Natur des auftretenden Fehlers. Bei einem Kaltstart meiner App sehe ich jetzt zusammen mit der erwarteten Veraltungswarnung diesen etwas beängstigenderen Fehler in den Protokollen:

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)]: {} }

Früher waren es MongoTimeoutError aber jetzt sind es MongoNetworkError ... ...keine Ideen?

@bigsee Dieser Fehler würde darauf hinweisen, dass Sie die vereinheitlichte Topologie _nicht_ verwenden. Bitte aktivieren Sie es, indem Sie useUnifiedTopology: true an Ihr MongoClient

@mbroadst das ist richtig, was meiner Meinung nach der Punkt dieses Problems ist. Entschuldigung, wenn ich da falsch liege.

Wenn ich useUnifiedTopology: true verschwindet die Veraltungswarnung, aber meine App stürzt zufällig mit dem Titelfehler dieses Problems MongoTimeoutError: Server selection timed out after 30000 ms .

Wie bei @vkarpov15 und anderen oben konnte ich dieses Problem nicht konsistent reproduzieren. Der Fehler tritt ein paar Mal am Tag auf, was von Zeit zu Zeit zu 502 und schrecklichen UX-Fehlern führt. Es scheint ein neues Thema zu sein.

Wie oben berichtet, verhindert die Problemumgehung durch das Setzen von useUnifiedTopology: false (oder das Auskommentieren) den Fehler in diesem Problem, stellt jedoch die veraltete Warnung und jetzt den etwas beängstigenderen MongoNetworkError oben wieder her. Abgesehen davon tötet dies meine App nicht wirklich, macht mir jedoch Sorgen, dass dies für einen Benutzer irgendwann der Fall sein wird.

@bigsee das MongoNetworkError Sie erleben, ist nicht neu und bedeutet, dass der Treiber keine anfängliche Verbindung zu einem Cluster herstellen konnte (übrigens, wenn eine Art Race-Bedingung zwischen dem Starten Ihrer App und dem Starten Ihres Clusters verursacht wird.) dann sollte die vereinheitlichte Topologie auch hier helfen).

Der Punkt dieses Problems ist, dass die Benutzer den Anweisungen zur Verwendung der einheitlichen Topologie gefolgt sind, und wenn sie dies taten, traten falsche Zeitüberschreitungsfehler auf. v3.3.4-rc0 wurde veröffentlicht, um dieses spezielle Problem zu beheben, daher lautet die aktuelle Anleitung, diese Version zu verwenden, die den veralteten Hinweis entfernen und die falschen Timeout-Probleme beheben sollte, auf die die Leute gestoßen sind.

Ich sollte auch sagen: Diese Version wird _all_ Timeout-Fehler nicht verhindern. Dieser Fehler wird durch die Unfähigkeit des Treibers verursacht, eine anfängliche Verbindung zu einem Cluster herzustellen, was auf eine Art Konfiguration (Verbindungszeichenfolge) oder einen Netzwerkfehler Ihrerseits hinweisen würde. Bei der einheitlichen Topologie wird dies als MongoTimeoutError mit einem reason Feld angezeigt, das den Netzwerkfehler angibt, der die Zeitüberschreitung bei der ersten Verbindung verursacht hat.

@mbroadst Ich wollte nicht andeuten, dass das MongoNetworkError in meinem letzten Kommentar neu war, also entschuldige mich, wenn es so gelesen wird. Es ist der `MongoTimeoutError, der neu ist. Um hoffentlich klarer zu sein, war dies mein Prozess:

1. app hat config mit useUnifiedTopology: true - alles funktioniert wie erwartet
2. app stürzt nach dem Zufallsprinzip ab und zeigt ein MongoTimeoutError , das dem Titel dieser Ausgabe entspricht, sowie die ersten paar Zeilen eines oben gezeigten Stack-Trace
3. eine Google/SO-Suche bringt mich schließlich hierher
4. Ich verwende den vorgeschlagenen useUnifiedTopology: false Workaround
5. der MongoTimeoutError Fehler verschwindet zusammen mit dem Absturz der App. es wird jedoch zunächst durch die Veraltungswarnung ersetzt. dann, später, um weitere MongoNetworkError , die in der Anwendung nicht zu sehen sind, bevor useUnifiedTopology: false

Vielleicht ist dies, wie Sie vermuten, eher eine Korrelation als eine Kausalität. Kam mir nur wie eine rauchende Waffe vor. Zumindest stürzt die App jetzt nicht ab. Ich mache mir nur Sorgen, eine Option zu verlassen, die veraltet ist.

@bigsee Ah! Entschuldigung, ich habe Ihren ursprünglichen Kommentar falsch gelesen, um zu bedeuten, dass Sie bestätigen, dass die v3.3.4-rc0 Fehlerbehebungen Ihre Probleme von v3.3.3 gelöst haben. Hatten Sie die Gelegenheit, die neue Version auszuprobieren?

Dies ist mein erster Versuch auf Mongodb und ich habe diesen Fehler. lies dir die Kommentare durch und änderte meine db auf v3.3.4-rc0 und der Fehler wurde immer noch nicht behoben

DeprecationWarning: Die aktuelle Server Discovery and Monitoring Engine ist veraltet und wird in einer zukünftigen Version entfernt. Um das neue Server Discover and Monitoring-Modul zu verwenden, übergeben Sie die Option { useUnifiedTopology: true } an den MongoClient-Konstruktor.
MongoNetworkError: Verbindung zum Server [cluster0-shard-00-00-rhdve.mongodb. net:27017 ] beim ersten Verbinden [MongoNetworkError: Verbindung 3 zu cluster0-shard-00-00-rhdve.mongodb. Netz:27017 geschlossen
bei TLSSocket.(C:laragonwwwVue-express-mongodbnode_modulesmongodblibcoreconnectionconnection.js:356:9)
bei Object.onceWrapper (events.js:297:20)
bei TLSSocket.emit (events.js:209:13)
bei net.js:588:12
bei TCP.done (_tls_wrap.js:479:7) {
Name: 'MongoNetworkError',
errorLabels: [Array],
}]
am Pool.(C:laragonwwwVue-express-mongodbnode_modulesmongodblibcoretopologiesserver.js:433:11)
bei Pool.emit (events.js:209:13)
bei C:laragonwwwVue-express-mongodbnode_modulesmongodblibcoreconnectionpool.js:562:14
at C:laragonwwwVue-express-mongodbnode_modulesmongodblibcoreconnectionpool.js:999:9
bei Rückruf (C:laragonwwwVue-express-mongodbnode_modulesmongodblibcoreconnectionconnect.js:109:5)
at C:laragonwwwVue-express-mongodbnode_modulesmongodblibcoreconnectionconnect.js:129:7
at Connection.errorHandler (C:laragonwwwVue-express-mongodbnode_modulesmongodblibcoreconnectionconnect.js:321:5)
bei Object.onceWrapper (events.js:297:20)
bei Connection.emit (events.js:209:13)
bei TLSSocket.(C:laragonwwwVue-express-mongodbnode_modulesmongodblibcoreconnectionconnection.js:354:12) {
Name: 'MongoNetworkError',
errorLabels: [ 'TransientTransactionError' ],
}
TypeError: Eigenschaft 'find' von undefined kann nicht gelesen werden
at C:laragonwwwVue-express-mongodbserverroutesapiposts.js:12:26

@ Syfon01 Der Fehler, den Sie erfahren, ist auf einen Konfigurationsfehler zurückzuführen, der Treiber verwendet die Legacy-Topologie und kann nach einer Standardeinstellung von 10 mongo Shell). Wenn weiterhin Probleme auftreten, öffnen Sie bitte ein Jira-Ticket, damit wir die Unterhaltung dort fortsetzen können und die Leute, die sich dieses GitHub-Problem

Für Personen, bei denen dieses Problem auftritt: Wenn Sie Mongo Atlas Cloud Instance verwenden, überprüfen Sie bitte, ob Ihre IP-Adresse auf der Registerkarte Netzwerkzugriff korrekt angegeben ist.

Ich hatte das Problem und es scheint, dass Mongo Atlas, da mein ISP jedes Mal (DHCP) neue IPs ausgibt, wenn ich mich wieder mit dem Netzwerk verbinde, nur die zuvor angegebene IP-Adresse in der Whitelist auflistete. Hoffe das hilft jemandem.

aktualisieren - funktioniert nicht

Ich konnte dieses Problem lösen, indem ich die Struktur meines Codes, insbesondere den Rückruf, wie folgt änderte:

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 das macht keinen Sinn du hast im Grunde die Callback-Funktion statt des Versprechens verwendet, das Ergebnis ist immer noch ein und dasselbe, der einzige Unterschied ist, dass man in der Callback-Funktion sowohl die Verbindung als auch den Fehler in der Callback-Funktion bekommt die Sie nicht protokollieren, anstatt sich auf .then und .catch zu verlassen, sodass Ihre Funktion die Verbindung mit db protokolliert und die App so oder so startet, auch wenn ein Fehler auftritt. versuche es stattdessen

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 danke für die Korrektur. Sie haben Recht, ich habe den Fehler einfach ignoriert, anstatt ihn zu beheben. Ich hatte tatsächlich ein Problem mit meinem DB-Pfad.

Ich hatte das gleiche Problem, ich habe das mongoose npm-Paket von 5.6.9 auf 5.7.6 aktualisiert und das Problem verschwand.

Für Personen, bei denen dieses Problem auftritt: Wenn Sie Mongo Atlas Cloud Instance verwenden, überprüfen Sie bitte, ob Ihre IP-Adresse auf der Registerkarte Netzwerkzugriff korrekt angegeben ist.

Ich hatte das Problem und es scheint, dass Mongo Atlas, da mein ISP jedes Mal (DHCP) neue IPs ausgibt, wenn ich mich wieder mit dem Netzwerk verbinde, nur die zuvor angegebene IP-Adresse in der Whitelist auflistete. Hoffe das hilft jemandem.

habe mein Problem gelöst
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

Ich weiß nicht, wie das ein Problem gelöst hat, aber ich habe Compass heruntergeladen und mit der Datenbank verbunden, nur den Link kopiert. Sobald es verbunden war, war der Fehler weg. Die Topologie ist in meinem Code immer noch wahr. Vielleicht hat es einige Optionen mit Compass konfiguriert, die mit der üblichen mongodb-Installation nicht richtig waren. Jetzt kann ich mich ohne Compass verbinden und alles scheint zu funktionieren, habe es nur einmal am Anfang gemacht.

Ich habe das gleiche Problem und bin dank dieses Forums durchgekommen, indem ich die useUnifiedTopology-Einstellung kommentiert habe. Allerdings habe ich diese Einstellung dann auskommentiert, aber jetzt funktioniert sie immer noch einwandfrei... ziemlich verwirrt...

Mongoose v5.7.11 verwendet den neu veröffentlichten MongoDB-Treiber 3.3.4, daher werde ich dieses Problem schließen. Wenn Sie eine ähnliche Fehlermeldung erhalten, öffnen Sie bitte ein neues Problem und folgen Sie der Problemvorlage.