MySQL Bugs: #50272: mysqldump returns with return code 0 on crashed tables

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:	None
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

Description:
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

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.

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.

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?

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.

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:

----<q>----
string system  ( string $command  [, int &$return_var  ] )

 Parameters

command

    The command that will be executed.
return_var

    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.
----</q>-----

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.

Ah! Thats Perl. Please ignore my last comment.

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 $?
3

$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
768

As you see in my environment I get positive error numbers in both cases

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?

Thanks.

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.

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 :)

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.