Search code examples
magentoupgradeinfrastructure

Magento upgrading process and infrastructure for smallest possible downtime


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...


Solution

  • 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.