MySQL Bugs: #25531: MySQL crashes very soon after starting slave

Bug #25531	MySQL crashes very soon after starting slave
Submitted:	10 Jan 2007 18:53	Modified:	3 Apr 2008 0:18
Reporter:	Baron Schwartz (Basic Quality Contributor)	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server	Severity:	S2 (Serious)
Version:	5.0.26-standard-log	OS:	Linux (Gentoo)
Assigned to:		CPU Architecture:	Any
Tags:	qc

Description:
I have been having persistent trouble with replication hard-crashing the slave.  If the slave thread starts and runs successfully for a few days, it is likely to continue running for many weeks without interruption.  However, in many cases starting the slave causes a crash soon thereafter.

This bug is essentially non-repeatable.  However, the crash I'm reporting here was caused by shutting down a slave to take a backup, then bringing it back up; after a few minutes, I issued STOP SLAVE, then a minute later START SLAVE and it crashed.  At the point I stopped the slave, there were 7 slave temp tables open.

The stack trace I'll attach is for the MySQL-supplied binary.  If you need more information, I can attach it privately.

How to repeat:
I have not been able to reliably repeat this bug.  However, it happens often enough that it's a serious problem.

Contents of MySQL Error Log

Attachment: mysqld-err.txt (text/plain), 3.21 KiB.

Resolved stack trace of the crash.

Attachment: resolved-stack-trace.txt (text/plain), 1.09 KiB.

Thank you for the report.

Please verify if your case is same as bug #22504 (check sql_mode) and inform us about results

(John on behalf of Baron)

That does not appear to be the same bug.  There is space between the INTO and TABLE in our log.  Also ours resulted in a hard crash of the slave rather than simply a syntax error causing the slave thread to stop.

Thanks.

Please try using current 5.0.33 server accessible from http://dev.mysql.com/downloads/mysql/5.0.html (if you want to use binary packages, wait when binaries for your platform will be accessible from the mirror sites)

There are no official MySQL-supplied binaries available for 5.0.33 (and we have also heard about some InnoDB bugs that would cause us problems).  We switched to the officially supplied binaries specifically so we could eliminate our compiler as the source of the problem, because submitting a bug report against something we built ourself makes it harder for you to find the problem.  This problem has been happening since 5.0.0x, it is not new, but we only recently switched to official binaries.

Should we return to compiling the server ourself (Gentoo) or wait until there is an official binary for the community edition?

Sorry for delay: I was out of computer.

Please, compile from sources.

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".

I can't duplicate this bug reliably.  In fact I have recently gotten replication running more smoothly, and so I rarely stop/start slaves anymore.

Thank you for the feedback.

You can't duplicate problem with new version?

By "I can't duplicate" I mean I haven't seen it happen.  This is with Gentoo's latest source, but I can't duplicate it reliably with the old MySQL binary version either.  It only happened occasionally, but when it did happen, it seemed to be caused by issuing STOP SLAVE and then START SLAVE again.  I don't have a machine I want to repeatedly do that to, just to try to make it crash :-)

Did you have experienced the behavior reported since your last comment?.
Thanks in advance.

No, I was not able to repeat this anymore.

Thank you for the feedback. I am closing this bug according your last
comment.