[SERVER-25040] Initial syncing node maintains tmp collection from map reduce when primary has renamed it Created: 13/Jul/16  Updated: 19/Dec/16  Resolved: 19/Dec/16

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

Type: Bug Priority: Major - P3
Reporter: Judah Schvimer Assignee: Siyuan Zhou
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File tmpCollection.txt    
Issue Links:
Depends
depends on SERVER-25332 Initial sync bootstrap needs to handl... Closed
Duplicate
duplicates SERVER-26117 renameCollection 'c' op should restar... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Repl 17 (07/15/16), Repl 18 (08/05/16), Repl 2016-08-29
Participants:
Linked BF Score: 0

 Description   

When running the small_oplog_rs_initsync passthrough we get an error where a temporary collection created in a mapreduce is not renamed on teh secondary even though it is on the primary.



 Comments   
Comment by Spencer Brody (Inactive) [ 19/Dec/16 ]

Re-opening to change resolution since no commits happened on this ticket

Comment by Judah Schvimer [ 11/Aug/16 ]

This appears to be another issue of metadata idempotency.

Consider

{ ts: Timestamp 1468367378000|6, t: 1, h: 1161015165816820222, v: 2, op: "c", ns: "test.$cmd", o: { renameCollection: "test.tmp.mr.mr_merge_1", to: "test.mr_merge_out", stayTemp: false, dropTarget: false } }

When we call listCollections, it returns test.mr_merge_out so we clone test.mr_merge_out.
We then get to the applyOps phase.
First we apply

{ ts: Timestamp 1468367378000|1, t: 1, h: -3741401790110643680, v: 2, op: "c", ns: "test.$cmd", o: { create: "tmp.mr.mr_merge_1", temp: true } }


Then eventually we apply

{ ts: Timestamp 1468367378000|6, t: 1, h: 1161015165816820222, v: 2, op: "c", ns: "test.$cmd", o: { renameCollection: "test.tmp.mr.mr_merge_1", to: "test.mr_merge_out", stayTemp: false, dropTarget: false } }


We have dropTarget: false, which means that it will return a "NamespaceExists" error since the target namespace already exists. In oplog.cpp, "NamespaceExists" is an acceptable error for renameCollection, so this renameCollection will fail silently and both collections will exist on the secondary, as we see.

Comment by Judah Schvimer [ 13/Jul/16 ]

Example is here: https://logkeeper.mongodb.org/build/04af62a90a0ca2ec40f91f626bd08c06/all with tmp.mr.mr_merge_1

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