[SERVER-8767] journal files and lvm snapshots Created: 27/Feb/13  Updated: 08/Mar/13  Resolved: 28/Feb/13

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

Type: Task Priority: Major - P3
Reporter: Jason Mathis Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

amazon linux replica set hidden secondary


Participants:

 Description   

I am in the process of implementing and automating lvm snapshot backups and restores. New to LVM and filesystem backups for databases.

After the snapshot I am archiving each database into a separate gzip file. I need to have the option of restoring any one database at a time.

My question is about the journaling piece. We do have it enabled, so according to your docs I don’t have to lock the server. Although I am assuming I would need to grab those journal files.

On the restore:

1. If I restore one database with the journal files as well.
a. Will this roll forward transactions on a database currently on the server NOT be restoring but with the same name from where the backup came from?
b. What happens to the CURRENT transactions on the server I am restoring to? Gone right? Unless you fsync and wait before the restore?
c. Is it ok to restore to a server where transactions in the journal are for a database not on the server I am restoring to?
d. Best practice> Should we be shutting down the server for a restore or can you just lock the server and copy the files over? On the shutdown, will the transaction in the journal roll forward over the newly restored database when the service is started?

I don’t have a problem just locking the server if this would get around all these issues. On both the backup and restore? Do I have to wait 60 seconds? I am fine with this as well its a hidden secondary and if it’s always 60 seconds it’s no problem.

Thanks!



 Comments   
Comment by Daniel Pasette (Inactive) [ 05/Mar/13 ]

fsync is a synchronous command by default. see doc: http://docs.mongodb.org/manual/reference/command/fsync/. It's not possible to restore into a different db with this method. You would have to use mongodump/mongorestore to restore into a different db.

Comment by Jason Mathis [ 04/Mar/13 ]

Also is it possible to restore into another database using this method? I am assuming not.

Comment by Jason Mathis [ 01/Mar/13 ]

Ok, sounds good. fsync it is.

Should I be waiting for any specific time after the fsync?

Thanks!

Comment by Eliot Horowitz (Inactive) [ 28/Feb/13 ]

You are correct in thinking an lvm snapshot of a running system will make restoring a single database very hard.

I would do an fsync+lock on a secondary, and then you can gzip each database safely.

For a restore, you would either have to shutdown, and replace the files, or drop the database and import.

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