Bug #38487 Error on master: 'Got error %d from storage engine' (1030), Error on slave: 'no
Submitted: 31 Jul 2008 12:05 Modified: 4 Aug 2008 11:19
Reporter: Hendrik Bulick Email Updates:
Status: Not a Bug Impact on me:
None 
Category:MySQL Server: InnoDB storage engine Severity:S2 (Serious)
Version:5.0.51a-9-log (Debian) OS:Linux
Assigned to: CPU Architecture:Any

[31 Jul 2008 12:05] Hendrik Bulick 
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 `XXXX`'" 

All I have found is the the error-message on the master occures randomly on using saveponts with a lot of write-operations. And this is not a realy error-message, because all datas are correctly writen. 

If you are using a single server, this error-message can be ignored, but in the replication this error causes the replication to get out of sync.

Booth server are version 5.0.51a-9-log (Debian) on a 64bit-Debian. The queries on the master are executed by the Connector/J from a self written Java-application.

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.
[31 Jul 2008 12:09] Susanne Ebrecht 
Many thanks for writing a bug report.

Which storage engine do you use? InnoDB, NDB or BDB?
[31 Jul 2008 13:11] Hendrik Bulick 
We use the InnoDB-Storage-Engine.
[31 Jul 2008 13:38] Susanne Ebrecht 
Many thanks for writing a bug report.

I can't repeat this ... but you already wrote that it is randomly...

We have to ask development here, if there is a known bug or if they have an idea why this happens.
[31 Jul 2008 19:49] Sveta Smirnova 
Thank you for the report.

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 you can use option slave-skip-errors
[4 Aug 2008 11:19] Hendrik Bulick 
Thanks for the workaround. But the problem with this workaround is, that you have to tell this option an error-code. But which error-code do we have to use. In the error-message only is "%d". But "%d" will not be accepted in the my.cnf.
And we don't want to use "all", because we don't know, wich errors also can 
occur.