MySQL Bugs: #38841: Replication error-code %d

Bug #38841	Replication error-code %d
Submitted:	18 Aug 2008 7:57	Modified:	20 Aug 2008 8:52
Reporter:	Witali Pril	Email Updates:
Status:	Won't fix	Impact on me:	None
Category:	MySQL Server: Replication	Severity:	S1 (Critical)
Version:	5.0 bzr	OS:	Linux
Assigned to:	Lars Thalmann	CPU Architecture:	Any

Description:
Description:
Our replication gets often on randomly times out of sync with the
following message. 

Query caused different errors on master and slave. Error on master: 'Got error %d from storage engine' (1030), Error on slave: 'no error' (0). Default database: 'xxx'. Query: 'SAVEPOINT `xxx`'

I would like the option slave-skip-error, but I need to the error-code.
I need an error code or a different solution to the problem Sync.
The sync. is very important for us.

BR,
Witali Pril

How to repeat:
Its occures randomly, so it's not possible to repeat it.

Suggested fix:
The best way would be, that the master didn't throw this error-message.
An other way would be, that the slave don't react on this
error-message.

Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://dev.mysql.com/doc/ and the instructions on
how to report a bug at http://bugs.mysql.com/how-to-report.php

If master produces error and slave does not this is expected behavior and needed to DBA can be sure data is consistent. So I close the report as "Not a Bug".

As workaround I can suggest to create script which will check slave status and restart slave if needed. Probably EVENTs (available since 5.1) can help here.

The bug ist the unknow error-code "%d"!
I need a numeric number.

Restart from the slave does not, as this at the same point stop.

______________________
Peresagruska slave ne4o ne dajot, potomuschto opjat na etom sche mestje sync. ostonawlewajetsja. Mne nomer buga nado dlja "slave-skip-error".

Thank you for the feedback.

Correct: having "%d" instead of error number in the slave error log is problem. But this should be fixed by patch for bug #20159. Please indicate version of MySQL server you use.

Regarding to restarting slave: of course, you should set slave skip_counter to appropriate value before restart.

MYSQL version: 5.0.51a-9-log (Debian)

Bug #38845 was marked as duplicate of this one.

Thank you for the feedback.

Verified as described.

To repeat.

Create test file:

$cat rpl_bug38841.test
--source include/master-slave.inc
--source include/have_innodb.inc

create table t1(f1 int) engine=innodb;

begin;
insert into t1 values(1);
--error 1030
savepoint foo;
insert into t1 values(2);
commit;

select * from t1;

sleep 1;

connection slave;

select * from t1;

--vertical_results
show slave status;

Run: ./mysql-test-run.pl --manual-gdb  --record rpl_bug38841; cat r/rpl_bug38841.result 

In master's gdb do:

(gdb) b ha_innodb.cc:2010
Breakpoint 2 at 0x1aab14: file ha_innodb.cc, line 2010.
(gdb) c
Continuing.
[Switching to process 23410 thread 0x2b03]

Breakpoint 2, innobase_savepoint (thd=0x4863418, savepoint=0x4866c38) at ha_innodb.cc:2011
2011            DBUG_RETURN(convert_error_code_to_mysql(error, NULL));
(gdb) set error=500
(gdb) c
Continuing.

Examine slave status:

Last_Errno      0
Last_Error      Query caused different errors on master and slave. Error on master: 'Got error %d from storage engine' (1030), Error on slave: 'no error' (0). Default database: 'test'. Query: 'savepoint foo'

On master error is correct: 

savepoint foo;
ERROR HY000: Got error -1 from storage engine

MySQL 5.1 does not stop replication in case if error doesn't affect data on master. So bug exists in 5.0 only.

As I understand it, this is already fixed in 5.1.

We will not fix this in 5.0.

mysql-server-5.1 is aktualy unstabil.
When the stable version comes out?

thx