[SERVER-22605] A failed copydb command leads to mismatched indexes on replica set nodes Created: 13/Feb/16  Updated: 06/Dec/22  Resolved: 13/Jan/20

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: 3.1.3
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Kamran K. Assignee: Backlog - Replication Team
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
Assigned Teams:
Replication
Operating System: ALL
Steps To Reproduce:

'use strict';
 
var rst = new ReplSetTest({nodes: 2});
rst.startSet();
rst.initiate();
 
var primary = rst.getPrimary();
var secondary = rst.getSecondary();
 
var testDB = primary.getDB('test');
var targetDB = 'test2';
 
// Create a collection with document validation enabled.
var res = testDB.createCollection('foo', {
    validator: {a: {$exists: true}},
    validationLevel: 'strict',
    validationAction: 'error'
});
assert.commandWorked(res);
 
// Insert a document that fails validation to cause the subsequent copydb command to fail.
res = testDB.runCommand({insert: 'foo', documents: [{}], bypassDocumentValidation: true});
assert.commandWorked(res);
 
// The copydb command fails because we do not bypass document validation.
res = testDB.adminCommand({
    copydb: 1,
    fromdb: 'test',
    todb: targetDB,
});
assert.commandFailedWithCode(res, ErrorCodes.DocumentValidationFailure);
 
rst.awaitReplication();
 
// Print out the oplog for debugging.
printjson(primary.getDB('local').oplog.rs.find().toArray());
 
// The failed copydb command leaves an _id index on the secondary but not the primary.
var primaryIndexes = primary.getDB(targetDB).foo.getIndexes();
var secondaryIndexes = secondary.getDB(targetDB).foo.getIndexes();
 
assert.docEq(primaryIndexes, secondaryIndexes);

Participants:
Linked BF Score: 0

 Description   

A copydb command will fail if a collection in the database contains a document that fails validation. When this occurs, a secondary will contain a collection with an _id index, whereas the corresponding primary will be missing that same _id index.

Oplog dump:

[
	{
		"ts" : Timestamp(1455321967, 1),
		"h" : NumberLong("-2943391995913786641"),
		"v" : 2,
		"op" : "n",
		"ns" : "",
		"o" : {
			"msg" : "initiating set"
		}
	},
	{
		"ts" : Timestamp(1455321978, 2),
		"t" : NumberLong(1),
		"h" : NumberLong("-7019435253571208007"),
		"v" : 2,
		"op" : "n",
		"ns" : "",
		"o" : {
			"msg" : "new primary"
		}
	},
	{
		"ts" : Timestamp(1455321978, 3),
		"t" : NumberLong(1),
		"h" : NumberLong("3677791815055733623"),
		"v" : 2,
		"op" : "c",
		"ns" : "test.$cmd",
		"o" : {
			"create" : "foo",
			"validator" : {
				"a" : {
					"$exists" : true
				}
			},
			"validationLevel" : "strict",
			"validationAction" : "error"
		}
	},
	{
		"ts" : Timestamp(1455321978, 4),
		"t" : NumberLong(1),
		"h" : NumberLong("-5242686880532286683"),
		"v" : 2,
		"op" : "i",
		"ns" : "test.foo",
		"o" : {
			"_id" : ObjectId("56be737a8e9c12d16896f4c6")
		}
	},
	{
		"ts" : Timestamp(1455321978, 5),
		"t" : NumberLong(1),
		"h" : NumberLong("4831483178064446599"),
		"v" : 2,
		"op" : "c",
		"ns" : "test2.$cmd",
		"o" : {
			"create" : "foo",
			"validator" : {
				"a" : {
					"$exists" : true
				}
			},
			"validationLevel" : "strict",
			"validationAction" : "error"
		}
	}
]



 Comments   
Comment by Evin Roesle [ 13/Jan/20 ]

As copydb has been deprecated since 4.0, we are closing this ticket. If you are experiencing this issue without a way to remediate, please reopen this ticket.

Comment by Judah Schvimer [ 06/Jan/20 ]

Note: copydb has been deprecated since 4.0.

Comment by Kamran K. [ 13/Feb/16 ]

It's not clear to me if this is a replication issue or just an issue with the copydb command, but I thought I'd mark it as a replication bug for now.

Generated at Thu Feb 08 04:00:53 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.