[SERVER-14556] Default dbpath for mongod --configsvr changes in 2.6 Created: 15/Jul/14 Updated: 11/Mar/15 Resolved: 17/Jul/14 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Admin |
| Affects Version/s: | 2.6.3 |
| Fix Version/s: | 2.6.4, 2.7.4 |
| Type: | Bug | Priority: | Critical - P2 |
| Reporter: | Jason R. Coombs | Assignee: | Matt Kangas |
| Resolution: | Done | Votes: | 0 |
| Labels: | community-team | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Operating System: | ALL | ||||||||||||
| Backport Completed: | |||||||||||||
| Steps To Reproduce: | 1. Deploy sharded cluster using MongoDB 2.4, not specifying dbpath for the mongod --configsvr instance. |
||||||||||||
| Sprint: | Server 2.7.4 | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
Issue Status as of Jul 18, 2014 ISSUE SUMMARY USER IMPACT The issue is exacerbated in the case where a config server and a regular mongod are co-located on the same host, and both processes rely on default dbpaths. In that case, the config server might read from the regular mongod dbpath, which can lead to undefined behavior and cluster instability. WORKAROUNDS AFFECTED VERSIONS FIX VERSION RESOLUTION DETAILS Original descriptionWe've discovered an undocumented backward-incompatible change when upgrading our sharded cluster from MongoDB 2.4 to 2.6. On 2.4, mongod defaults to `/data/configdb` for the dbpath. On 2.6, mongod defaults to `/data/db` for the dbpath. This change must be documented in the Upgrade Documentation but is not currently. If the deployment relies on the default path for the configdb, following the upgrade procedure will take down the entire cluster. |
| Comments |
| Comment by Githook User [ 22/Jul/14 ] | ||||||||||||||
|
Author: {u'username': u'kangas', u'name': u'Matt Kangas', u'email': u'matt.kangas@mongodb.com'}Message: (cherry picked from commit 7797c0ed4fc2ce61979ae5d8b0931d73e08855bc) Conflicts: | ||||||||||||||
| Comment by Githook User [ 17/Jul/14 ] | ||||||||||||||
|
Author: {u'username': u'kangas', u'name': u'Matt Kangas', u'email': u'matt.kangas@mongodb.com'}Message: | ||||||||||||||
| Comment by Thomas Rueckstiess [ 15/Jul/14 ] | ||||||||||||||
|
Hi Jason, Thanks for reporting this issue. I can confirm the different behavior of 2.4.10 vs. 2.6.3 regarding the dbpath, as shown in the log snippets below 2.4.10 startup log messages
2.6.3 startup log messages
Based on the 2.6 documentation of the mongod --configsvr option, I believe this is an unintentional change in behavior.
We'll investigate further and post updates to the ticket once we know more. In the mean time, the easiest work-around is to ensure that you explicitly set the --dbpath to the desired path. Regards, | ||||||||||||||
| Comment by Jason R. Coombs [ 15/Jul/14 ] | ||||||||||||||
|
Given the mitigating factor that /data/db must exist to take down the cluster, I'd say this is critical but not a blocker. | ||||||||||||||
| Comment by Jason R. Coombs [ 15/Jul/14 ] | ||||||||||||||
|
Note: if /data/db exists, the config server upgrade will complete, creating blank config instances. If /data/db does not exist, the config server upgrade will fail because the new instances will refuse to start. In our case, the former happened because the config servers were built with the same puppet recipes as our shard instances, and that recipe creates /data/db. |