-
Notifications
You must be signed in to change notification settings - Fork 695
GEODE-3801: Use hardlinks for backup oplog files #963
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
* Oplog files that are backed up are read-only. For this reason,
they can be transfered to the backup location through hard links,
instead of copying the file. This change improves speed of backups.
If the creation of a hard link fails, we revert to the existing copy
behavior.
* During backups, the copying of the oplog's krf file was being done while
that file could still be in the process of writing. This change ensures
that if a krf is to be written, that it is finished and included in the
backup
* cleanup existing oplog tests
kirklund
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Everything looks good to me except the one log statement I commented on.
| try { | ||
| Files.createLink(targetDir.toPath().resolve(file.getName()), file.toPath()); | ||
| } catch (IOException | UnsupportedOperationException e) { | ||
| logger.warn("Unable to create hard link for + " + targetDir + ". Reverting to file copy"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You have an extra + after inside the log statement quotes.
The Log4J2 way is to use their parameters:
logger.warn("Unable to create hard link for {}. Reverting to file copy", targetDir);
kirklund
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1
pivotal-eshu
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1
| private void backupFile(File targetDir, File file) throws IOException { | ||
| if (file != null && file.exists()) | ||
| try { | ||
| Files.createLink(targetDir.toPath().resolve(file.getName()), file.toPath()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any reason you cannot use a symbolic link here? That way it would allow the link to span filesystems too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The use of a hard link here is to replace the existing logic of making a copy of the original file for the backup. Deletion of the original file cannot be allowed to result in loss of that file in the backup location and thus a symbolic link cannot be used in this case. Hard links can be used here in place of copying the file only because the Oplog files being copied are guaranteed to be read-only.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK - that makes sense. Thanks for the explanation.
…pache#963)" This reverts commit 6a4e50e. The revision is causing a hang in Backup which is filed as GEODE-3940.
…pache#963)" This reverts commit 6a4e50e. The revision is causing a hang in Backup which is filed as GEODE-3940.
* Oplog files that are backed up are read-only. For this reason, they can be transfered to the backup location through hard links, instead of copying the file. This change improves speed of backups. If the creation of a hard link fails, we revert to the existing copy behavior. * During backups, the copying of the oplog's krf file was being done while that file could still be in the process of writing. This change ensures that if a krf is to be written, that it is finished and included in the backup * cleanup existing oplog tests
* Oplog files that are backed up are read-only. For this reason, they can be transfered to the backup location through hard links, instead of copying the file. This change improves speed of backups. If the creation of a hard link fails, we revert to the existing copy behavior. * During backups, the copying of the oplog's krf file was being done while that file could still be in the process of writing. This change ensures that if a krf is to be written, that it is finished and included in the backup * cleanup existing oplog tests
…pache#963)" This reverts commit 6a4e50e. The revision is causing a hang in Backup which is filed as GEODE-3940.
they can be transfered to the backup location through hard links,
instead of copying the file. This change improves speed of backups.
If the creation of a hard link fails, we revert to the existing copy
behavior.
that file could still be in the process of writing. This change ensures
that if a krf is to be written, that it is finished and included in the
backup