[SERVER-23919] Database/Collection drop during initial sync can cause collmod to fail initial sync Created: 25/Apr/16  Updated: 18/May/17  Resolved: 02/May/16

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: 3.0.13, 3.2.7, 3.3.6

Type: Bug Priority: Major - P3
Reporter: Scott Hernandez (Inactive) Assignee: Eric Milkie
Resolution: Done Votes: 0
Labels: code-only
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-28151 Authentication database should be syn... Closed
is related to SERVER-20677 Failed collMod during replication res... Closed
is related to SERVER-23932 Get collection info ASAP after listDa... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Completed:
Sprint: Repl 14 (05/13/16)
Participants:
Linked BF Score: 0

 Description   

If during the cloning of collections the database is dropped then it is possible that none of the collections are copied – same can happen with a collection as well. If we then apply an operation from the oplog which tries to change that collection, like collMod, it is possible for it fail and error (causing a shutdown of the server).

We should write a test to reproduce this before we attempt a fix, to ensure it is a real problem.

One possible solution might be that we check if the collection still exists remotely and if not, ignore the error – since the database will be dropped later in the oplog.



 Comments   
Comment by Githook User [ 19/May/16 ]

Author:

{u'username': u'milkie', u'name': u'Eric Milkie', u'email': u'milkie@10gen.com'}

Message: SERVER-23919 fix call to userCreateNS
Branch: v3.0
https://github.com/mongodb/mongo/commit/60109c530d7df9b7ad2e41bdec917fbf8f9ea74e

Comment by Githook User [ 19/May/16 ]

Author:

{u'username': u'milkie', u'name': u'Eric Milkie', u'email': u'milkie@10gen.com'}

Message: SERVER-23919 gather all collection names at the start of initial sync
Branch: v3.0
https://github.com/mongodb/mongo/commit/2ce439622ee3930b395e97ced681cbc9685c4147

Comment by Eric Milkie [ 03/May/16 ]

This is fixed for collmod's that modify the collection. For collmod that modifies an index on the collection (the flag called "index"), there is a still a problem. See SERVER-20677.

Comment by Githook User [ 02/May/16 ]

Author:

{u'username': u'milkie', u'name': u'Eric Milkie', u'email': u'milkie@10gen.com'}

Message: SERVER-23919 gather all collection names at the start of initial sync

(cherry picked from commit c52c530428fbbe0cae1293ad6605c3ab7be2a281)
Branch: v3.2
https://github.com/mongodb/mongo/commit/fdbaa6d5be2c3aca8d69b6a4ae1830a0b439bc2f

Comment by Githook User [ 02/May/16 ]

Author:

{u'username': u'milkie', u'name': u'Eric Milkie', u'email': u'milkie@10gen.com'}

Message: SERVER-23919 gather all collection names at the start of initial sync
Branch: master
https://github.com/mongodb/mongo/commit/c52c530428fbbe0cae1293ad6605c3ab7be2a281

Comment by Eric Milkie [ 26/Apr/16 ]

I think if we gather and create all collections in all db's at the start of cloning, that should close the race to something small. If we still lose the race, the initial sync will simply restart when it gets to the collMod op.

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