[SERVER-46550] Enabling sharding creates a database without an oplog entry Created: 02/Mar/20  Updated: 27/Oct/23  Resolved: 25/Aug/20

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

Type: Bug Priority: Major - P3
Reporter: Matthew Russotto Assignee: Garaudy Etienne
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File server46550_repro.js    
Issue Links:
Related
related to SERVER-50532 Cannot require that database exists w... Closed
related to SERVER-50540 Complete TODO listed in SERVER-46550 Closed
related to SERVER-46221 Remove oplogApplicationEnforcesSteady... Open
is related to SERVER-21700 Do not relax constraints during stead... Closed
Operating System: ALL
Steps To Reproduce:

I have attached a repro; it prints out the oplogs showing two dropDatabase entries in a row (and no createDatabase) for the affected database.

Participants:

 Description   

If we run enableSharding and movePrimary on a database, we can cause it to be created (for the purpose of dropDatabase) without a "create" oplog entry. It appears that on the primary shard this does not cause a problem. On a non-primary shard the database will be created on the primary but not the secondary, so if a dropDatabase is run, it will create an oplog entry to delete a database the secondary does not think exists.



 Comments   
Comment by Matthew Russotto [ 25/Aug/20 ]

I had a Slack conversation with Eric, and the conclusion is that because databases are ephemeral, applying a 'dropDatabase' cannot enforce that the database exists. I will create a ticket for that and we can close this one out.

Comment by Garaudy Etienne [ 24/Aug/20 ]

matthew.russotto any updates here?

Comment by Eric Milkie [ 22/Jul/20 ]

The steps-to-reproduce talks about a "createDatabase" oplog entry, but no such thing exists in MongoDB. Databases are only implicitly created by other operations.

Generated at Thu Feb 08 05:11:48 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.