0

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

MadBoy
  • 10,824
  • 24
  • 95
  • 156

2 Answers2

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.

Magento Guy
  • 2,493
  • 1
  • 16
  • 13
1

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
Krista K
  • 21,503
  • 3
  • 31
  • 43
  • Still there is downtime involved ... how big sites are doing it? I can't imagine some huge shop doing it this way? – MadBoy Jun 07 '12 at 18:31
  • Sure they do... they'll do it when they know they are at lowest traffic. The truly huge sites will have distributed servers and the upgrade will roll out. Then someone will have to tidy up loose ends with regard to orders placed on the "old" database... – Krista K Jun 07 '12 at 18:34
  • I was thinking about using this http://www.shopping-cart-migration.com/ so that I would setup new magneto shop for upgrade from scratch and then migrate data with it.. is this something that looks and works ok? – MadBoy Jun 07 '12 at 18:38
  • No matter what you do, some computer is going to have to churn the database and update it from old to new magento versions. Best to have the cloud instances sort that stuff out. Add memory or CPU as needed upon observation. It is creepy easy to start a new server from scratch in Rackspace or Amazon EC2. Ultimately, there will be either down time or lost orders that need to be transferred after-the-fact by hand from old DB to new one. Oh, and we use github for file version control, too. – Krista K Jun 07 '12 at 18:51
  • The shopping-cart-migration seems to offer a way to copy "missing" orders after everything. Seems like a good tool for this. And yes I was planning to have multiple instances like that for migration. Thank you – MadBoy Jun 07 '12 at 18:56