MongoDB Upgrade Summary

background

Recently the business MONGO upgrade, because the need to adjust the business code and offline testing, the work lasted one months before the results of the phase. Version upgrade be sure to make a version upgrade on the production machine after the test environment has been successfully tested. The business code is primarily Python, and before the upgrade, we have updated to the appropriate version of Pymongo and tested it online. In order to upgrade from 2.4 to 3.0 due to data compatibility issues, you need to upgrade from 2.4 to 2.6 before upgrading from 2.6 to 3.0. MONGO does not install with Yum, directly copies the Mongo bin file and runs Mongd boot on the machine. Download address MONGO is not using sharding. mongo2.4 to 2.6

This upgrade was done by the developer on its own a long time ago. the process of upgrading

Upgrading from a library
Main operation: Replace the 2.4 version MONGO binary file with the binary file in the bin directory of the 2.6 package and restart it. After the MONGO has changed from the Recoer state to the secondary state, the next MONGO instance is upgraded. You can view the instance state in the MONGO shell with Rs.status ().

Shut down the main library

the benefits of upgrading the Main Library upgrade indexing is an issue that can cause long-time write locks, and MongoDB needs to occupy a write lock (and not give up temporarily) when building an index in the foreground, and if the collection has a large amount of data, it usually takes a long time to build an index, which is especially easy to cause problems. MongoDB provides two types of indexed access, one that is background, does not take a long time to occupy the write lock, and the other is a non-background way, which takes a long time to occupy the lock. Use the background method to solve the problem.
However, when mongo2.4 is under construction, even if background is specified, access to the database is still blocked when replaying from the library. This problem was fixed in 2.6, so that you could create a new index in a running MONGO cluster without worrying about blocking. It was a big pain in our business to run small steps. mongo2.6 to 3.0

This upgrade is performed by the DBA and the business side mates. This upgrade directly switches to the new database engine. the process of upgrading

Upgrade offline from library
2.6 Before upgrading to 3.0 need to verify the existing user schema, in 3.0 MongoDB completely deprecated the previous user authorization authentication mode, so before upgrade 3.0 need to upgrade the 2.6 user schema to a compatible 3.0 format.
Stop Mongod, replace the binary of version 2.6 MONGO with the binary file in the bin directory in the downloaded 3.0 package, and then restart Mongod.

Upgrade online from library
The main thing is to copy the data and restart a mongo3.0 instance.

Upgrading the Main Library
Because during the upgrade, there is a short read-only time when the MONGO is selected. To prevent data write failures, we re-sent the business code before the upgrade, and all the interfaces that write MONGO operations go into the maintenance state.
DBA Operation: Stop the Old Main library, MONGO cluster will re-select the master, and then directly copy the files from the library to the original library machine, start a mongo3.0 instance, then add the instance to replica, and finally re-place the main library. the benefit of the upgrade is the most intuitive benefit because it switches the storage engine and saves a lot of disk space after the upgrade. Until then, the MONGO of our business has been its own operation. The DBA is MONGO that our side of the version is too old and unwilling to take over. After this upgrade, the basic can be delivered to DBA hosting, much less worry. Summary of the industry has specialized, database operations or to the DBA to do better. After 3.0, the CPU load of the MONGO machine will be higher than before the upgrade, should be evaluated before the upgrade, the sudden escalation of the CPU full may be unexpected. MongoDB's replica set requires at least more than 3 units to be highly available, and the number of nodes is preferably cardinality. We are actually using 1 Master 2 online from library 2 offline from the library. In order to minimize the impact on the business, database upgrades are generally placed on an undervalued visit. Our upgrade was carried out at 3 o'clock in the morning, and the night was a very pernicious one.