[SERVER-27147] Do not initial sync data written with setReplicatedWrites(false) Created: 21/Nov/16  Updated: 06/Dec/22  Resolved: 07/Jun/18

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

Type: Bug Priority: Major - P3
Reporter: Judah Schvimer Assignee: Backlog - Replication Team
Resolution: Done Votes: 0
Labels: todo_in_code
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-35498 Unblacklist mapReduce tests from the ... Closed
Related
related to SERVER-33638 CheckReplDBHash should ignore mapredu... Closed
related to SERVER-27206 blacklist tests involving MapReduce f... Closed
related to SERVER-42554 Complete TODO listed in SERVER-27147 Closed
related to SERVER-43460 Complete TODO listed in SERVER-27147 Closed
related to SERVER-26965 Use RAII type for turning off replica... Closed
related to SERVER-31216 Mark internal collections in metadata... Closed
is related to SERVER-35365 MapReduce temporary inc collections s... Closed
Assigned Teams:
Replication
Operating System: ALL
Participants:
Linked BF Score: 16

 Description   

In MapReduce, incremental collections are cloned in initial sync even though they are created with setReplicatedWrites(false). This appears to be the only place this is an issue, though we should make sure there are no other places where this should be handled.



 Comments   
Comment by Spencer Brody (Inactive) [ 07/Jun/18 ]

MapReduce inc collections were the only known offenders here, and those were moved to the local database in SERVER-35365. Thus this issue has gone away.

I filed SERVER-35498 for re-enabling test coverage of initial sync and mapReduce.

Comment by Judah Schvimer [ 17/Mar/17 ]

This is also an issue for convertToCapped. If a server creates the temporary collection and then crashes before renaming it, it will leave a temporary collection around until it is elected primary. At startup and rollback we should also drop these "local temporary" collections.

Comment by Andy Schwerin [ 09/Dec/16 ]

I believe that when this happens, if the node that has replicated the "no replicate" collection is elected primary, it will delete that temp collection, and then the secondaries will crash because they don't know about the collection. On restart, if some other node is elected primary, the suspect node will enter rollback, see that the temporary collection no longer exists, and happily go about its recovery, ending up in a consistent state. Not great, but not corrupting. Since this bug has existed as long as mapreduce and I've never heard a user complaint, I'm not going to schedule this work now.

Comment by Andy Schwerin [ 09/Dec/16 ]

I think the real problem is that mapreduce is doing the wrong thing by creating these non-replicated temp collections somewhere other than the "local" database. Or that we need to be able to mark collections as non-replicated, but that seems... perilous.

Comment by Judah Schvimer [ 29/Nov/16 ]

When fixing this, also un-blacklist the MapReduce tests from the initial sync dynamic passthroughs.

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