Magento upgrading process and infrastructure for smallest possible downtime

Question

I have a client who currently has one server with Magento and his admin takes down whole site for updates for multiple hours. I would like to make it instant process so that I wanted to propose new solution on how he should have set it up:

• Magento Production Server 1 (WEB+DB)
• Magento Production Server 2 (WEB+DB)
• Magento Dev Server 1

DB would have to be synced somehow between those 2 servers (cluster? replication?) and I was thinking that for the smallest downtime possible first the updates should be tested on Dev Server (DB / WEB synced from Production server just before upgrading) and after checking it works fine and knowing how the process looks like I would be disabling LoadBalancing or RoundRobin DNS to only Server 1 then doing upgrades/updates on Server 2 and then Switching to server 2 as production server and updating server 1. When both are done switch on LoadBalancing/Round Robin on.

I come from Windows environment so this is how I would do it on Windows (maybe with seperate Database and Web too) and with tools like RedGate SqlCompare/Sql Data Compare etc it should work.

But I don't know Magento at all so please let me know what's possible and maybe how this should be done if the client don't want to end up with his shop being down...

Answer 1

You'll definitely need a production server, and some sort of staging/version management system. I recommend checking out Subversion or Git for version management. Changes can be committed to a repository first, and then updated to the live site with no downtime. This would be more than sufficient for a development environment.

For bigger changes, like a Magento version upgrade, you might still want/need to take the site down for a few hours in the middle of the night, as this is a much bigger process.

As for multiple servers, as an example I run a load balancer which balances between a primary and a secondary server. There is one database server that is separate. Changes are made to a development server, committed to the primary server with Subversion, and then any changes between the primary and secondary servers are rsynced to the secondary server every 60 seconds.

For this solution, session and cache data are stored in the database.

Answer 2

IMHO, with a good hosting environment, you won't need multiple servers unless you literally are in the thousands of simultaneous visitors. Plugins are the usual cause of admin-related problems.

We've had great success with "cloud" environments. Instantiate a new cloud instance, get that IP, then in your "hosts" file, point something like dev.yourdomain.com to it for testing. The only real downtime is that you should freeze the production site while the database converts to the new version, which can be a couple hours. Our mySql DB backup is 3 GB or so, but thankfully tgz's down to 280 MB.

We're using nginx and php-fpm and they are obscenely fast.

Typical migration path for me:

1. backup production site
2. start new cloud instance and copy production site to dev site (restore production database)
3. try upgrading dev site one step at a time to see what breaks
4. start new cloud instance and do completely fresh install of newest magento version
5. once working, restore production database and watch as it grinds on converting it, see what breaks
6. pick between upgrade versus fresh install
7. back up production mySql, put production site in maintenance mode while dev site converts the database
8. point domain to new IP address