[SERVER-1588] mongodump/mongoexport should issue its own lock command Created: 07/Aug/10  Updated: 15/Dec/12  Resolved: 15/Dec/12

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: 1.4.0, 1.4.1, 1.4.2, 1.4.3, 1.4.4, 1.5.0, 1.5.1, 1.5.2, 1.5.3, 1.5.4, 1.5.5, 1.5.6, 1.5.7, 1.5.8, 1.6.0
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Justin Dearing Assignee: Eliot Horowitz (Inactive)
Resolution: Duplicate Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All environments


Issue Links:
Depends
depends on SERVER-1423 reads often aren't possible while in ... Closed
Operating System: ALL
Participants:

 Description   

Mongodump and mongoexport have two forms of operation. They either connect to a running mongod instance or they operate directly on a mongo data directory. What I learned recently from Kristinia's blog (http://www.snailinaturtleneck.com/blog/2010/07/26/mongodb-backups-corn-on-the-cob-in-10-minutes/) was that it does not lock the database before dumping for ensure consistency.

There should be a switch to opt into a locking the database, I propose l/-lockDatabases.This will simplify backup scripts.



 Comments   
Comment by Eliot Horowitz (Inactive) [ 15/Dec/12 ]

SERVER-2279

Comment by A. Jesse Jiryu Davis [ 15/Dec/12 ]

This ticket is similar to SERVER-2279, and similarly depends on SERVER-1423 being fixed first.

Comment by Kenn Ejima [ 31/May/12 ]

Found this ticket while I'm looking for this --lock option. +1.

I think mongodump is typically used by small-scale use cases, where --oplog is probably unavailable. Once you're in the scale that you need a replica set, you wouldn't need mongodump for daily backups, rather use LVM snapshot, etc.

People are either doing lock-fsync-mongodump-unlock dance, or just backing up non-point-in-time backups, and right now the complexity of the former discourages people to do it right, IMO.

Comment by Eliot Horowitz (Inactive) [ 26/Apr/11 ]

It only works if you have an oplog, so either any replica set member, or a regular master.

Comment by Justin Dearing [ 26/Apr/11 ]

Eliot,

I didn't know about --oplog until just now. If --oplog will work on a standalone server, or the slave of a master slave pair (my particular use case) then I guess you can close.

Comment by Eliot Horowitz (Inactive) [ 26/Apr/11 ]

Is this really needed now that the --oplog feature exists?

Comment by Eliot Horowitz (Inactive) [ 07/Aug/10 ]

No new cases are going into 1.7 unless they are bugs or widely asked for.
There are already a lot of important/highly voted cases, so have to cut, not add.

If you coded it, we wouldn't have a problem merging it in.

Comment by Justin Dearing [ 07/Aug/10 ]

Thanks for clarifying my verbiage.

Why is this targeted for 1.9 and not 1.7? Is it just time frame, or planned architectural changes.

Specifically, if I wanted to start coding this feature myself right now (which I'm not) is there a reason I shouldn't.

Comment by Eliot Horowitz (Inactive) [ 07/Aug/10 ]

I think there is a bit of confusion.

mongodump is consistent and safe, but not a point in time snapshot.

for example if you add or delete objects while the dump is running, the dump may or may not get those changes.

So it kind of make ssense to have a write lock mode for a point in time snapshot

Generated at Thu Feb 08 02:57:27 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.