Seems the MongoDB release is a significant performance upgrade - ay idea when Spring Data MongoDB will support this version?
Strictly speaking, the MongoDB 3.0 server can even be used with the latest 2.13 Java driver and thus the currently released Spring Data MongoDB 1.6.2. For a full compatibility overview of the driver and server versions, see this wiki page.
The recently released first release candidate of Spring Data MongoDB 1.7 ships support for the MongoDB 3.0 Java driver. This is mostly a compatibility release, we don't target special 3.0 features yet (although you should be able to benefit from an upgrade nonetheless).
Find more information about this in the release train wiki, the JIRA ticket as well as the corresponding section of the reference documentation.
The GA release of Spring Data MongoDB 1.7 is scheduled to be part of the Fowler release train GA end of March.
Spring Data Mongo has 1.7RC1 -> http://docs.spring.io/spring-data/data-mongo/docs/1.7.0.RC1/ Hopefully that one will be released soon.
As Java Driver github repo says, they released a 2.13.0 version on January 29th and it is stable -> https://github.com/mongodb/mongo-java-driver/releases/tag/r2.13.0 It includes all the features for mongo 3.0, but you need to go through the compatibility to upgrade to this version.
Also, they are working on v. 3.0.0. for Java Driver, you can find it here -> https://github.com/mongodb/mongo-java-driver/releases/tag/r3.0.0-beta3 (its still in beta though)
Related
we plan to use Spring Batch for mission critical production batching system. And I am wondering which version we should choose now?
From the version history in github(https://github.com/spring-projects/spring-batch/tags): version 4.2.7 is marked with .RELEASE, while 4.3.3 is not.
So the questions are:
1、what's the difference regarding the versions with or without .RELEASE ending, is the ".RELEASE" ending verison more stable?
2、which version is recommended for production now ?
Thanks a lot!
Both are production ready releases, one for the 4.2 line and the other for the 4.3 line. I recommend using the latest 4.3 as it has an extended support lifetime. Spring Batch follows the same support terms as Spring Boot, and each version will be supported as long as the latest Spring Boot version that brings it is supported, see https://github.com/spring-projects/spring-boot/wiki/Supported-Versions.
For example:
the latest Spring Boot version that brings Spring Batch 4.2 is 2.3 which will be OSS supported until May 2021.
The latest Spring Boot version that brings Spring Batch 4.3 is 2.5 which will be OSS supported until May 2022.
etc
Spring Boot 2.6 is expected on November 2021 and will likely bring Spring Batch 4.3 as well, which extends the OSS support for Spring Batch 4.3 for another year. So I recommend using the latest version from 4.3 to benefit from a longer support period since you are planning to use it in production. FTR, there is an ongoing effort to update the website/wiki with all these support details across the portfolio, so keep tuned.
In regard to the version name scheme, we (the Spring engineering team) have decided to switch from the old naming scheme (.BUILD-SNAPSHOT, .RELEASE, etc) to a new naming scheme. This has been announced on our blog here: Updates to Spring Versions.
We have multiple applications using mongodb as database. In our current case our applications are using the mongo driver 3.4.
On the server side currently we are running with Mongo 3.4 but we would like to keep the Mongo version up to date as long as possible.
I know that mongo drivers provide such level of backward compatibility, but I don't know whether an old version of mongo driver can work without any problem with a newer version of a mongo server.
Can mongo driver 3.4 work with 3.6 server without any problem?
Officially supported drivers provide a form of backward compatibility.
That is, newer drivers should be compatible with older server versions, but thorough testing of the application to double-check is always strongly recommended.
Note that the opposite is not always true, e.g. newer servers may be compatible with older drivers, but there is no guarantee. This is especially true if you apply setFeatureCompatibilityVersion command after a server upgrade.
The page Driver Compatibility in the documentation should be up-to-date with driver versions vs. server versions. You might be able to refer to this page in the future.
As of December 2021, the driver compatibility pages containing compatibility matrices for Python can be found at:
PyMongo: https://docs.mongodb.com/drivers/pymongo/#mongodb-compatibility
Motor: https://docs.mongodb.com/drivers/motor/#mongodb-compatibility
I want to upgrade all members to 3.4, however, I want to be able to switch back to 2.6.8 if anything goes wrong. In order to do this, I was hoping to add a new member 3.0 or 3.4 member to the existing replica set (on 2.6.8), replicate the data, then break it out and create a separate replica set on 3.4. After breaking out the synced up 3.x member, I would add further 3.x members to it and switch my app to use the new replica set. If the app breaks, I am planning to switch back to the older replica set. I read that replica set members can be on different versions. I am having trouble locating information on specific versions and potential issues. Also, the reason I keep mentioning 3.0 as well as 3.4, is because when I started planning, the latest version was 3.0, I also heard that I have to upgrade members incrementally, so from 3.0 to 3.2 to 3.4. Any advice?
This seems to be documented in Mongo Release Notes for 3.0, 3.2 and 3.4.
https://docs.mongodb.com/manual/release-notes/3.4-upgrade-replica-set/
"upgrade an existing MongoDB deployment to 3.4, you must be running a 3.2-series release.
To upgrade from a version earlier than the 3.2-series, you must successively >upgrade major releases until you have upgraded to 3.2-series. For example, if >you are running a 3.0-series, you must upgrade first to 3.2 before you can >upgrade to 3.4."
https://docs.mongodb.com/manual/release-notes/3.2-upgrade/
https://docs.mongodb.com/manual/release-notes/3.2-downgrade/
"To upgrade an existing MongoDB deployment to 3.2, you must be running a 3.0->series release.
To upgrade from a 2.6-series release, you must upgrade to the latest 3.0-series >release before upgrading to 3.2. For the procedure to upgrade from the 2.6->series to a 3.0-series release, see Upgrade to 3.0."
https://docs.mongodb.com/manual/release-notes/3.0-upgrade/
"To upgrade an existing MongoDB deployment to 3.0, you must be running 2.6. If >you’re running a version of MongoDB before 2.6, you must upgrade to 2.6 before >upgrading to 3.0. See Upgrade to 2.6 for the procedure to upgrade from 2.4 to >2.6. Once upgraded to MongoDB 2.6, you cannot downgrade to any version earlier >than MongoDB 2.4."
In a previous project, we had to upgrade from 2.6.8 -> 3.0 (upgrade members in a rolling manner to keep the cluster up and running). Our rollback plan was to decide at this point whether everything was OK and if not rollback to 2.6.8. If it was ok, upgrade from 3.0 -> 3.2 (again, a rolling upgrade). We did not try a two step downgrade, but I guess it is theoretically possible based on what Mongo documents. From 3.4, you will have to review the release notes to see if it is theoretically possible!
Also note that you need to consider upgrading your client drivers along the way. There are compatibility issues with client driver versions as well.
My mongodb is in version 3.0 and run on Linux Redhat 6.
I do not use entreprise options, then I would like to switch enterprise edition to community edition. Any drawback on data? It's much like binary upgrade?
Unless you are using an Enterprise storage engine (eg. Encrypted Storage Engine in MongoDB 3.2+), the data format in MongoDB Community and Enterprise editions is identical and changing between editions is just a change in the MongoDB server binaries. If you need to change storage engines you can do so without downtime on replica sets using a rolling maintenance procedure (see: Your Ultimate Guide to Rolling Upgrades).
I would recommend using matching release versions when changing between MongoDB Enterprise and Community editions to minimize any unexpected issues. The standard upgrade/compatibility caveats (as mentioned in the MongoDB Release Notes) apply if you happen to be upgrading or downgrading between major MongoDB versions (i.e. 3.2 and 3.4).
We have an app that uses the C# Mongodb client lib from mongo, version 1.1.0.4184
This code currently runs against mongodb 2.6.4
We would like to stand up a new mongodb server, the current version (3.2.11). Will our code run against newer mongodb?
It really depends what you mean by "will it run". The MongoDB v1.1.0.4184 C# driver was released in June, 2011 and dates to roughly the MongoDB 1.8 server release timeframe. This driver version is certainly no longer tested or supported, and will not be fully compatible with newer server features like the WiredTiger storage engine (default in MongoDB 3.2+) or SCRAM-SHA-1 authentication (default in MongoDB 3.0+).
The MongoDB documentation includes a reference table with recommended version(s) of the drivers for use with a specific version of MongoDB: C#/.NET Driver Compatibility.
If this is a production system I would strongly recommend taking the time to update and test a supported version of the C# driver for use with MongoDB 3.2 (eg. the v1.11 C# driver). I suspect it is very likely you will encounter fixed (or novel) bugs/behaviour using a driver that is more than five years old. Your application won't be able to take advantage of many of the newer server features, and this obsolete driver predates specifications such as standard Server Discovery and Monitoring (SDAM) behaviour.
That said, assuming you aren't using any features the driver isn't aware of your code may continue to run (or at least appear to run) successfully. In my opinion doing so is a high risk deployment strategy.
Yes, i am using it, but however we have to chek on specific features, which you were using. using MongoDB latest driver is much better in terms of latest features and there are few features were removed(like 'eval()').