A year and a half ago, I wrapped innobackupex in a script to get all of the control I needed to do my nightly backups. At that time, it seems (from memory) that the return code from innobackupex could not be trusted to be accurate and the preferred method was to look for the “innobackupex: completed OK!” string at the end of the log file. Is this still the case?
I’ve got a specific couple of servers that are constantly reporting failure, even though the backup actually completed successfully. I’m debugging my wrapper scripts now to try to find out what’s going on. I figured if it was possible to simplify things and rely on the return code, that would be the best approach.
Thanks,
David
The returned code should be reliable. This is a test with the latest version:
130606 11:40:43 innobackupex: Connection to database server closed
130606 11:40:43 innobackupex: completed OK!
root@vagrant-debian-squeeze-64:/home/vagrant# echo $?
0
I think that the best way to debug this is to log the output of innobackupex to a file and then check it after a failed backup report. You can paste here the log if you need help.
I’m using the latest version of XtraBackup (2.1.3) with MySQL 5.6.11 on CentOS 6.3.
One and a half years ago, I somehow arrived at the following code to determine failure/success of a backup. Perhaps things have improved, and I need to amend my wrapper script.
$returncode = execute(innobackupex command)
if ($returncode !=0)
fail
else {
// essentially, we’re saying we don’t trust a 0 return code, so check the log output just to be sure
check the output of innobackupex log to see if it really said “OK” to see if we really failed or not
}
What I think you’re telling me is that I should flip this scenario now. 0 return code is reliable, and if I get a non-zero, then I should check the log output?
Thanks,
Dave