Fixing MySQL Error 1067 on Windows Server 2008 r2

Let me just start by saying that this has been really annoying me for some time now and obviously taking the server offline to fix this is difficult at the best of times.  Fortunately, this week I've had the time to take a look at this and see if I can sort the issue.

From looking at all of the various 'solutions' out there, it doesn't actually seem that any of them are correct.  Don't get me wrong, I'm sure there is one somewhere but I didn't manage to find it past page two of Google so I thought I would give it a go myself.  Just to save you some time, the following doesn't work despite what a lot of people will have you believe (and if they do, then you have been lucky):

• Removing the service and reinstalling;
• Removing and recreating the log files;
• Repairing the install;
• Recreating your MySQL instance;

Now the reason that it happened on my server was due to an upgrade from MySQL 5.1.x to 5.5.x a few months ago.  I thought that I had done the usual routine correctly of taking backups, downing the service, uninstalling, reinstalling and then restoring.  Job done I thought.  This has never been a problem on any other server that I've done this and so I wasn't expecting this.  All it meant was that from time to time, the service wouldn't start after a Windows reboot.  Not really a big deal but any down time at all is a big no no.

So, in essence you will actually need to do most of your preparation that you would normally do for an upgrade.  You might as well download the latest version of MySQL while you do this so firstly go and grab that.  Next, do your normal backup of your databases and also your my.ini from wherever you normally keep it.  Stop your MySQL service and then uninstall your MySQL installation.  Go to your ProgramData folder and remove your MySQL folder, and do the same in your Program Files\MySQL folder (remove your server folder just in case you have your tools or workbench installed in there).  Now go to your Users folder and have a look through there and it will normally be hidden in your Default\AppData folder.  Launch regedit and search for 'mysql' and remove any instance of it that is related to your server install.  Restart your server now.

When your server comes back on, run your nice new installer, giving it the same settings that you had before.  Set a new instance up (it can be the same service name if you like) and then it will go off and set your my.ini, your service and your security settings.  Your service should now be running straight away.  Just to check it though, stop the service and start it again.  You should find that it's running without erroring.  If it does error, not to worry, open a command prompt and browse to your bin folder inside your new installation and run the following:

mysqld -remove MySQL

Where MySQL is the name of your service that you specified.  Assuming that you have typed that in correctly it will say that it has removed the MySQL service.  Now run the instance configuration wizard again (inside your bin folder) and go through it again.

Lastly, restore your databases and users / permissions and you should be done.  Sorry that this is a bit lengthy but this worked for me and every other solution that I found didn't sort my problem.  It seems that this error goes way, way back to MySQL 4.x but nobody has worked out a way to fix this properly.  As I mentioned before, other people have posted their solutions which may have worked for them, but that could mean that this is an inconsistent error which is why it hasn't been fixed as of yet.

PHP: mysql_fetch_assoc Vs. mysql_fetch_array

Recently I've been doing a lot of work to optimise my work so that pages load more quickly and server load is reduced.  When I was looking through to my database calls, typically I've always used the mysql_fetch_assoc function because it always returned less data than the mysql_fetch array which actually returns two arrays - one which has a numeric index and the other which has an associative key index.
Having a play around and doing some benchmarking between 1,000 and 10,000 iterations of a fairly small amount of data, I found that the mysql_fetch_assoc function was between 24% and 31% faster than the mysql_fetch_array function.  Good news for me really as this is how I typically return data from my MySQL database and so I won't be doing any rewriting any time soon.  This is what I expected really as the size of the data processed and returned is half (well less than that really because it's numeric) so good news here.

Of course there are occasions when the mysql_fetch_array function is needed and I'm not questioning its existence at all, but purely as a benchmarking exercise I would pick mysql_fetch_assoc everyday.

As a side note, it's also important that I mention the mysql_fetch_object function as well which is for those of you who prefer the OO notation.  However, using the same benchmark against the mysql_fetch_assoc function, this is still on average between 8% and 14% slower.

I hope this helps anybody who is currently in the process of performance tuning.  Every little bit saved does help to improve the user experience.

Moving on, onwards and upwards!

Following on where I left off really from my last post!

I briefly mentioned in my last post that I had an upgrade path in place (after testing of course!) for 'Connect'.  The time was approaching to move on with the technology, whereby Connect had been in place for three years and in that time it had only ever had a couple of PHP / MySQL point release updates.  Not that this was a problem of course, but you can never be left standing still.

Anyway, after doing a bit of research and some testing on my machine at work I ended up drawing up a plan for the migration.  Not only would I be migrating the software from the old server to a new one, I would be taking advantage of certain in-house server developments.  Our new server cluster which runs Microsoft Hyper-V, has now been patched to SP1 by Microsoft to support dynamic memory - which means lots of nice resources for any server sitting within that cluster.  Not only this, I drew up plans to upgrade the core functionality of Moodle to version 1.9.10, as well as move to 64-bit MySQL and also move to the latest PHP 5.2.x release (I don't particularly like running Fast CGI on IIS as it has odd behaviour issues sometimes, which left me with ISAPI).

Testing of all of this was done successfully, very successfully!  With nearly everything running in native 64-bit mode on the server (except PHP), the performance boost was clear to be seen.  Pages instantly loaded quicker, reports were much faster to be dynamically generated and most of all, there would be peace of mind that it should, (famous last words!) be a lot more reliable and ready for the future.

To get started with the migration, one of our library server images of Server 2008 r2 was set up, and immediately patched with the freshly released Service Pack 1 from Microsoft.  MySQL, PHP and IIS were also set up, before copying the code across, setting security permissions and restoring the database from the old server.  The Moodle upgrade and module upgrades then took place, whilst downing the old server to ensure that there would only be one database in use.

And that was it really, how to migrate your Moodle!  Downtime was minimal, and first impressions are that everything seems very fast which I think in part is a little to do with everything.  The contributing factors in my opinion are:

• (The obvious) Much more powerful server, with lots of resources
• Move to 64-bit MySQL
• New PHP release
• Newer Moodle release
• Move to Microsoft Server 2008 r2 SP1

I'll be adding more posts soon, so please follow this blog if it will help you in your day to day duties!