Currently, I am using MongoDB 2.4.1 in my all shard clusters. I need to upgrade to MongoDB 2.4.6.
Please help me on this.
Thank you.
If you are upgrading between point releases (for example, 2.4.x to 2.4.y), the upgrade process should just be updating the binaries. As a general rule there should be no changes in data file format, config metadata, or backward compatibility within the same major release series.
It's definitely worth reading the release notes and upgrade notes to be clear on the changes and any upgrade caveats. I would also encourage you to upgrade to the latest available production version in your release series (currently 2.4.9) as there are generally worthwhile performance and stability improvements.
Recommended steps for 2.4.x -> 2.4.y sharded cluster upgrade
The recommended steps for upgrading sharded cluster components with minimal disruption are:
Disable the balancer to avoid migration errors during the upgrade period.
NOTE: If a migration is currently in progress, it will be completed before the balancer is disabled.
Upgrade all mongos instances in the cluster, in any order.
Upgrade all 3 mongod config server instances.
NOTE: You should ideally upgrade the first server listed in the mongos --configdb
argument last (i.e. upgrade the config servers in the reverse of the order listed in your --configdb string).
Upgrade each shard, one at a time.
NOTE: You should ideally upgrade the mongod secondaries first, and then run rs.stepDown() to elect a new primary before upgrading the primary of each shard. You may wish to run rs.freeze(60) on the current primary to ensure it is ineligible for re-election.
Enable the balancer once all upgrades are complete.
Related
Apologies if this question is too open-ended.
I have inherited an aging tech stack and am required to upgrade our 200GB MongoDB Community Edition v3.4 installation (hosted on Ubuntu 20) to MongoDB v5 in order to support some new features.
MongoDB advises that to install v5.0, one must be already on MongoDB v4.4:
https://www.mongodb.com/docs/manual/release-notes/5.0-upgrade-standalone/
They say that if you are on a version older than 4.4, then you need to incrementally upgrade to v4.4 before upgrading to v5.
However, if you follow the links in that official upgrade tutorial, you will find that in order to upgrade to any version of MongoDB, they insist on you upgrading version-by-version, successively.
So for me on v3.4 the upgrade path will look like this:
v3.4 -> v3.6 -> v4.0 -> v4.2 -> v4.4 -> v5.0.13
Following these tutorials:
https://www.mongodb.com/docs/manual/release-notes/3.6-upgrade-standalone/
https://www.mongodb.com/docs/manual/release-notes/4.0-upgrade-standalone/
https://www.mongodb.com/docs/manual/release-notes/4.2-upgrade-standalone/
https://www.mongodb.com/docs/manual/release-notes/4.4-upgrade-standalone/
https://www.mongodb.com/docs/manual/release-notes/5.0-upgrade-standalone/
I'm not entirely sure why this is necessary, as the tutorials themselves seem to mostly involve copying over newer binaries and then setting a feature compatibility version in the database config.
To test whether this was necessary I did a mongodump of our entire v3.4 database and then installed a standalone MongoDB v5.0.13 on the same server and then mongorestore to the new v5.0.13 database. Everything seems to work fine, mongorestore spent two hours recreating all the indexes as its last step (something various articles told me would not happen using the mongodump/mongorestore method).
I am able to connect Mongo clients to this new v5.0.13 Community instance without issue. All the data is there and I am able to query it just fine.
So my question is, why does MongoDB strongly advise doing the upgrade incrementally, one version at a time when dumping the database and restoring it to a new version of MongoDB seems to work just fine?
The only issues I have currently is having to rewrite some client code which is using an older Mongo Java driver. This is something I am going to have to do regardless of the upgrade method I used.
Our MongoDB instance is Community Edition and is a single, standalone instance (not a replica set) so I don't know if this matters. Perhaps the upgrade process described by MongoDB is for Mongo Cloud or for Enterprise?
I'm just looking for clarification on whether the simpler method I tried is going to cause me issues. Maybe I've missed something I hadn't considered.
Last time I performed a major postgresql RDS version upgrade, the followers were really messed.
I am about to perform a minor version upgrade (something like 12.5 --> 12.6) and i cannot find any relevant documentation about if and what type of impact this may have on the followers.
Any directions towards any relevant docs?
According to AWS documentation:
There are two kinds of upgrades: major version upgrades and minor version upgrades. In general, a major engine version upgrade can introduce changes that are not compatible with existing applications. In contrast, a minor version upgrade includes only changes that are backward-compatible with existing applications.
Source
I can also mention that I've been running a few RDS PostgreSQL clusters in production, with perhaps all the possible flavors, Aurora RDS with PostgreSQL provisined, Aurora RDS serverless, RDS PostgreSQL and never had an issue when doing a minor upgrade either with master, replicas or clients, we even have the automatic minor version upgrade enabled.
Current version 9.0.7.0
Upgrade version 9.0.11.0
When we looked at how to upgrade, we found below link
ML Knowledgebase
This document is of April 2018.
So i would like to know if we have to follow any additional steps, configuration, process?
Upgrading from Release 9.0-1 or Later
To upgrade from release 9.0-1 or later to the current MarkLogic 10 release (for example, if you are installing a maintenance release of MarkLogic 10), perform the following basic steps:
Stop MarkLogic Server (as described in step 1 of Removing MarkLogic).
Uninstall the old MarkLogic 9 release (as described in Removing MarkLogic).
2.1. If you want to uninstall MarkLogic 9.0-4 or later, and if the converters package was previously installed with it, you will have to perform a two-step uninstall: first uninstall MarkLogic Converters and then uninstall MarkLogic Server. For more detail, see MarkLogic Converters Installation Changes Starting at Release 9.0-4 and Removing MarkLogic.
Install the new MarkLogic 10 release (as described in Installing MarkLogic).
If you want to install MarkLogic 9.0-4 or later, and you plan to use the converters package with it, you will have to perform a two-step installation: first install MarkLogic Server and then install MarkLogic Converters. For more detail, see MarkLogic Converters Installation Changes Starting at Release 9.0-4 and Installing MarkLogic.
Start MarkLogic Server (as described in Starting MarkLogic Server).
Open the Admin Interface in a browser (http://localhost:8001/).
When the Admin Interface prompts you to upgrade the databases and the configuration files, click the button to confirm the upgrade.
If you are upgrading a cluster to a new release, see Upgrading a Cluster to a New Maintenance Release of MarkLogic Server in the Scalability, Availability, and Failover Guide. The Security database and the Schemas database must be on the same host, and that host should be the first host you upgrade when upgrading a cluster.
If you are upgrading two clusters that make use of database replication to replicate the Security database on the master cluster, then you must enter the following to manually upgrade the Security database configuration files on the machine that hosts the replica Security database:
http://host:8001/security-upgrade-go.xqy?force=true
It is possible to update mongodb (Currently in version 2.0.6 and I need > 2.2) and keep databases ?
Mongodb running on Debian 7
MongoDB 2.0 data files are compatible with 2.2-series binaries without
any special migration process. However, always perform the upgrade
process for replica sets and sharded clusters using the procedures
that follow.
As said on the mongodb release notes. Also when your making an upgrade, since your current version is 2.0.6 you need to upgrade to 2.2 first.
If you want to go up to the latest version you have to keep upgrading version one by one as said on the release notes here.
Upgrading a Standalone version
Download binaries of the latest release in the 2.2 series from the MongoDB Download Page.
Shutdown your mongod instance. Replace the existing binary with the 2.2 mongod binary and restart MongoDB.
Recently I upgraded one of our replicas from MongoDB version 2.4.3 to 2.6.3. It was a simple restart of the 3 mongodb replicas after upgrading of the binaries. After a few days, the same queries that were running for nearly a year on 2.4.3 started to build up causing very high load on the server. The load avg which used to be less than 1 all the time now spiked to over 300. Quick resolution was to failover and restart the mongod process which would bring the load down. But the new Primary would behave the same way in matter of a few hours and I would be forced to failover again and restart mongod. After a few such occurrences I downgraded the replicas to 2.4.10 and this seem to have resolved the load issue or queues building. Can anyone vouch for the theory to be true if you might have experienced a similar problem?