[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: |
|
||||||||||||||||||||||||||||||||||||||||
| 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 I filed |
| 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. |