[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:
Related
is related to SERVER-29349 Delete shell/upgrade_check.js Closed
Assigned Teams:
Query
Backwards Compatibility: Fully Compatible
Operating System: ALL
Participants:

 Description   

Running 3.2.1 shell against a 2.4 MongoDB.

$ mongo ...
MongoDB shell version: 3.2.1
connecting to: ...
> db.upgradeCheck()
database 'gravity-staging' for 2.6 upgrade compatibility
...
Everything in 'gravity-staging' is ready for the upgrade!

This isn't true, the import will fail with

Failed: gravity-staging.featured_links: error creating indexes for gravity-staging.featured_links: createIndex error: Btree::insert: key too large to index, failing gravity-staging.featured_links.$subtitle_1 1040 { : "With his declaration that “painting relates to both art and life,” Robert Rauschenberg opened up the ivory tower that was postwar American paintin..." }

The command also runs suspiciously fast.

The 2.6.12 version of the command line client processes documents.

$ mongo ...
MongoDB shell version: 2.6.12-pre-
connecting to: sawyer.mongohq.com:10007/gravity-staging
> db.upgradeCheck()
database 'gravity-staging' for 2.6 upgrade compatibility
 
Checking database gravity-staging
 
Checking collection gravity-staging.ab_test_groups
 
Checking collection gravity-staging.access_controls
28481 documents processed
74362 documents processed
115745 documents processed
158064 documents processed
202519 documents processed
 
...

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 SERVER-29349.

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.

Generated at Thu Feb 08 03:59:50 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.