Bug #74553 Crash when starting MySQL 5.6.21, using data from 5.6.20
Submitted: 24 Oct 2014 16:48 Modified: 10 Feb 2015 12:19
Reporter: Saverio Miroddi Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server Severity:S1 (Critical)
Version:5.6.21 OS:Linux
Assigned to: CPU Architecture:Any

[24 Oct 2014 16:48] Saverio Miroddi
Description:
I have a slave machine (Ubuntu 14.04), which has a 5.6.20 install (tarball), running.
On the same machine, there is a 5.6.21 installed, sharing the same configuration and data, but not running - essentially, a setup ready for migrating version.

When I stop the old version (service mysql.server stop), replace the symlink, and start the new (service mysql.server start), the server start, but never gets to a fully started state, filling the log with crashing logs, without stopping (I stopped after a few minutes).

If I go back to the old version, there is one log replay, then the server fully starts.

I've tried several time the procedure old -> new -> old -> new..., but the same problem always happens.

How to repeat:
See the description.
[24 Oct 2014 17:26] Valeriy Kravchuk
Would you mind to share a stack trace for one of these crashes?
[24 Oct 2014 17:29] Saverio Miroddi
When I start (service mysql.server start), I don't see anything in the terminal - the crash information is found in the error log (a sample is attached).
[24 Oct 2014 18:33] MySQL Verification Team
Thank you for the bug report. You wrote:

"On the same machine, there is a 5.6.21 installed, sharing the same configuration and data..."

Both server has the same datadir?

Thanks.
[24 Oct 2014 18:47] MySQL Verification Team
Guessing we need to watch:
 Bug 19724470 - CRASH WHEN RECEIVE OLD-STYLE ROW EVENTS FROM TIMESTAMP COLUMNS 
 Bug 19704825 - TEMPORARY SLAVE TYPE CONVERSION TABLES RELEASED TO EARLY 

My suspicion is the fix for this introduced a regression:
Bug 18770469 - OUT OF MEMORY ON 5.6 SLAVE USING RBR WITH DATETIME WHEN TABLE CREATED IN 5.5.
[26 Oct 2014 20:38] Saverio Miroddi
Yes, but they never run at the same time. The data has been long used, without any problem, byt the 5.6.20, and the procedure mentioned has been an attempt to update.
[29 Oct 2014 15:22] Saverio Miroddi
I confirm that it has nothing to do with the interaction between the existing data and the new version.

This is the procedure I've performed:
- Stopped MySQL
- Removed all the data, including the system tables
- Executed mysql_install_db, from 5.6.21
- Started 5.6.21
- Things are ok until here
- Restored a dump taken on the master, with --master-data=1
- Executed START SLAVE

Now I get the usual problem.
After this, I restore a dump (originally done from the master with --master-data=1),
[10 Feb 2015 11:23] MySQL Verification Team
Please try version 5.6.23. Thanks.
[10 Feb 2015 11:55] Saverio Miroddi
I've upgraded to mysql 5.6.23 (on the slave), and the service now starts without any error.
[10 Feb 2015 12:14] MySQL Verification Team
Thank you for the feedback. So it can be considered solved?. Thanks.
[10 Feb 2015 12:17] Saverio Miroddi
Yes, since the the behavior was fail-fast and the slave started correctly, I can consider it fixed.
[10 Feb 2015 12:19] MySQL Verification Team
Thank you for the feedback.