Tag Archives: Maintenance

Update on Downtime / F.A.Q

This blog post will serve as a update on the downtime as of 16/04/2014 and an F.A.Q on this and other general downtime and related issues.

The Downtime

So initially, sites were down due to high load on the web server, which causes 503 errors that you see. Earlier that day, it turns out that our Varnish caching software had crashed resulting in about 10 hours of downtime overnight. The downtime you are now seeing is different. Due to problems at our host/datacentre, it appears the hardware that the database server on began having problems, and our host migrated the server to a new “node” without shutting down the server. There appears to have been complications with this that resulted in a sizeable amount of data loss and some database corruptions that were very unlikely and unpredicted when we initially went down.

Our Data Is Gone?

That title is what I assumed might be going through your heads as you read the last section. The answer isn’t a simple yes or no. Our host has a backup from about 12 hours prior to the migration of the node which was during the Varnish crash we believe. In addition to that, the current version of our database server is accessible and has some wikis we should be able to export. It is very important you read the following section thoroughly before clicking the link.

We have logs of all actions that we use to fight vandalism and spam. Using these, we’ve mostly determined the potential loss of data. These “loggable actions” are not all edits. They include things from deletions and protections, to upload and patrol logs. (note: files are not stored on the same server, and are unaffected, they will lose their relevant File/Image namespace page)

Link to list of affected wikis

The Plan

So this part of the post isn’t confirmed, we’re still waiting on a reply from our host but we needed to let you guys know the situation and calm the panic.

As it stands, our host have offered to put up a second instance of our database server running from the backup they took. What we then intend to do is extract as many of the affected wiki’s databases that are not corrupt from the primary instance and import them into the backed up server. This should mitigate as much of the loss as possible.


When will this be done?

We can’t give an E.T.A at the moment as we have to wait for host to confirm the plans and get things set up. The database server back up is a large file and will take time to transfer. Have you ever performed an action on your computer and the estimated time keeps changing? This is why we can’t tell you for certain, but we’ll be working as hard as we can to get the wikis back up as soon as possible.

Is this the same reason you don’t tell us about other downtimes?

Partially. There are always different factors in each type of errors and sometimes its to do with external factors.

Am I affected?

Unless you contributed to any of the wikis listed after 3AM EDT on Monday the 14th of April, it is very unlikely. However preference changes are not logged so if you changed a setting you may have lost that.

So I should backup my own wiki then/Turn back on DumpsOnDemand?

No. It is very very rare we see data loss and the reason we’ve disabled the features as they are a key cause of the 503 memory issues. It puts high load on the server which ultimately results in downtime. It is understandable for you to see this as the perfect excuse to cry for DumpsOnDemand but it causes downtime, and we get into a vicious cycle of people panicking and backing up their wikis, stopping the service for everyone else.

Why don’t you just buy more servers?

Simple answer, we can’t afford to. We have a former staff member who controls a handful of our servers on his personal account as he gets better deals than our current staff and we can provide the most quality for the little money we have.

Scheduled Maintenance Window

As mentioned in our previous blog post, we’ve had to plan a maintenance window. Here are the details:



The window will be the entire of the weekend of the 5th/6th of October, however it could well be done early. Keep an eye out on our Facebook and Twitter, as well as this post which we’ll be updating throughout the weekend.


We’ve had excessive loads on the server, causing pages to not be returned to users. This has caused much upset, and we’ve had to disable various features to try and improve this in the short term. We’re now going to implementing our long term fixes.


The maintenance window will mean sites go into read-only mode while we transfer the necessary data across servers, and configure the new server. We’re hoping that all sites will still be readable during this period, as we’ll be serving read-only data from the old server until the new one is configured and ready. When this is done, we’ll switch be switching the IP address assignments and you’ll then get data from the new server.

The server we are replacing is the server that stores our production MediaWiki code base, and stores the images. All wiki edits and pages are stored on a separate server which is unaffected and will run as usual, so you will not lose any of your hard work. Images will be backed up and transferred across.

If you have any questions, please leave a comment! Again, we thank you for your continued patience.


09:25 UTC Sat 5th – Maintenance has started. Image uploads and deletions have been turned off temporarily while the maintenance is completed. Wiki creation has also been suspended temporarily.
17:15 UTC Sun 13th – New server in production usage. Maintenance restrictions still in place while the new server is load tested. Thumbnails must be regenerated.
17:00 UTC Mon 14th – Issue with images with UTF-8 characters in their names resolved. These will now thumbnail correctly.
22:18 UTC Mon 14th – Subdomains now redirect to the the correct Main Page (fixes for non-English wikis or wikis with custom main page names.)
20:37 UTC Tue 15th – Wiki creation, image uploads and image deletion re-enabled, marking the end of the maintenance period.

On behalf of the ShoutWiki team,

— Lewis Cawte
Chief Technical Officer, ShoutWiki.