Top List Top

Topology closed mongodb

Normally, the ‘MongoDB error topology was destroyed’ error occurs if the node server’s connection to the MongoDB instance was interrupted while it was trying to write to it. Or if the mongo driver drops the connection for any reason.

Another reason could be mongoose disconnecting before mongo document indexes are created

Here at Bobcares, we have seen several such MongoDB errors as part of our Server Management Services for web hosts and online service providers.

Today, let us see how our Support Engineers resolve this MongoDB error message.

How we resolve the error ‘MongoDB error topology was destroyed’

Recently, one of our customers approached us with a MongoDB error message. He told that suddenly the node started crapping out errors with the message “MongoDB error: Topology was destroyed”.

Now let’s take a look at how our Support Engineers resolve this error message.

Here, we found that the mongo driver was dropping the connection. So, we can increase the retry time value.

By default, the mongoose will try to reconnect for 30 seconds and then stop retrying. After that, it throws errors forever until we restart it.

We change this by editing the below fields.

mongoose.connect[MONGO_URL, { server: { // sets how many times to try reconnecting reconnectTries: Number.MAX_VALUE, // sets the delay between every retry [milliseconds] reconnectInterval: 1000 } } ];

This instantly fixes the error for the customer.

Another reason could be mongoose disconnecting before the creation of mongo document indexes.

In order to make sure all models have their indexes built before disconnecting, we can make the below changes:

await Promise.all[mongoose.modelNames[].map[model => mongoose.model[model].ensureIndexes[]]]; await mongoose.disconnect[];

This must resolve the error.

[Need any further assistance in fixing MongoDB errors? – We are here to help you.]

Conclusion

In short, this error can occur due to many reasons that include interruption of the node server’s connection to the MongoDB instance while it was trying to write to it. If the mongo driver drops the connection for any reason. Another reason could be mongoose disconnecting before the creation of mongo document indexes. Today, we saw how our Support Engineers fix this MongoDB error.

Never again lose customers to poor server speed! Let us help you.

Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.

GET STARTED

var google_conversion_label = "owonCMyG5nEQ0aD71QM";

I’m trying to insert a document to the collection “B99”, but i get the error: MongoError: Topology is closed, please connect. Removing client.close []; at the end. Reformatting my code as shown below [got the “format” from another post]. Adding my IP to the whitelist on the Network Access page on MongoDB Atlas. Solved it.

Is there a failure to connect error in MongoDB?

_MongoNetworkError: failed to connect to server [cluster0-shard-00-01-YOUR.mongodb.net:27017] on first connect [Error: connect ECONNREFUSED …]_ you should then probably follow these steps below. If you are using MongoDB Atlas, you’ll need to whitelist your server’s IP or a range of IPs, to avoid facing this error.

Why is the topology closed in Node.js?

MongoError: Topology is closed because of the authentication problem

Why is MongoDB not ready for NPM only?

Therefore mongodb is not ready if used npm only. _MongoNetworkError: failed to connect to server [cluster0-shard-00-01-YOUR.mongodb.net:27017] on first connect [Error: connect ECONNREFUSED …]_ you should then probably follow these steps below.

What is the reason for the MongoDB connection error?

Try logging the error in console.log by passing it as a second argument and paste the resulting log. Ok Thanks. Here’s the log. reason: MongoError: Authentication failed.

Removing client.close []; at the end. Reformatting my code as shown below [got the “format” from another post]. Adding my IP to the whitelist on the Network Access page on MongoDB Atlas. Solved it. Needed to put insertOne and client.close [] in an async function [thanks @D. SM], like this:

MongoError: Topology is closed because of the authentication problem

How is MongoDB topology manager used in Node.js?

The mongodb-topology-manager npm package is indispensible for testing MongoDB connection logic. This lib can stop and start MongoDB servers, replica sets, and sharded clusters from Node.js. The MongoDB driver Node.js uses it for testing internally. First, let’s see what happens when the MongoDB server that the driver is connected to shuts down.

Why do I get a MongoDB connection error?

Version 3.3.3 of the driver which was published today should add more details to the MongoTimeoutError. It is also recommended to update the driver due to a bugfix. This error is the result of the driver being unable to connect to a server satisfying the read preference of a given operation [or initial connect].

Why is my Node.js Mongo server not connecting?

2017-10-30T14:32:21.477+0530 E QUERY [thread1] Error: couldn’t connect to server 127.0.0.1:27017, connection attempt failed : Start your MongoDB Service with the command below : There should be no error reported when you start Mongo Daemon, mongod.

How to fix mongoerror failed to connect to server?

MongoError: failed to connect to server 1 Make sure MongoDB Service is up and running. 2 The URL you provide to the MongoClient.connect [] method should be correct. More

Is there a way to disable useunifiedtopology in Mongo?

Mongo will warn you that it will be disabled in future or something but for the time being it seems to totally solve this issue. Can confirm that commenting useUnifiedTopology out solves the problem in my build. Also happening in a [apparently] random fashion. @rpedroni Sadly, it doesn’t for us…

Why is Mongo driver not reconnecting after topology was destroyed?

Mongo is 3.4.3. What bothers me is that after this error the connection is not re-established [the app will just keep on throwing errors from downstream in the database]. Am I missing an option to re-establish a lost connection in the driver?

What does it mean if Mongo server is not up?

Starting the Mongo Shell should verify this. If your MongoDB Service is not up, you would get an Error in the Terminal as below. 2017-10-30T14:32:21.477+0530 E QUERY [thread1] Error: couldn’t connect to server 127.0.0.1:27017, connection attempt failed :

Why is there a connect error in MongoDB?

The issue comes from trying to create an api using the direct nodejs mongodb driver 3.9. I have the client call in the controller because putting it in the server and calling to the client when needed constantly creates a “connect error” so here it is in the controller for full context.

Reference
Unified Topology Design

At the time of writing the node driver has seven topology classes, including the newly introduced unified topology. Each legacy topology type from the core module targets a supported topology class: Replica Sets, Sharded Deployments [mongos] and Standalone servers. On top of each of these rests a thin topology wrapper from the “native” layer which introduces the concept of a “disconnect handler”, essentially a callback queue for handling naive retryability.

The goal of the unified topology is threefold: - fully support the drivers Server Discovery and Monitoring, Server Selection and Max Staleness specifications - reduce the maintenance burden of supporting the topology layer in the driver by modeling all supported topology types with a single engine - remove confusing functionality which could be potentially dangerous for our users

How to use it

The unified topology is available now behind the useUnifiedTopology feature flag. You can opt in to using it by passing the option to your MongoClient constructor:

const client = MongoClient['mongodb://localhost:27017', { useUnifiedTopology: true }];

NOTE: In upcoming minor versions useUnifiedTopology will default to true, and in the next major version of the driver this topology will outright replace the legacy topologies.

Behavioral Changes

Deprecated events and options

The unified topology no longer supports the following events: - reconnect - reconnectFailed - attemptReconnect - joined - left - ping - ha - all - fullsetup - open

It also deprecates the following options passed into the MongoClient: - autoReconnect - reconnectTries - reconnectInterval - bufferMaxEntries

The following sections will go into detail about why tese values are no longer used.

MongoClient.connect, isConnected

The unified topology is the first step in a paradigm shift away from a concept of “connecting” to a MongoDB deployment using a connect method. Consider for a moment what it means to be connected to a replica set: do we trigger this state when connected to a primary? A primary and one secondary? When connected to all known nodes? It’s unclear whether its possible to answer this without introducing something like a ReadPreference parameter to the connect method. At this point “connecting” is just one half of “operation execution” - you pass a ReadPreference in, and await a selectable server for the operation, now we’re connected!

But couldn’t you do all of that as a part of your first operation? Our goal is to move towards code that looks more like the following:

A default ReadPreference of “primary” is used for the first write, and a part of awaiting that insert involves initiating connections to all servers in a cluster, selecting a server and executing the operation. Errors will surface at the callsite of any given operation, giving the user more fine-grained control over error handling.

Why does MongoClient.isConnected always return true?

We think the ambiguity of what it means to be “connected” can lead to far more problems than it seeks to solve. The primary concern of an application developer is successful operation execution. The isConnected method is often used to “health check” the MongoClient in order to determine if operations can be successfully executed. The unified topology pushes this concern directly to operation execution through the introduction of a “server selection loop” [discussed in detail below]. A MongoClient thus is always “connected” in that it will always accept operations and attempt to execute them.

NOTE: In the next major version of the driver, isConnected will be removed completely.

Server Selection

The psuedocode for operation execution looks something like this:

function executeOperation[topology, operation, callback] { const readPreference = resolveReadPreference[operation]; topology.selectServer[readPreference, [err, server] => { if [err] { // This error is most likely a "Server selection timed out after Xms" return callback[err]; } // checks a connection out of the server to execute the operation, then checks it back in server.withConnection[conn => operation.execute[conn, callback]]; }] }

The serverSelection method above will loop for up to serverSelectionTimeoutMS [default: 30s] waiting for the driver to successfully connect to a viable server in order to execute the requested operation. If server selection results in no viable server, control is passed back to the user to determine what the next best course of action is. This doesn’t necessarily mean that the client is generally disconnected from a cluster, but that it is not currently connected to any server that satisfies the specified ReadPreference.

disconnectHandler

The three topology types from the “native” layer [in lib/topologies] primarily provide support for a callback store, called the “disconnect handler”. Rather than using a server selection loop, the legacy topologies instead place callbacks on this store in cases when no suitable server is available, intending to run the operation at some later time. This callback store also provides a form of naive retryability, however in practice this might lead to unexpected, or even unintended results: - The callback store is only associated with a single server, so attempts to re-execute an operation are only ever made against the originally selected server. If that server never comes back [it was stepped down, and decommissioned for instance], the operation will sit in limbo. - There is no collaboration with the server to ensure that queued write operations only happen one time. Imagine running an updateOne operation which is interrupted by a network error. The operation was successfully sent to the server, but the server response was lost during the interruption, which means the operation is placed in the callback store to be retried. At the same, another microservice allows a user to update the written data. Once the original client is reconnected to the server, it automatically rexecutes the operation and updates the newer data with an older value.

The unified topology completely removes the disconnect handler, in favor of the more robust and consistent Retryable Reads and Retryable Writes features. Operations now will attempt execution in a server selection loop for up to serverSelectionTimeoutMS [default: 30s], and will retry the operation one time in the event of a retryable error. All errors outside of this loop are returned to the user, since they know best what to do in these scenarios.

Deprecated monitoring events

The joined, left, all, and fullsetup events are no longer emitted by the unified topology, primarily because their behavior is duplicated by the pre-existing SDAM monitoring events: topologyDescriptionChanged and serverDescriptionChanged. Please refer to the documentation on Topology Monitoring

Frequently Asked Questions