[DOCS-4931] Add note about when it's safe to fsyncUnlock after EBS snapshot Created: 06/Mar/15  Updated: 11/Jan/17  Resolved: 20/Jun/15

Status: Closed
Project: Documentation
Component/s: ecosystem
Affects Version/s: None
Fix Version/s: 01112017-cleanup

Type: Improvement Priority: Major - P3
Reporter: Joanna Cheng Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Participants:
Days since reply: 8 years, 34 weeks, 4 days ago

 Description   

For this page: http://docs.mongodb.org/ecosystem/tutorial/backup-and-restore-mongodb-on-amazon-ec2/#unlock-the-database

From the AWS documentation (bolding is mine):

You can take a snapshot of an attached volume that is in use. However, snapshots only capture data that has been written to your Amazon EBS volume at the time the snapshot command is issued. This might exclude any data that has been cached by any applications or the operating system. If you can pause any file writes to the volume long enough to take a snapshot, your snapshot should be complete. However, if you can't pause all file writes to the volume, you should unmount the volume from within the instance, issue the snapshot command, and then remount the volume to ensure a consistent and complete snapshot. You can remount and use your volume while the snapshot status is pending.

The current sentence is not clear about this

After the snapshots have been created, the database can be unlocked.

I propose changing this to something along the lines of

Once the snapshots are in state "pending" (as in the above example), the database can be unlocked.



 Comments   
Comment by Githook User [ 20/Jun/15 ]

Author:

{u'username': u'kay-kim', u'name': u'kay', u'email': u'kay.kim@10gen.com'}

Message: DOCS-4931 specify when you can unlock the database after ebs snapshot
Branch: master
https://github.com/mongodb/docs-ecosystem/commit/959dca6d366ab757e6ed1e17972cebcf2522f0d6

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