Bug #50272 mysqldump returns with return code 0 on crashed tables
Submitted: 12 Jan 2010 12:51 Modified: 18 Jan 2010 10:10
Reporter: Ronny Forberger Email Updates:
Status: Closed Impact on me:
Category:MySQL Server Severity:S2 (Serious)
Version:mysqldump Ver 10.13 Distrib 5.1.35, for OS:Solaris (5.10 Generic_139556-08 i86pc i386 i86pc)
Assigned to: Sveta Smirnova CPU Architecture:Any
Tags: mysqldump return code

[12 Jan 2010 12:51] Ronny Forberger
The mysqldump command seems not to exit with an exit code != 0 when it cannot dump a database due to crashed tables.

mysqldump: Got error: 144: Table './XXXXXXXXXXXX/YYYYYYYYYY' is marked as
crashed and last (automatic?) repair failed when using LOCK TABLES

We are faced up to the problem, that our MySQL Backup tool mysql-zrm does not fail jobs when mysqldump does not fail.

Also see: http://forums.zmanda.com/bugzilla/show_bug.cgi?id=74

How to repeat:
Dump a table that is marked crashed

Suggested fix:
Investigate / Change return codes in case of crashed tables
[12 Jan 2010 20:52] Sveta Smirnova
Thank you for the report.

I can not repeat described behavior: mysqldump fails with error 3, not 0.

Please provide options you use when invoke mysqldump.
[13 Jan 2010 9:40] Ronny Forberger
Did you really simulate a crashed table error?

Here are the command line, mysql-zrm invokes mysqldump with:

myhost:~# pargs 8680
argv[0]: mysqldump
argv[1]: --opt
argv[2]: --extended-insert
argv[3]: --create-options
argv[4]: --default-character-set=utf8
argv[5]: --single-transaction
argv[6]: -v
argv[7]: --user=x
argv[8]: --password=y
argv[9]: --host=foobar
argv[10]: --port=3306
argv[11]: --databases
argv[12]: DB1
argv[13]: DB2

Thanks for the help.
[13 Jan 2010 10:03] Sveta Smirnova
Thank you for the feedback.

I still see error 3. You wrote you use mysql-zrm to invoke mysqldump. How do you check return error?
[13 Jan 2010 10:14] Ronny Forberger
According to an enquiry to the mysql-zrm bug tracking system, mysql-zrm would fail if mysqldump returns with != 0.

Since it didn't on my instance by only showing the error about crashed tables, I highly suggest it being a problem there.
[13 Jan 2010 13:21] Sveta Smirnova
Thank you for the feedback.

mysql-zrm-backup calls mysqldump in following code:

1421     my $p = &addMySQLParams($MYSQLDUMP);
1447     my $r = system($p.$command);
1454     if( $r > 0 ) {
1455         &printAndDie("mysqldump did not succeed.\n Command used is ".$p.$command);
1456     }

But PHP manual describes usage of function system at http://www.php.net/manual/en/function.system.php in different way:

string system  ( string $command  [, int &$return_var  ] )



    The command that will be executed.

    If the return_var argument is present, then the return status of the executed command will be written to this variable.

Report a bug
Return Values

Returns the last line of the command output on success, and FALSE on failure.

So you can see mysql-zrm-backup  doesn't check &$return_var, but used return value of this function instead. In PHP FALSE ==0, so it never fails.

Please report bug in Zmanda bug tracker.
[13 Jan 2010 13:25] Sveta Smirnova
Ah! Thats Perl. Please ignore my last comment.
[13 Jan 2010 13:57] Sveta Smirnova
I still can not repeat described behavior.

Please check without Zmanda what mysqldump returns in your environment. Use both Perl and just command line like in example below:

$./build/mysql-5.1/bin/mysqldump -S ./src/mysql-5.1/mysql-test/var/tmp/mysqld.1.sock -uroot  test >/dev/null
mysqldump: Error 1194: Table 't1' is marked as crashed and should be repaired when dumping table `t1` at row: 0

$echo $?

$perl -e 'printf system("./build/mysql-5.1/bin/mysqldump -S ./src/mysql-5.1/mysql-test/var/tmp/mysqld.1.sock -uroot  test >/dev/null");'
mysqldump: Error 1194: Table 't1' is marked as crashed and should be repaired when dumping table `t1` at row: 0

As you see in my environment I get positive error numbers in both cases
[13 Jan 2010 14:00] Ronny Forberger
Thank you for your investigations. Yes it's perl. Indeed I already reported a bug in mysql-zrm. 

See: http://forums.zmanda.com/bugzilla/show_bug.cgi?id=74

In the mind of mysql-zrm it is a bug of mysqldump, which does not return != 0 in that case.

I could simulation that in my environment, just couldn't make a database fail that way. How did you make a table crashed by intention?

[13 Jan 2010 14:05] Sveta Smirnova
I used test case for our MTR test suite:

create table t1(f1 text);
insert into t1 values('fdsfdsfdsfdsfdsfdsasd');
insert into t1 select * from t1;
insert into t1 select * from t1;
insert into t1 select * from t1;
insert into t1 select * from t1;
insert into t1 select * from t1;
insert into t1 select * from t1;
insert into t1 select * from t1;
insert into t1 select * from t1;
flush tables;

--let $MYSQLD_DATADIR=`select @@datadir`
--exec echo "foobar" >$MYSQLD_DATADIR/test/t1.MYD

sleep 1000;

And when it sleeps I connected to the server using mysqldump.

You can just create dummy MyISAM table, write several rows in it, then rewrite MYD file with some random data.
[15 Jan 2010 10:15] Ronny Forberger
Thank you for the guide.

I have tested this in my environment now, return code is 3, so indeed you are right.

Thanks for the approval :)
[18 Jan 2010 10:10] Ronny Forberger
FYI: The problem was indeed not caused by mysqldump, rather than by mysql-zrm, which had a on the fly compression of the dump turned on.

mysqldump ... | bzip2 ...

mysql-zrm looked at the return code of bzip2.

Thanks for the help again.