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?
Related
I'm getting this error after removing the lock file and running mongod.exe --repair from the command line.
This version of MongoDB is too recent to start up on the existing data files. Try MongoDB 4.2 or earlier
I was literally just using the database with an express app that I'm developing when the service crashed, and now it won't restart or repair. Since I'm not an expert on Mongo I need some help recovering from this.
I don't have any other versions of mongo installed, nor have I done any upgrades. I don't care so much about the data, other than trying to preserve my admin db where I've got all my authentication configured.
How do I get mongo running again?
EDIT: This question, which was suggested as an answer was the first thing I looked at.
This version of MongoDB is too recent to start up on the existing data files. Try MongoDB 4.2 or earlier
It was unhelpful because, as I've mentioned already, I was already running mongo. The service crashed, and when I tried to restart the service, I'm getting the error. But I did not upgrade. The database files appear to be corrupted.
I would like to inform you that we are migrating MongoDB from 3.2.8 to 4.4.10 and it has been successfully done without any more issue and problems also when we are restarting service of mongoDB then it is being up with 4-5 minutes and on some version 2-3 minutes. But when we are migrating this mongoDB from 4.4.10 to 5.0.3 then service is taking too long time to start (around 50-60 minutes) and same time is taking on after restart when getting started the service.
So
please help us to resolve this issue. and if do you have any solutions on it so please provide us.
Note: We have tested with 2 os version 1. Amazon Linux-2 2. Cent-OS -7 but showing same response
Thank you for your support in advance.
Lal Chand
DevOps Specialist
Master node of 3-nodes replicaset gone OOM and was killed by kernel. After it was restarted and master role was retaken, featureCompatibilityVersion was set to 3.2 instead of 3.4 but there's no trace of that change in logs. That caused some issues on client side until i manually switched it back to 3.4.
It's a clean installation of 3.4.23, no upgrades was made on this replicaset.
Is it normal behaviour or some kind of bug?
Might be a bug but, since 3.4 server has passed its end of life, your only real solution is to upgrade to a supported version (3.6+ as of this writing).
seems bug, if it's new installation. You need to set featureCompatibilityVersion to 3.4 or add in start script to avoid any application error.
Recommendation: 3.4 has passed it's end of life and 3.6 have end of life in another 6 months. Please take reference of below link. So better plan to upgrade your mongodb server to 4.0
https://www.mongodb.com/support-policy
Sunday we upgraded our RDS instance from postgresql 9.6 to 10.3. After that, we started to see a way bigger CPU consumption.
I've checked and looks like the two versions have a few different defaults parameters. Anyone know which one could be the cause of the difference in CPU?
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.