View profile

How to Upgrade MongoDB With Zero Downtime

How to Upgrade MongoDB With Zero Downtime
By Mastering JS Weekly • Issue #45 • View online
If you’re running MongoDB in production, you should be running a replica set rather than a standalone server. Replica sets have the neat advantage that you can lose one server in the replica set without disrupting the clients making requests. This leads to a neat advantage: zero-downtime upgrades of your production cluster. Upgrade your database without disrupting even a single application request!

3 node replica set: your app talks to the primary. Secondaries replicate from primary
3 node replica set: your app talks to the primary. Secondaries replicate from primary
This replica set is made up of 3 independent `mongod` processes that are configured to operate as a replica set. When a secondary goes down, the replica set can continue functioning normally. When the primary goes down, the remaining members of the replica set “elect” a new primary using an algorithm based on the Raft Consensus Algorithm.
The Upgrade Process
Suppose you have a replica set running MongoDB v4.2.9, and you want to upgrade to MongoDB v4.4.1. The steps for upgrading a 3 node replica set are as follows:
  • Upgrade one of the secondaries: kill the v4.2.9 `mongod` process, and run the v4.4.1 `mongod` process. Make sure you set the same dbpath.
  • Wait for the new v4.4.1 process’ replication to catch up
  • Upgrade the other secondary and wait for replication to catch up.
  • Connect to the MongoDB cluster and run `rs.stepDown()` to force an election and make the current primary into a secondary.
  • Upgrade the former primary
MongoDB Atlas can handle this upgrade process automatically for you. But the process is pretty easy even if you do it manually, it usually only takes 5-10 minutes.
Since this process only takes down `mongod` processes that are secondaries in the replica set, your app won’t drop any requests while you’re upgrading the individual processes.
The only possibility for failed requests is when you run `rs.stepDown()`: if a query or write operation is in progress when you call `rs.stepDown()`, MongoDB will kill that operation and your application will get an error.
Retryable Writes
MongoDB 4.2 compatible drivers (like Mongoose ^5.7.0) support retryable reads and retryable writes. This means that the driver is smart enough to automatically retry your request if it happens to fail because an `rs.stepDown()` happened in the middle of the request.
Retryable reads are enabled by default. Here's how you enable retrying writes
Retryable reads are enabled by default. Here's how you enable retrying writes
Retryable reads and writes do come with some asterisks. While most read and write operations are retryable, there are some notable exceptions. For example, the `getMore` command is not retryable, which means Mongoose won’t be able to automatically pick up where it left off if the primary goes down in the middle of iterating through a cursor.
On the retryable write side of things, `updateMany()` and `deleteMany()` are not retryable.
Of course, there’s nothing stopping you from implementing retries yourself. However, in a lot of cases, the MongoDB driver handles this automatically.
“Mastering Mongoose” distills 8 years of hard-earned lessons building Mongoose apps at scale into 153 pages. That means you can learn what you need to know to build production-ready full-stack apps with Node.js and MongoDB in a few days. Get your copy!
Most Recent Tutorials
Other Interesting Reads
How To Write Resilient MongoDB Applications
MongoDB’s CTO Eliot Horowitz on what’s new in MongoDB 4.2, Ops Manager, Atlas, and more
Did you enjoy this issue?
Mastering JS Weekly

A weekly summary of our tutorials

If you don't want these updates anymore, please unsubscribe here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Powered by Revue