[SERVER-14132] Warn during initial sync if _id index missing on any cloned collection Created: 02/Jun/14  Updated: 06/Dec/22  Resolved: 13/Dec/18

Status: Closed
Project: Core Server
Component/s: Index Maintenance, Replication
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: J Rassi Assignee: Backlog - Replication Team
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-8237 autoIndexId:false should be disabled Closed
is related to SERVER-19067 Warn at creation that autoIndexId:fal... Closed
is related to DOCS-3523 "autoIndexId" collection option shoul... Closed
is related to SERVER-38624 Do not allow node to startup with aut... Closed
Assigned Teams:
Replication
Sprint: Quint Iteration 7, QuInt 8 08/28/15, Quint 9 09/18/15, QuInt A (10/12/15)
Participants:

 Description   

The server logs a warning at startup if any collection is missing an _id index. A startup warning should also be generated at time of initial sync for any cloned collection that does not have this index.

Correctness of replication is not guaranteed for any collection that is missing this index. To illustrate a simple example: the following script inserts two documents into a replicated collection without an _id index, and shows that the secondary's copy of the collection ends up with only one document.

var rst = new ReplSetTest({nodes: 2});
rst.startSet();
rst.initiate();
var primary = rst.getPrimary();
primary.getCollection("test.foo").runCommand("create", {autoIndexId: false});
primary.getCollection("test.foo").insert({_id: 0, a: 1});
primary.getCollection("test.foo").insert({_id: 0, a: 2});
rst.awaitReplication();
var secondary = rst.getSecondary();
assert.eq(primary.getCollection("test.foo").count(), secondary.getCollection("test.foo").count());
// Line 10 throws "assert: [2] != [1] are not equal : undefined"



 Comments   
Comment by Gregory McKeon (Inactive) [ 13/Dec/18 ]

We banned new autoIndexId collections in 4.0 under SERVER-8237.

Comment by Githook User [ 23/Feb/15 ]

Author:

{u'username': u'milkie', u'name': u'Eric Milkie', u'email': u'milkie@10gen.com'}

Message: SERVER-14132 update test for missing _id index
Branch: master
https://github.com/mongodb/mongo/commit/07420bdfb60fd6e976b0588d91afbfdc40685ec5

Comment by Eric Milkie [ 23/Feb/15 ]

jstests/repl/repl16.js contains some test code Aaron wrote that can show how replication can malfunction without the uniqueness guarantees provided by an _id unique index.

Comment by Eric Milkie [ 05/Feb/15 ]

The code to handle missing _id fields was, in 2.4, when we passed QueryPlanSelectionPolicy::idElseNatural() to updateObjectsForReplication(), but in 2.6 all that went away and we now just call update(). The idElseNatural selection policy was added by Aaron specifically to support this use case in replication, I believe. Today, I think the query planner internally figures out what to do? I'm not sure if it still works if you pass it a query doc without an _id.

The code to handle missing _id index is: https://github.com/mongodb/mongo/blob/master/src/mongo/db/repl/oplog.cpp#L709

Comment by Andy Schwerin [ 05/Feb/15 ]

I thought the code was there to handle missing _id fields, not missing _id indexes. Can you add a link to the code you're referring to?

Comment by Eric Milkie [ 05/Feb/15 ]

The code to handle updates on documents without the index on _id is still there, and it's still pretty easy to create collections with autoIdIndex:false, so I think this ticket work stands as described.
Additional work could be to fail any import of a document without an _id during initial sync, but that would be very hard to achieve – I think you'd have to use godInsert on the primary to get that.

Comment by Andy Schwerin [ 05/Feb/15 ]

Can we just start failing the initial sync in these cases for new versions of mongod? The _id field is required by replication, now.

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