MySQL Bugs: #67355: mysql crashes and restarts all the time (with diff. versions, diff. hardware)

Bug #67355	mysql crashes and restarts all the time (with diff. versions, diff. hardware)
Submitted:	24 Oct 2012 10:24	Modified:	29 Nov 2012 20:13
Reporter:	Alexander Lhner	Email Updates:
Status:	Can't repeat	Impact on me:	None
Category:	MySQL Server: Replication	Severity:	S2 (Serious)
Version:	5.5.19, 5.5.25, 5.5.27, 5.5.27a, 5.5.28	OS:	Linux (Debian Squeeze (6.0.x))
Assigned to:		CPU Architecture:	Any
Tags:	crash, Debian, replication, restart

Description:
We have serious problems with different mysql versions greater than 5.5.15 (<= 5.5.15 is running stable) on many different servers with different hardware.

Tested and reproduced was this behaviour with the versions 5.5.19, 5.5.25, 5.5.27, 5.5.27a and 5.5.28.

How to repeat:
 - We are installing mysql community server.
 - Then we are importing our backups from the master server
 - Then we are starting the replication slave on the server in question
 - Then we are waiting until the replication is uptodate.
 - Then suddenly, while the slave tries to become uptodate, the mysql server starts to crash and to restart again all the time without any end.

We have tested this on many different servers and with many different mysql versions. The last server where we have tested this got version 5.5.28 installed.

relevant part of error log

Attachment: error_log.txt (text/plain), 20.32 KiB.

my.cnf file

Attachment: my.cnf.txt (text/plain), 3.08 KiB.

Hard- and software of the server in question

Attachment: hardware.txt (text/plain), 86.23 KiB.

Hi Alexander, Can you do a test on one slave?  

1. Totally disable query cache.
2  Remove all the replicate_wild_ignore_table rules from my.cnf 

If the above actions stop the crashing I have a good idea what the problem is...

Hello Shane,

I've now installed 5.5.28 on the same server shown in the hardware details above. Then I've deactivated the query cache and the replicate_wild_ignore_table rules.

Then I've imported the full backup (about 15 GB) and started the slave process. After about 2 hours the replication was uptodate and now this slave is in our production environment integrated (we have a software SQL loadbalancer that automatically deactivates this slave if it crashes again).

Until now (after about 2 hours since it is integerated in the live environment), it runs stable.

But I still can not say if this server will now stay stable. Unfortunatly these crashes appeared very random. Sometimes they started already right after importing the backup and starting the slave, sometimes it runs for some hours until it then starts to crash repeatly.

So, lets wait until Monday... then I'll report back if it is still stable.

Maybe you can already tell me, what the problem is or what you think what the problem could be?

Thanks in advance!

Sincerely yours
Alex

Hello Shane,

okay, until now (Monday morning) this server runs stable.
The replication gives us many errors (dublicate errors), because we need these replicate_wild_ignore_table rules, but without this and without the query cache, the server runs stable until  now.

So, maybe you want tell us, what you think what the problem is? *g*

Sincerely yours
Alex

There is an upcoming bugfix for 5.5.29, (which is already fixed in 5.6.7!).
I think it's this bug:

"Replication: Updates writing user variables whose values were never set on a slave while using --replicate-ignore-table could cause the slave to fail. (Bug #14597605)

References: This bug was introduced by Bug #14275000."

Okay, great. Thanks for your help!
We'll then wait for the 5.5.29.

Alex

Thank you for the feedback.

Closing as "Can't repeat" since bug is not repeatable anymore. If you hit this again feel free to reopen the report.