-
Notifications
You must be signed in to change notification settings - Fork 2
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
Add MariaDB dumpfile fetch and import. #11
Conversation
importMariaDBdmpFile/config.ini
Outdated
[logs] | ||
# set to 'info' for step-by-step summary | ||
# only 'error' or 'info' are implemented | ||
level=error |
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.
What's the output like when the logging level is error
? The current monitoring assumes no output on a successful run.
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 reading is that the current monitoring requires "completed ok" as the final line of output from a successful run. Any other condition is a failure.
I am re-working the logging to allow specification of a log file to which info/debug/error output is written while "completed ok" or an error message goes to stdout.
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.
so "completed ok" currently goes to the syslog via the logger
command, whereas the monitoring checks the log produced by the cron job that runs the import process hourly and assumes the underlying 1_runDbUpdate.sh
produces no output to stdout or stderr on a successful import.
You could have the logging report at the debug level rather than info - so if something is going wrong with the process one can switch the more verbose mode on.
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.
:lightbulb: 1_runDbUpdate.sh has an internal bash function 'logger' which (appears to me) is hardwired to output to a local file, so not to syslog. How does the output end up in syslog?
In any case, I've changed it so that stdout should be empty and "completed ok", or error message, will go in the specified log file, with return status as appropriate.
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.
ah yes, you're right - I mistook logger
for the pre defined function and not one that was defined in the script itself. And I've only just discovered updateLog.txt is even a thing...
error messages should go to stderr as well, I'm not convinced of the need to have two log files - one for the script and one for the cron.
Is It's referenced as |
codacy has highlighted somethings as well (though the README issues probably keep the file self consistent, so if you wanted to fix them, please do it in a standalone PR. |
Yes, that's a bit confusing. There's no intent, but it is possible and there seems no reason to restrict it. I have renamed to a .cnf_template suffix and included the user so that all mysql options arrive through that route. And expanded the comments in config.ini. |
After discussion:
|
With optional .zip file inflation.
Closing for now as I'll be force pushing some intermediate/incomplete/untested updates. |
Draft request at this stage as preview hoping for comments, on style and substance, and expecting more integration work to be needed.
Closes #7 #5 (for MariaDB only)
But does not yet address #6