gracefully upgrading a website

Question

Is there a preferred method of gracefully upgrading a web site? I have a completely new code base ready to go on a site, but updating it will take several hours. I don't want the site to be down the entire time with a "Upgrading, be back soon!" message, but neither can I leave the current site up while the new one is put in place.

The only way I can think of that might allow for a graceful upgrade is through the use of two servers, but this would get more expensive.

Answer 1

Several hours is much, if there is a lot of converting in the database you can first take a copy of the database, finish converting, set up the new site (but with a slightly old db), look on what have changed since you took the copy, convert that too (should be faster than the big dump if you don't have a lot of changes) and insert it into the new database.

Just don't forget to backup!

Answer 2

There's a number of tactics you can use - depending upon the time/resources you're willing to commit to the upgrade.

It might be possible, depending upon how you're performing your migration, to do this with absolutely zero down-time.

The more complex your application/site, the more complex the migration strategy may be if you want no downtime.

We've achieved zero down-time migrations by:

1. Setting up new server(s) with the new version of the site and database.
   • Altering the load-balancer to split traffic into two pools new-app, and old-app.
   • Configure load balancers begin sending traffic to the new-app server(s), but keep existing sessions on the old-app server(s)
   • New sessions on new-app check to see whether the customer-data has been migrated, and if not - quickly does that.
   • Progressively shutting down "old-app" servers as load falls off, upgrading to the new-app, and adding to the new-app load balancer pool.
   • As sessions end, the customer data is migrated to the new database.
   • As load permits, migrate inactive customer data to the new database.

Of course, this is more complex - as we needed to maintain access to customer data in two environments and progressively migrate.

It does permit us though to roll-back changes should some issue be noticed - eg excessive CPU or Memory usage on one of the new-app servers.

For a smaller site where you don't have the budget for additional servers, you may be able to achieve this by simply using multiple IP Addresses, or some form of internal load-balancing software to route requests to the old, or new site. This can complicate matters more.

If you're not able to run the old app, and new app off the same data store (backend webservices, database, etc) - then your apps would need to be aware that they would need to sync data between old/new - eg during save/update of customer-data, the write would need to occur in both locations.

Answer 3

Planning to "gracefully upgrade your website" doesn't start when you're ready to deploy. It starts very early in the design of your application. That means you have to build an application that can be upgraded gracefully, and also having the infrastructure in place to support that upgrade.

You have provided few details and are asking a vague, but important question from random people on the internet. This leads me to believe that "upgrading gracefully" was a last minute concern (like 23 minute ago).

Your question, "Is there a preferred method of gracefully upgrading a web site?" can only be answered as, "Yes, but I do it way differently than you do."

Answer 4

If it's only the database you are upgrading, just make a new one and switch back as soon as it's ready. If you are talking about uploading the code, upload it to another directory and mv it when it's ready. It's shouldn't be a problem if you have a similar setup on your development environment.

You can also rent a very cheap server like those at 20euro/month (kimsufi or something) and do your upgrade.

Answer 5

This is probably something you needed to have already "designed in" to the current release.

Can it be segmented so that some parts (eg. catalogue) are available, but others (eg. purchasing) are being upgraded?

Can a read-only version be created using a cache?

Or, surely there are times of day when a service outage is acceptable? Work a Sunday evening? Even quite major websites have some maintenance windows during which pieces of functionality are unavaiable.

Answer 6

Sounds like you want to have your cake and eat it.

If the upgrade is a manual job that takes several hours, why don't you speed it up by scripting the job.

Answer 7

I think that, whichever way you go with this, it is absolutely necessary to have the full cooperation of your web hosting and domain name provider.

A rough procedure would be to:

1. Rent a new server with a different IP address, which will be where you'll deploy the new site. Or if possible, create a test subdomain within your site that is inaccessible to the public.
2. Deploy your site in the new server/subdomain. Perform all necessary testing with your new site using the IP or your subdomain first.
3. When you're sure everything is okay, issue redirects first to your new server/subdomain.
4. Redirect your DNS to the new IP address, or fix it in such a way that you can make your main domain now point to the original location of the subdomain.

Ideally nobody would even notice that your site was down, or if it has down time, it will only last a few minutes.