[SERVER-18310] Can't rollback dropCollection if new primary renamed the collection Created: 04/May/15  Updated: 06/Dec/22  Resolved: 15/Nov/17

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

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

Issue Links:
Depends
depends on SERVER-29959 Fix renameCollection step in rollback... Closed
Duplicate
duplicates SERVER-4941 collection rename may not replicate /... Closed
Related
Assigned Teams:
Replication
Backwards Compatibility: Fully Compatible
Operating System: ALL
Participants:
Linked BF Score: 0

 Description   

Node A's oplog:
optime 1: dropCollection foo

Node B's oplog:
optime 1': renameCollection foo -> bar

When node A enters rollback it will try to "undo" the dropCollection by resyncing the foo collection from node B. But node B won't have any foo collection anymore since it has been renamed to bar. This will cause the nodes to silently be out of sync.



 Comments   
Comment by Judah Schvimer [ 15/Nov/17 ]

This was fixed by the "Safe Rollback" project (PM-842) in SERVER-29959.

Comment by Eric Milkie [ 26/Aug/15 ]

I believe this is a problem for any op in the renamed collection that needs to be rolled back, not just dropCollection. Using idents to uniquely identify collections instead of names will solve this.

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