-
Notifications
You must be signed in to change notification settings - Fork 65
PSMDB-810 improve logging #695
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
base: v4.2
Are you sure you want to change the base?
Conversation
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.
Hi Igor. As you suggested in our slack chat, I think the special logging should be a log level 0.
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.
Thanks for changing the log level to 0 Igor.
I have some edit suggestions again though sorry.
log() << "Hot backup copying {} bytes from '{}' to '{}'"_format( | ||
fsize, srcFile.string(), destFile.string()); |
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.
log() << "Hot backup copying {} bytes from '{}' to '{}'"_format( | |
fsize, srcFile.string(), destFile.string()); | |
log() << "Beginning copy of {}/{} files in backup snapshot: {}, {} bytes"_format( | |
fcCtr++, filesList.size(), srcFile.filename(), fsize); |
(The fcCtr variable needs to be defined just a bit above of course.)
As for the destFile I think the destination directory only needs to be shown once as the backup process begins. (The destination incidentally also appears in the argument values of the "command: createBackup" log message when it finishes.)
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.
I wish we could print the user-recognizable collection or index namespace string, when a file is a user-data table, but I don't find a map of "idents" -> namespaces. Only private member "NSToIdentMap _idents;" in the DurableCatalogImpl class, so we'd also have to change that class to access.
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.
pull request updated
} else { | ||
log() << "Source file size is: {} bytes"_format(fs::file_size(srcFile)); | ||
} | ||
|
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.
} else { | |
log() << "Source file size is: {} bytes"_format(fs::file_size(srcFile)); | |
} | |
} | |
Truncating the byte size log line from here because the preceding edit suggestion would include it there.
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.
My idea was to show current size of the file. It may be different from the size reported in another message (that size is captured when file list is generated)
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.
Thanks for catching the fcCtr increment bug.
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.
Regarding showing the size of the file it is true, it might become notably bigger during the backup. And that is so interesting to DBAs worried about file size growth that I first drafted an edit where it would warn() (not log) if the file size had grown (> +10% && > +100MB).
I don't think it's helpful for users to just be informed what the size is if it is not the same size as what is copied. I think they will see it as an error and report it.
But then I discarded that draft because the $backupCursor work will probably require us doing this all again, didn't seem worthwhile now.
} else { | ||
log() << "Source file size is: {} bytes"_format(fs::file_size(srcFile)); | ||
} | ||
|
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.
Thanks for catching the fcCtr increment bug.
} else { | ||
log() << "Source file size is: {} bytes"_format(fs::file_size(srcFile)); | ||
} | ||
|
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.
Regarding showing the size of the file it is true, it might become notably bigger during the backup. And that is so interesting to DBAs worried about file size growth that I first drafted an edit where it would warn() (not log) if the file size had grown (> +10% && > +100MB).
I don't think it's helpful for users to just be informed what the size is if it is not the same size as what is copied. I think they will see it as an error and report it.
But then I discarded that draft because the $backupCursor work will probably require us doing this all again, didn't seem worthwhile now.
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.
Pull Request Overview
This PR improves logging in the WiredTiger storage engine's hot backup functionality by adding detailed progress tracking and enhanced error reporting. The changes provide better visibility into backup operations and more informative error messages when issues occur.
- Adds progress logging showing current file copy status with file counts and sizes
- Enhances error handling with detailed context including file paths and error codes
- Improves file stream management by ensuring proper closure
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
You can also share your feedback on Copilot code review for a chance to win a $100 gift card. Take the survey.
@@ -1491,6 +1491,8 @@ static void copy_file_size(const boost::filesystem::path& srcFile, const boost:: | |||
dst.write(bufptr, cnt); | |||
fsize -= cnt; | |||
} | |||
|
|||
dst.close(); |
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 dst.close() call is redundant and potentially problematic. The ofstream destructor will automatically close the file when the function exits, and calling close() explicitly here could mask exceptions that occur during the write operations since close() is called outside the try-catch block that handles the file operations.
dst.close(); |
Copilot uses AI. Check for mistakes.
if (!fs::exists(srcFile)) { | ||
log() << "Source file does not exist: {}"_format(srcFile.string()); | ||
} else { | ||
log() << "Source file size is: {} bytes"_format(fs::file_size(srcFile)); |
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 fs::file_size() call can throw an exception if the file doesn't exist or there are permission issues, but it's not wrapped in a try-catch block. This could cause the backup operation to fail unexpectedly. Consider wrapping this call in a try-catch block or checking file existence first.
log() << "Source file size is: {} bytes"_format(fs::file_size(srcFile)); | |
try { | |
log() << "Source file size is: {} bytes"_format(fs::file_size(srcFile)); | |
} catch (const fs::filesystem_error& ex) { | |
log() << "Could not get source file size for '{}': {}"_format(srcFile.string(), ex.what()); | |
} |
Copilot uses AI. Check for mistakes.
for (auto&& file : filesList) { | ||
fs::path srcFile{std::get<0>(file)}; | ||
fs::path destFile{std::get<1>(file)}; | ||
auto fsize{std::get<2>(file)}; | ||
|
||
log() << "Beginning copy of {}/{} files in backup snapshot: {}, {} bytes"_format( | ||
++fcCtr, filesList.size(), srcFile.string(), fsize); |
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.
[nitpick] Logging every file copy operation could generate excessive log output for large backups with many files. Consider using a higher log level (e.g., debug) or throttling the logging to only show progress at intervals (e.g., every 100 files or every 10%).
++fcCtr, filesList.size(), srcFile.string(), fsize); | |
LOG(1) << "Beginning copy of " << (fcCtr + 1) << "/" << filesList.size() | |
<< " files in backup snapshot: " << srcFile.string() << ", " << fsize << " bytes"; | |
if ((fcCtr % 100 == 0) || (fcCtr + 1 == filesList.size())) { | |
log() << "Backup progress: copying file " << (fcCtr + 1) << " of " << filesList.size(); | |
} | |
++fcCtr; |
Copilot uses AI. Check for mistakes.
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.
Can you focus on improving log messages so they are more user / support friendly?
No description provided.