Question Locked

perl capturing mysqldump error message

0 helpful
3 replies
Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

I have written a short perl script that will read a configuration file to backup the mysql database's using the mysqldump. This perl script acquires it's input from a config file that any user can maintain with userid, password, if its a daily/weekly/monthly/annual backup, the directory the backup .sql file should be placed in. Stuff like that.

The reason for this script is so that backup sql files can be created with date/time stamps and will roll off in a generation dataset fashion. Ie: I only want to retain 7 daily backups, 12 monthly backups, and 10 annual backups. The script can perform this based on the data passed by the config file.

Ok, my question. In testing this script I made sure that one of my test's was to include invalid password/userid passed via the config file. mysqldump blew chunks as it should have but it did not pass back the proper error message to the variable as I thought it would.

The error message generated by mysqldump was:mysqldump: ?Got error: 1045: Access denied for user 'crap'@'xxxxxxx.xxxxxxx.com' (using password: YES) when trying to connect? but what it returned to the perl script was 512.

I've tried directing'>' the output to files, nothing is inserted. I've tried the perl functions exec, system, and back ticks to see if anything worked. Nope. Shoot, I even echo'd out the command I built and copied it to a shell script. ran the shell script with the output being directed to a text file to see if perl was just not capturing it. Even the shell script did not place the full error message where I wanted it.

In that this is going to be running from a cron, I would like to capture and properly report any and all errors to a log file for backup verification.

uggg, any suggestions here?

Dan

3 replies

by danlm

Because the perl script builds all the parameters for the mysqldump, to place the full command that was built in the log file with an additional comment to manually execute this to determine exact cause of error.

God, I hate falling back to that but....

Dan

by tony hopkinson

it's a good start.

Think of it this way, it's a robust solution, now matter how they arse about with MySQLDump, you know the login is good.

This discussion is closed to new replies.