我们目前正处于为电子商务业务build立一个“主”数据库的研究阶段，该数据库将集中包括产品信息，供应商信息，Magento信息，亚马逊等在内的所有数据……我们研究了“物理硬件“（两个RAID 5机器，主/从，备用硬盘备份和一个单独的应用程序服务器）….或者我们可以做一个”基于云“的系统。
问题的核心是，在云上复制是否有任何好处？ 云的全部重点是可扩展性和“无硬件停机”，因此不会因硬件损坏而丢失数据。 在基于云的系统上将发生的数据丢失（如果有的话）将是基于软件的。 这就是说，作为一个会导致数据丢失的软件问题，这个问题最有可能得到复制吗？ 因此，我们将有2台机器具有相同的数据损坏？
我们正试图分析两种解决scheme的成本/收益。 当然，如果在云上复制没有任何好处，那么云所提供的好处将超过硬件解决scheme。 但是，如果在云上复制解决scheme是更好的select，那么硬件解决scheme将会更便宜，包括物理pipe理时间。
有没有人有任何经验或见解？
关于虚拟机最重要的一点是（这实际上是从“云”提供商那里得到的），就是因为有人说“虚拟”而发生了什么奇迹 。 或“云”。
你仍然需要计划和testing高可用性，而不是假设它会工作。 您仍然需要担心数据损坏正在写入副本等。
从本质上讲，所有你从云计算中获得的东西都是平台的可视性较差 – 这很容易被看作是责任较小，但是如果你的业务需要云资源，而且它们不可用（比如想象一下纽约的一家公司一个现场服务器和云在几个月前故障转移到新泽西州的数据中心），然后能够指向一个云供应商，并说“这是你的错”不能帮助你的网站恢复更快的订单。
计算机仍然崩溃，即使是那些运行“云”的计算机。
这并不是说你不应该这样做。 如果您遇到问题，可以让异地副本准备好介入，而将整个基础架构转移到云提供商也有好处，所以这两种方法都是有效的。 你只需要清楚你正在购买什么（你不买一些“云”，你正在购买一个服务，你需要明确什么服务，你会有什么SLA，他们将下。）
在这里澄清几点很重要：
一些云架构可以提供“不需要停机维护计划” – 从使用VMotion和类似软件。
运行VMWare Fault Tolerance或类似系统的系统可以防止意外的硬件故障，但是对于设置有很大限制（使用VMWare FT，受保护的VM只能有一个CPU内核）。
既不是因为你买了标有“云”的东西而自动的。
因此，对于可伸缩性，您可能需要使用主/从复制; 这在云端设置和专用硬件设置中一样好。
由于数据库对磁盘性能特别敏感，因此您需要确定您了解云提供商的IO QoS选项和超额认购比率。
虽然有人认为RAID5是一个穷人的磁盘冗余解决scheme，但为了您自己的安全和理智，请尽快摆脱RAID5。 为什么？
现在我们来讨论一下InnoDB和MyISAM
如果你不使用innodb_file_per_table ，那么OMG的所有活动都将围绕一个文件ibdata1进行。 InnoDB的ibdata1中包含了什么？
即使在InnoDB中读取也往往会使用MVCC保护行来允许重复读取，并允许事务处理读取相同的行。 因此，读取以及写入在ibdata1中产生磁盘I / O。
使用innodb_file_per_table可以通过将表数据和索引页从ibdata1分离到.ibd文件中来减轻某些磁盘I / O。 然而，我认为只有在RAID5环境中有限的时间内才会有明显的性能提升。 表交互仍然有点相同。 对.ibd文件的每次访问总是在针对ibdata1的引用检查之前进行。
虽然分离可以带来显着的性能变化，但RAID5将是他们在化学领域所称的限制性试剂。 InnoDB布局变化所带来的任何好处都将被诸如RAID5之类的外部因素所抵消。 由于innodb_file_per_table的额外表空间文件的存在，随着时间的推移你什么也不买，而只是存在额外的表空间文件。
当涉及到MyISAM时，RAID5在读取繁重，低写入的环境中可以正常工作， 只要将所有临时表（使用tmpdir ）映射到与RAID5分开的另一个磁盘即可 。 （听起来像是击败RAID5的目的，呃？）
请记住，表格数据页位于.MYD文件及其相应的索引页面中。 一个写入繁重的环境（插入，更新，删除）将强制RAID5放慢速度。 鉴于MyISAM的locking行为（在每个INSERT，UPDATE和DELETE中的全表locking），在一个写入繁重的环境中，稳定的DMLstream将使RAID5保持相当繁忙的状态，让DB用户input一个简短但烦人的时间扭曲，等待DML去完成。
在引擎盖下，RAID5具有以下奇偶写入特性
如果这些步骤中的任何一个都能看到最轻微的间歇性，那么RAID5会产生一个短暂而烦人的时间扭曲。 乘以大量的写入，你会感觉到它在数据库的性能。 这些步骤中的每一步都可能是一个失败点。 为什么？
据维基百科关于RAID5
如果在主动写入期间发生系统故障，则条带的奇偶校验可能与数据不一致。 如果在磁盘或磁盘块出现故障之前未检测到并修复此问题，则可能会导致数据丢失，因为将使用不正确的奇偶校验重build该条带中的缺失块。 这种潜在的漏洞有时被称为写入漏洞。 通常使用电池支持的caching和类似技术来减less发生这种情况的机会窗口。
RAID10不仅提供了稳定性，而且在大多数情况下不会影响MySQL的磁盘维护。 当数据被镜像时，你知道数据在哪里，你知道从哪里读取数据。
我会说与RAID10一起去。 除非您不介意长时间停机，否则不能进行RAID5磁盘维护以代替必要的磁盘同步。 实际上，在RAID10中磁盘分区越小，RAID 10磁盘维护后的同步时间就越快。
其他事情要考虑
关于VMWare中的Master和Slave，请确保Master和Slave位于不同的物理磁盘中。 如果VMWare中的磁盘是RAID5，请立即使用RAID10准备另一个VMWare Cluster。
如果你想要可靠性，那么去RAID 10而不是RAID 5和主/从设置（RAID 10给你的性能以及可靠性）。 我怀疑你可以用任何云提供商获得物理服务器（RAID 10）的IO性能。 当您的负载/stream量不一致或者每天有2-3次的stream量峰值时，使用云是非常有用的。 在这种情况下，您将创build新的Web服务器和数据库实例，并在stream量正常时将其丢弃。
无论是在云端，在RAID 10 / RAID 5的物理服务器还是主/从复制，都要定期备份数据。 而最重要的是，经常testing你的备份健康。
云的全部重点是可扩展性和“无硬件停机”，因此不会因硬件损坏而丢失数据。
您了解“云”只是运行虚拟化操作系统的普通服务器。 那可以，并且比通常的专用服务器承受更多（通常更多）的停机时间和数据丢失。
目前我们正在为电子商务业务build立一个“硕士”数据库的研究阶段
这个冒险只是为了你的Magento商店数据库 – 还是为了一些更广泛的ERP实施？
如果前者再开始研究。 Magento不受其数据库绑定 – 在MySQL成为问题之前，你会遇到很多其他的瓶颈。 也就是说，如果您没有将您的MySQL服务器放置在由高延迟，路由不畅，高度拥挤，高度竞争，低带宽的广域网连接连接的远程“云”VPS上。
我看到更多的数据丢失和不可靠的商店从高可用性的DIY尝试 – 而不是一个简单的，单服务器解决scheme。
看着你的另一个问题 。 你每年在Magento EE许可证上花费14000美元 – 但是试图pipe理你自己的服务器？
有一个很好的理由，专门的Magento托pipe服务提供商存在 – 它会阻止你花费，并可能失去一笔小小的财富，做出错误的决定，试图DIY。 你应该专注于运行你的商店，并做你擅长的事情 – 不要成为系统pipe理员。