Take the 2-minute tour ×

We currently are in the research phase of building a "Master" database for our e-commerce business that will centralize all data, including product information, vendor information, Magento information, Amazon, etc .... We have looked into both "physical hardware" (Two RAID 5 machines, master/slave, with a HDD backup off the slave -- and a separate application server).... Or we could do a "cloud based" system.

The heart of the question is, is there any benefit with replicating on a cloud? The whole point of a cloud is scalability and "no hardware downtime" therefore no lost data due to bad hardware. The data loss that would occur, if any, on a cloud based system would be software based. With that said, being a software based issue that would cause loss of data, this issue would most likely get replicated right? Therefore we'd have 2 machines with the same corrupted data?

We are trying to analyze the cost/benefit of either solution. Of course, if there is no benefit to replicating on a cloud, then the benefits the cloud has to offer outweigh the hardware solution. However if a replicated solution on the cloud is a better option, then the hardware solution will be far less expensive, including physical management time.

Does anyone have any experience or insights here?

share|improve this question
If you do buy physical hardware, I would highly suggest NOT using RAID 5. –  toppledwagon Dec 7 '12 at 0:47
"The whole point of a cloud is scalability and 'no hardware downtime' therefore no lost data due to bad hardware." No. No no no. No no no no no! That's not true at all. –  ceejayoz Feb 2 '13 at 1:33
add comment

5 Answers

up vote 6 down vote accepted

The biggest thing to remember about virtual machines (which is essentially what you'll get from a 'cloud' provider) is that nothing magic happened just because someone said 'Virtual'. Or 'Cloud'.

You still need to plan and test high availability instead of just assuming it'll work. You still need to worry about data corruption being written to replicas, etc.

Essentially all you'd be getting from pushing to the cloud is less visability of the platform - it's tempting to view this as less responsibility but if your business needs the cloud resources and they're not available (e.g. imagine a New York based business with an onsite server and cloud fail-over to a New Jersey datacentre a few months ago) then being able to point to a cloud vendor and say "It's your fault" doesn't help your website resume taking orders any faster.

Computers still break down, even those that run "clouds".

That's not to say you shouldn't do it. There are benefits to having an off-site replica ready to step in if you have problems, and there are benefits to moving the entire infrastructure to a cloud provider, so both approaches are valid. You just need to be clear about what precisely you're buying (you're not buying some "cloud", you're buying a service and you need to nail down precisely what services you'll have and what SLA they'll be under.)

share|improve this answer
As I appreciate ALL the answers on this page, this I am going to accept this one and vote up the ones I feel were extremely helpful. Thank you all for your insight. It's easy since we've been in the 'cloud' for a year now, to get complacent because things just 'work'. As far as the RAID 5 and 10, thank you all very much for the information, it was very useful. I now am armed with the questions I need to ask our cloud provider to make an informed decision. –  Zak Dec 10 '12 at 0:35
add comment

It's important to clarify a couple points here:

  • Some cloud architectures can provide 'no downtime for scheduled maintenance' -- from the use of VMotion and similar.

  • Systems running with VMWare Fault Tolerance or similar can provide resistance to unexpected hardware failure, but there are significant limits to the setup (with VMWare FT, protected VMs can only have one CPU core).

  • Neither is automatic just because you bought something labeled 'Cloud'.

Thus, for scalability, you will probably want to go with master/slave replication; this works just as well in a cloud setup as in a dedicated-hardware setup.

As databases are particularly sensitive to disk performance, you'll want to make sure you understand your cloud provider's IO QoS options and over-subscription ratio.

share|improve this answer
As I question the IO of our disks, are there any other questions/concerns I should have? BTW you are correct about "one core per CPU", thus just to get a single processor capable of physical hardware, we have to go with 4 or 8 cores (Or as they label them CPU's). This significantly increases the cost of the cloud based setup. –  Zak Dec 7 '12 at 0:55
On top: A crashing vm can corrupt the database. A restart of the virtual machine on another computer wont fix that - there goes your high availability. –  TomTom Dec 7 '12 at 6:04
add comment

RAID5 Viewpoint

While some regard RAID5 as a poor man's disk redundancy solution, for your own safety and sanity, please get rid of RAID5 ASAP. Why ???

    • Your budget
    • Your tolerance
    • Your blood pressure

Now let's discuss InnoDB and MyISAM



  • Table Data Pages
  • Table Index Pages
  • Table Metadata for Managing TableSpace IDs
  • MVCC Data (for ACID Compliance and Transaction Isolation)





When it comes to MyISAM, RAID5 is OK in a read-heavy, low-write environment provided you map all temp tables (using tmpdir) to another disk, separate from the RAID5. (Sounds like defeating the purpose of RAID5, eh?)


Conclusion on RAID5


  • Read the old data block
  • Read the old parity block
  • Write the new data block
  • Write the new parity block


According to Wikipedia about RAID5




I would say go with RAID10. Unless you do not mind long periods of downtime, you cannot afford to do RAID5 disk maintenance in lieu of the necessary disk synchronization. In fact, the smaller the disks you stripe in RAID10, the faster the sync time would be after a RAID 10 disk maintenance.

Other things to consider

  • Tune your queries
  • Remove redundant indexes
  • Cache as much of the data as you can
  • Use covering indexes wisely

VMWare Viewpoint

Concerning the Master and Slave in VMWare, please make sure the Master and Slave are sitting in separate physical disks. If the disks in VMWare are RAID5, get another VMWare Cluster ready right now using RAID10, please.

share|improve this answer
add comment

If you want reliability then go with RAID 10 not RAID 5 and master/slave setup (RAID 10 gives you performance as well as reliability). I doubt you can get the IO performance of physical server (RAID 10) with any cloud provider. Use of cloud is very useful when your load/traffic is not consistent or you have traffic spikes 2-3 times a day. In such cases, you create new web server and database instances and discard them when traffic goes normal.

Backup your data regularly whether you are in cloud, on physical server with RAID 10/RAID 5 or master/slave replication. And most importantly, test your backups health often.

share|improve this answer
add comment


You understand that "The Cloud" is merely just normal servers running virtualised operating systems. That can, and do, suffer more (usually much more) downtime and data loss than a normal dedicated server.


Is this venture solely for your Magento store database - or for some broader ERP implementation?

If the former, then start researching again. Magento isn't bound by its DB - you'll hit a LOT of other bottlenecks before MySQL becomes a concern. That is if you don't locate your MySQL server on distant "Cloud" VPS connected by a high latency, poorly routed, highly congested, highly contended, low bandwidth WAN connection.

I've seen more data loss and unreliable stores from DIY attempts at high availability - than with a simple, single-server solution.

Looking at your other question. You are spending $14k per year on a Magento EE licence - but trying to manage your own server?

There is a good reason that specialist Magento hosting providers exist - and its to prevent you spending and potentially losing a small fortune making the wrong decisions trying to DIY. You should be focusing on running your store and doing what you're good at - not trying to be a system administrator.

share|improve this answer
add comment

Your Answer


