We had a weird problem when moving a WordPress website for a customer: after DUMPing it out of MySQL, we noted that the wp_options table had a problem, namely the table had no primary key and no index on the option_name field. We noted that because the WordPress website, once moved, looked akward and wrong, missing some key pieces and it also seemed to use settings that were old. The reason was that, with primary key missing, lots of duplicate records were stored inside the table and I’m pretty sure it was not what the website was meant to do. Field option_id was set to 0 in most cases when it should have been an auto-incremented integer plus it seemed that the website was not updating settings, rather it was storing a new copy of them each time.

The akward look was probably due to WordPress not being able to load-up the most recent settings but the weird thing was that it was working like a charm on its existing server. However, we noticed that the source server was running MySQL 5.1 while the destination was instead running MySQL 5.7. MySQL is that weird beast where everything can happen but anyway that 5.1 version was really really old. I would expect such things not to happen in an enterprise world (never had such problems with SQL Server) but…

The problem

So the first problem we had to solve was re-enabling primary key for field option_id and its indices but we couldn’t add a primary key on that field since thousands of record were using the same key (zero) so we had to find a way to update them with a unique value. The best solution would be to have consecutive integers though that wouldn’t ensure that we are restoring the right order. But I’m afraid there’s no real way to be sure about that. However, when enumerating records one might assume that the table scan would populate results from the oldest to the newest. Not sure about this but we might try.

So we basically developed a stored procedure that would scan that table and update each record to set a new option_id. One of the key problems with this is that you need to perform only an update at a time because you cannot use any relevant key to uniquely get the record given that option_id is zero. Other fields might be the same for multiple records so for example if we try to select records based on option_name we might have multiple records update with the same option_id and we wouldn’t solve our problems.

We might just hope that we’re lucky enough so that scanning for zero keys and updating just a single record would just update in the same order. Anyway, the key to change the table design is to have different keys, it is not strictly necessary to have the same order though quirks might happen if we don’t do that. The real important thing is to ensure we won’t [...]

Windows Azure Pack is a great technology but sometimes Microsoft seems to be missing the complexity of providing services to hundreds if not thousands of customers, each of them with different needs. Standardization is good but it should provide enough flexibility to manage things in a reasonable way. So here’s the scenario: you deployed WAP and your customer starts to buzz into your server because how good WAP actually is. Rock solid, able to run most demanding websites. Great technology, I said.

However, one of your customers runs over his allotted quota of one of the seventeen metrics you can monitor for your websites. Since your customer didn’t opt for a pay-per-use billing model, you just suspend his website, like any hoster in the world would do, and your customer calls in to buy more “of that something”. He pays (if needed), if you’re like us he gets an add-on to increase his quota over a standardized plan and, after a while and a little synchying, WAP states that his account is now back in quota. End of story.

Well, almost! Because your customer calls in again stating that his website is still suspended while on his portal he sees no over-quota warnings and you realized that he is right: no warnings, increased quota but website still suspended. Hmmm…

From now on, you start a journey to understand why WAP didn’t re-enable that website. You try to update plans, subscriptions, add-ons, force subscription resynchying, force plans to update, open-up Powershell to look for a well-hidden parameter that will allow you tell WAP to re-evaluate quota and re-enable website, or (at least) a cmdlet to tell WAP to re-enable that #&%$@#!$ website because I’m the one who rules here. Apparently, you discover that there isn’t anything like that: no way to re-enable a website that is over quota. So you basically look at portal where it states that counters will be reset in 29 days and you start thinking if WAP really wants to re-evaluate quota in 29 days from today. You wait in the hope that it will take a little time to start that website again but no luck. After hours, you really start to think that WAP will keep that website suspended until it will be time to reset counters, which is obviously totally unacceptable. But the most scary thing is that you cannot force it to change his mind. You’re basically powerless.

After a little checking, it turns out what I stated is not true for all quota items. For example, a short while after upgrading (by adding an add-on) sent bytes quota, a suspended website has been restarted by WAP itself. However, there are other counters that seem to be evaluated only when their configured period will expire, for example CPU burst and received bytes. No matter how long you wait after changing those, WAP won’t restart the affected website. I’m talking about hours here, not minutes, but I couldn’t wait days to check if it would happen after 29 days as suspected. [...]