Bug #67041 'mysql' folder in datadir becomes empty after upgrade.
Submitted: 1 Oct 2012 22:00 Modified: 2 Apr 2013 7:36
Reporter: Peter Laursen (Basic Quality Contributor) Email Updates:
Status: Can't repeat Impact on me:
None 
Category:MySQL Server: Installing Severity:S1 (Critical)
Version:5.5.28 OS:Any
Assigned to: CPU Architecture:Any

[1 Oct 2012 22:00] Peter Laursen
Description:
I upgraded from 5.5.23 to 5.5.28 using mysql-5.5.28-win32.zip.  I skipped the configuration wizard (what I was surprised to see actually, as it contradicts communcication from MySQL developers stating that the wizard will no longer be bundled with the 'standalone installer').

Server refused to start. Error log:

121001 23:05:20 [Note] Plugin 'FEDERATED' is disabled.
C:\Program Files\MySQL\MySQL Server 5.5\bin\mysqld: Table 'mysql.plugin' doesn't exist
121001 23:05:20 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
121001 23:05:20 InnoDB: The InnoDB memory heap is disabled
121001 23:05:20 InnoDB: Mutexes and rw_locks use Windows interlocked functions
121001 23:05:20 InnoDB: Compressed tables use zlib 1.2.3
121001 23:05:20 InnoDB: Initializing buffer pool, size = 128.0M
121001 23:05:20 InnoDB: Completed initialization of buffer pool
121001 23:05:20  InnoDB: Log file .\ib_logfile0 did not exist: new to be created
InnoDB: Setting log file .\ib_logfile0 size to 5 MB
InnoDB: Database physically writes the file full: wait...
121001 23:05:20  InnoDB: Log file .\ib_logfile1 did not exist: new to be created
InnoDB: Setting log file .\ib_logfile1 size to 5 MB
InnoDB: Database physically writes the file full: wait...
121001 23:05:20 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
121001 23:05:20  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
121001 23:05:21  InnoDB: Waiting for the background threads to start
121001 23:05:22 InnoDB: 1.1.8 started; log sequence number 146429964
121001 23:05:22 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3307
121001 23:05:22 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
121001 23:05:22 [Note] Server socket created on IP: '0.0.0.0'.
121001 23:05:22 [ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.host' doesn't exist

A little research revealed that the /datadir/mysql folder was completely empty after running the installer! before the upgrade teh server worked fine. As a Windows user I could recover its content from last existing 'shadow copy' stored by NTFS file system before the upgrade (folder context menu .. properties .. previous versions)

I am actually surprised that the installer would run at all as per http://bugs.mysql.com/bug.php?id=56889 . But it did this time.  Maybe because that MySQL 5.6 in between has been upgraded to 5.6.7. So in order to reproduce this you should probably have both a pre-5.5.28 5.5 server and 5.6.7 installed.

BTW: after restoring the 'mysql' folder from a NTFS 'shadow copy' I ran mysql_upgrade and bumped into this: http://bugs.mysql.com/bug.php?id=67040

How to repeat:
Please not!

Suggested fix:
Get in control of your installers. PLEASE. They are horrible!
[1 Oct 2012 23:49] MySQL Verification Team
Thank you for the bug report. I need help to try to repeat this bug report, my problem is that I don't had 5.5.23 installed then I download the package and installed it then I did the upgrade with the package 5.2.28 without problems. So I guess some particular condition of the 5.2.23 installation I didn't have on my environment so I can have success to find the bug. Du you have some clue about?. Thanks in advance.
[2 Oct 2012 7:59] Peter Laursen
Well .. not really a clue.

You should know that I have posted bug reports like this and also a few blogs:
http://www.webyog.com/blog/2012/05/10/circus-oraclimus-installatus-upgradimus/
http://www.webyog.com/blog/2012/08/19/mysql-windows-installer-mess/

Also I am not the only one reporting similar bugs even though it seems that it materializes worse on my system than it does for most people affected.

I have been upgrading 5.5 and 5.6 since very early 5.5 and 5.6.0 on this system.  At one occasion I used an early 'unified installer'.  Exactly what triggers this I don't know. It could have started long before 5.23. 

I don't have more data than I can easily dump in a few minutes, so I think I will have to completely remove 5.5 and 5.6 and start a fresh of both.  

But this should never happen.  It is not a big deal to write software that 'works when it works'.  It should also 'work when it does not work' (ie. exit gracefully without damage to the system if something is wrong)
[2 Oct 2012 9:18] Peter Laursen
correction .. I used mysql-5.5.28-winx64.msi (and I had 5.5.23 64 bit installed in advance)
[2 Oct 2012 11:18] Peter Laursen
I have uninstalled 5.5 and 5.6 and deleted *each and everything* from them + did a fresh install of 5.5.28 and 5.6.7 (using mysql-5.5.28-winx64.msi and mysql-5.6.7-rc-winx64.msi 'standalone installers').

Now let us see if I'll face any problems in the future. If I do I will come *furiously* back! :-)

@Miguel .. you may set this to 'Need Feedback' if you think so. Personally I think MySQL supporters and/or Windows team should spend more effort to understand this, but that is your decision.  It may be like searching a needle in a haystack and I cannot contribute any more as I have deleted everything.
[2 Apr 2013 7:36] MySQL Verification Team
was continued in http://bugs.mysql.com/bug.php?id=67959