[SERVER-33160] syncApply() treatment of delete operations on non-existent namespaces Created: 07/Feb/18  Updated: 29/Oct/23  Resolved: 09/Feb/18

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

Type: Improvement Priority: Major - P3
Reporter: Benety Goh Assignee: Benety Goh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-30220 Lock correct nss for syncApply by UUID Closed
is related to SERVER-30293 in syncApply, throw NamespaceNotFound... Closed
is related to SERVER-30521 in syncApply, throw NamespaceNotFound... Closed
is related to SERVER-32913 Parallelize application of applyOps o... Closed
Backwards Compatibility: Fully Compatible
Sprint: Repl 2018-02-12
Participants:

 Description   

syncApply currently throws NamespaceNotFound exceptions on delete operations that refer to non-existent namespaces, specifically in cases when the UUID resolves to a missing collection, or when the database referred in the "ns" field does not exist. This condition does not occur during normal server operation in 3.6. However, modifications to the applyOps command proposed in SERVER-32913 may introduce such delete operations, requested by the client, into the oplog application process on the secondary. Therefore, we should consider treating deletes on the secondary as no-ops.



 Comments   
Comment by Githook User [ 09/Feb/18 ]

Author:

{'email': 'benety@mongodb.com', 'name': 'Benety Goh', 'username': 'benety'}

Message: SERVER-33160 clean up syncApply() handling of delete ops
Branch: master
https://github.com/mongodb/mongo/commit/d1b2515a2d7dd4a22222de7d8905d6dc6b1ab1be

Comment by Githook User [ 08/Feb/18 ]

Author:

{'email': 'benety@mongodb.com', 'name': 'Benety Goh', 'username': 'benety'}

Message: SERVER-33160 syncApply() treats delete ops on non-existent namespaces as no-ops for idempotency reasons
Branch: master
https://github.com/mongodb/mongo/commit/99ec7ccdb0196b3826abfa5d987835b349f32e0d

Comment by Judah Schvimer [ 08/Feb/18 ]

This doesn't happen with rollback via refetch with UUIDs because we never refetch collections, and two phase drop ensures that we only ever drop UUIDs once they cannot be rolled back. For rollback without UUIDs, this can happen if at the common point the collection existed, but on both branches of history the collection was dropped. When rolling back the dropCollection, we try to refetch it from the sync source, but find nothing, so leave it dropped. Then during oplog application we see a delete entry (or any crud op) before the drop entry. This is almost certainly still a bug with rollback via refetch with no uuids for all crud ops and is simply untested.

Comment by Githook User [ 08/Feb/18 ]

Author:

{'email': 'benety@mongodb.com', 'name': 'Benety Goh', 'username': 'benety'}

Message: SERVER-33160 added syncApply() test cases for CRUD ops on non-existent namespaces
Branch: master
https://github.com/mongodb/mongo/commit/38aa3dfd1edd6a83540c9c5b5e654803cc960f69

Comment by Benety Goh [ 08/Feb/18 ]

SERVER-32913 may unpack an embedded delete op to be applied by SyncTail instead of executing it through the applyOps command, which suppresses namespace lookup errors on deletes.

Comment by Andy Schwerin [ 08/Feb/18 ]

How does SERVER-32913 introduce this possibility?

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