There had been a lot of questions about when db.fsyncLock() is necessary before creating a backup of your MongoDB files† and when it's not. And there are tricky things around using it, because if you get yourself into a state where you can't fsyncUnlock then you will have to bring down your `mongod` process by force.
I had been thinking about this problem and realized that one of the tricks to getting the problem minimized would be to run the backup from the same mongo shell sessions/script as the lock/unlock pair, so I wrote a little script to do that. The script defines a function called 'runBackup' which takes a string representing your backup command (so it could be a shell script, batch file, ec2-snapshot command, tar czf command, anything at all). The script checks that the server is not already locked, and if it's not, it acquires the lock, runs the command given, and upon its completion runs the unlock command.
The last line shows how to call this function - you can use this as a starting point to create your own.
The code is in my Github repo, along with many other little scripts that might be useful to people who are playing with mongo shell much of the time.
I had been thinking about this problem and realized that one of the tricks to getting the problem minimized would be to run the backup from the same mongo shell sessions/script as the lock/unlock pair, so I wrote a little script to do that. The script defines a function called 'runBackup' which takes a string representing your backup command (so it could be a shell script, batch file, ec2-snapshot command, tar czf command, anything at all). The script checks that the server is not already locked, and if it's not, it acquires the lock, runs the command given, and upon its completion runs the unlock command.
The last line shows how to call this function - you can use this as a starting point to create your own.
The code is in my Github repo, along with many other little scripts that might be useful to people who are playing with mongo shell much of the time.
† the general answer is that you only need fsyncLock/Unlock during backup if you are taking a file system snapshot and your journal is on different volume than your data files, or if you are using another way of copying files that can't guarantee getting the data files and journal files as of the same point in time. No other method requires fsyncLock, not mongodump, nor snapshots that can get data and journal files together.
RSS Feed
