[SERVER-22251] db.upgradeCheck() does not perform checks in v3.0.x and v3.2.x Created: 20/Jan/16 Updated: 06/Dec/22 Resolved: 18/Aug/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Shell |
| Affects Version/s: | 3.2.1 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Daniel Doubrovkine | Assignee: | Backlog - Query Team (Inactive) |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Query
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Operating System: | ALL | ||||||||
| Participants: | |||||||||
| Description |
|
Running 3.2.1 shell against a 2.4 MongoDB.
This isn't true, the import will fail with
The command also runs suspiciously fast. The 2.6.12 version of the command line client processes documents.
Will update once/if it finds my error. |
| Comments |
| Comment by Daniel Pasette (Inactive) [ 18/Aug/17 ] |
|
The upgradeCheck functionality was removed from v3.4 as part of The idea of a pre-upgrade validation check is still valid, but if required in the future will most likely be built as an external tool. |
| Comment by Ramon Fernandez Marina [ 21/Jan/16 ] |
|
Having a separate tool is an approach that has been discussed in the past. Users looking to upgrade would need to download the latest version of the tool to upgrade to the latest version of MongoDB, so it's easier to make that tool part of the newer version of the database, right? Then whether the tool is a stand-alone binary or part of the shell is an implementation detail. |
| Comment by Daniel Doubrovkine [ 21/Jan/16 ] |
|
FWIW the idea that I need to use a newer check to run a check against an existing DB is so so. I would remove upgradeCheck as you suggest altogether and do something better. A completely separate upgrade tool that can just take any version of MongoDB and run any sanity checks on it for upgrading to whatever next version is probably what you want. You only need to maintain one of such tools that's compatible with all the supported versions of the system, it's a frankenstein of exceptions and checks. This is how UPGRADING of any project works, you just walk your way up from the version you have to the next and make changes in reverse order. |
| Comment by Daniel Pasette (Inactive) [ 21/Jan/16 ] |
|
It's a little more complicated. I think ideally, there should be a standard way that one upgrade from one major version to the next. We already document (but do not always enforce) that users must upgrade in order, ie., 2.4 -> 2.6 ->3.0 -> 3.2 -> etc. However, we only specifically created an upgradeCheck() function for 2.4 -> 2.6. As part of standard upgrade procedure, we could have a specific upgradeCheck() procedure that can be run on each version upgrade. If it's a no-op from one version to the next, then communicate that in both documentation and in the output of the script, but it should be specific what the upgradeCheck is doing. For example, if we relax the index key length restriction in a future version of mongodb, the upgrade check used in 2.6 may be invalid. It's also a little awkward because the upgradeCheck code can only be released with the next version. So, the process is download the next version shell, and run it on the last server version. This is error prone and a little hard to communicate. This can be difficult for users who are not allowed to simply download a tarball onto their machine and execute a script on their production database. I'm not sure how to get around that though. This all needs to be thought through more. In the meantime, I'd like to use this ticket to simply remove the upgradeCheck shell function from 3.2 and 3.0 and fix the documentation. |
| Comment by Daniel Doubrovkine [ 21/Jan/16 ] |
|
Are you saying 3.x is not supposed to work against a 2.4 database? It needs to fail loudly in that case, not just be documented. |
| Comment by Daniel Pasette (Inactive) [ 21/Jan/16 ] |
|
This checker was designed to work for upgrades from 2.4 to 2.6 while running server version 2.4, but the mongodb documentation does not state that it is only valid to use the 2.6 shell. |
| Comment by Daniel Doubrovkine [ 20/Jan/16 ] |
|
This was ported from a discussion in https://jira.mongodb.org/browse/SERVER-12983. |