[SERVER-13235] 2.6 mongorestore --dbpath fails to restore into to a 2.4 server Created: 17/Mar/14 Updated: 10/Dec/14 Resolved: 21/May/14 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Security, Tools |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Michael O'Brien | Assignee: | Spencer Brody (Inactive) |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | 26qa | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Operating System: | ALL | ||||
| Participants: | |||||
| Description |
|
repro script is at https://github.com/10gen/QA/blob/master/QA-404/dumprestore_dbpath.js just uncomment line 184:
this text attempts to start up a 2.4 server (source), another 2.4 server (target), insert a bunch of users in the source, shut down both servers, mongodump from the source and restore into target. Mongorestore logs this error:
|
| Comments |
| Comment by Spencer Brody (Inactive) [ 19/Mar/14 ] |
|
Workarounds are to use mongorestore from v2.4 or to start a mongod on the target datafiles and restore to it without --dbpath |
| Comment by Spencer Brody (Inactive) [ 18/Mar/14 ] |
|
We use the buildinfo command to detect the version of the target system, and then have some safety checks based on the schema version of the user data and the target system's mongodb version. The problem is that when we're using --dbpath, we're running the buildinfo command with a DBDirectClient, which will always report the version of mongorestore itself (as the data files on disk have no mongodb server version associated with them). So right now when using --dbpath mongorestore will always think it's talking to a v2.6 system, even if the datafiles were generated by a 2.4 mongod. One potential fix is to require the user to specify the target mongodb version of the data files being restored into whenever --dbpath is used. Then we could do our safety checks based on that. Another option would be to infer the target server version from the authz schema version. The downside to this is that we wouldn't be able to distinguish between a 2.4 system and a non-upgraded 2.6 system, so we may end up violating the constraint that user data is readonly after upgrade to 2.6 until the user data upgrade process is run. |