-
Type: Bug
-
Resolution: Done
-
Priority: Major - P3
-
Affects Version/s: 2.6.1, 2.7.0
-
Component/s: Replication, Storage
-
None
-
ALL
ISSUE SUMMARY
When a collection contains invalid options, cloning it will result in a collection created with default options. As a result, collections with invalid options created by an initial sync or using the copyDatabase command may lose some of their properties like their allocation strategy, or become non-capped collections.
USER IMPACT
Different members on a replica set might become out of sync when capped collections become non-capped during initial sync. In this scenario, or when the original storage strategy for a cloned collection is modified, storage utilization may be adversely affected. Only collections created with invalid options are affected by this issue.
WORKAROUNDS
N/A
AFFECTED VERSIONS
MongoDB production releases 2.6.0 and 2.6.1 are affected by this issue.
FIX VERSION
The fix is included in the 2.6.2 production release.
RESOLUTION DETAILS
Collections with invalid options are no longer cloned.
Original description
Cloner::go() proceeds with a collection copy even if the call to userCreateNS() fails, in which case the collection is created with default options (by the insert of the first document). As a result, collections created by an initial sync or the copydb command can lose their cappedness or allocation strategy.
Reproduce by creating a collection with invalid options in 2.4.10:
> db.version() 2.4.10 > db.runCommand({create: "foo", capped: true, size: 1024*1024, max: "foobar"}) { "ok" : 1 } > db.foo.insert({}) Cannot use commands write mode, degrading to compatibility mode WriteResult({ "nInserted" : 1 })
And then upgrading to 2.6.1 and attempting to use copydb:
> db.version() 2.6.1 > db.copyDatabase("test","test2") { "ok" : 1 } > db.system.namespaces.find() { "name" : "test.system.indexes" } { "name" : "test.foo.$_id_" } { "name" : "test.foo", "options" : { "create" : "foo", "capped" : true, "size" : 1048576, "max" : "foobar" } } > db.foo.stats().capped true > db.getSiblingDB("test2").system.namespaces.find() { "name" : "test2.foo" } // INCORRECT: "foo" is no longer capped { "name" : "test2.system.indexes" } { "name" : "test2.foo.$_id_" } > db.getSiblingDB("test2").foo.stats().capped >
- is duplicated by
-
SERVER-13927 Copydb breaks on (some) capped collections
- Closed
- related to
-
SERVER-13968 Report invalid collection options in "<db>.system.namespaces" in upgrade checker
- Closed