MySQL Bugs: #15481: misleading SET ONE_SHOT in SHOW SLAVE STATUS last

Bug #15481	misleading SET ONE_SHOT in SHOW SLAVE STATUS last_error
Submitted:	5 Dec 2005 10:13	Modified:	12 Jan 2006 7:53
Reporter:	Anders Henke	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Server	Severity:	S3 (Non-critical)
Version:	4.1.10 and 4.1.13	OS:	Linux (Linux)
Assigned to:		CPU Architecture:	Any

Description:
I operate a replication setup with a 4.1.10 master and a 4.1.13 slave; replication breaks seldomly, but the SHOW SLAVE STATUS doesn't give out the likely reason, but a misleading message:

Last_Errno: 1053
Last_Error: Query partially completed on the master (error
on master: 1053) and was aborted. There is a chance that your master is
inconsistent at this point. If you are sure that your master is ok, run this query
manually on the slave and then restart the slave with SET GLOBAL
SQL_SLAVE_SKIP_COUNTER=1; START SLAVE; . Query: 'SET ONE_SHOT
CHARACTER_SET_CLIENT=8,COLLATION_CONNECTIO
N=8,COLLATION_DATABASE=31,COLLATION_SERVER=31'

SET ONE_SHOT does affect only for the following SQL command, so the more interesting
query which likely has failed is just the following binlog entry. I also doubt that a SET command can really "partitially complete" and guess that the query following that ONE_SHOT-statement really did fail on the master.

In that specific replication setup, it's likely that quite a complex query runs quite often and this query might fail; however, that query only affects a temporary table which shouldn't be replicated ... so I'm quite puzzled.

How to repeat:
Hard.

I'd like to add the affected binlog entries, however, the binlog has just been rotated into the binary bit bucket. As far as I remember, this problem occured two times so far (over a few months), so it's not that easy to reproduce.

Suggested fix:
Please check wether there are possibilities for a SET ONE_SHOT to partitially complete and close this bug as invalid if there are such ones.

Thank you for a problem report. Can you, please, try to identify a set of steps to repeat that mileading message each and every time? Can you try to upgrade to a newer version (4.1.15)?

I'm very sorry, but as already mentioned the problem doesn't occur on a regular basis and
especially the 4.1.10-based server cannot be easily upgraded (as that specific
server has to be 100% available).

Please, keep and eye on your master and save the binlog next time when something similar will happen. We really need more info to analyze this problem. Is there anything unusual in the master's error log for this period?

The master is running flawlessly and there were no unusual events in the error log for
at weeks, also not for the mentioned period.

The bug rarely occurs, so we might as well close this bug for now and I'll open a new bug once it re-occurs and I have the binlogs ready.

Let's better keep the report in a "Need Feedback" state until you'll be able to get the appropriate binlog.

It will be closed automatically after 1 month of no feedback.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".