我们目前正处于为我们的电子商务业务构建一个“主”数据库的研究阶段，该数据库将集中所有数据，包括产品信息、供应商信息、Magento 信息、亚马逊等......我们已经研究了“物理”硬件”（两台 RAID 5 机器，主/从，从属硬盘备份 - 和一个单独的应用程序服务器）......或者我们可以做一个“基于云”的系统。
问题的核心是，在云上进行复制有什么好处吗？云的全部要点是可扩展性和“无硬件停机”，因此不会因硬件损坏而丢失数据。在基于云的系统上发生的数据丢失（如果有的话）将是基于软件的。话虽如此，作为一个会导致数据丢失的基于软件的问题，这个问题很可能会被复制，对吗？因此我们会有 2 台机器有相同的损坏数据？
我们正在尝试分析任一解决方案的成本/收益。当然，如果在云上复制没有任何好处，那么云必须提供的好处超过硬件解决方案。但是，如果云上的复制解决方案是更好的选择，那么硬件解决方案的成本就会低得多，包括物理管理时间。
有人在这里有任何经验或见解吗？
关于虚拟机（本质上是您将从“云”提供商那里获得的），要记住的最重要的事情是没有任何神奇的事情发生只是因为有人说了“虚拟”。或“云”。
您仍然需要计划和测试高可用性，而不是仅仅假设它会工作。您仍然需要担心写入副本等的数据损坏。
从本质上讲，你从推动到云中得到的只是平台的可见性降低——人们很容易将其视为责任减少，但如果你的企业需要云资源但它们不可用（例如想象一家总部位于纽约的企业几个月前现场服务器和云故障转移到新泽西数据中心）然后能够指向云供应商并说“这是你的错”并不能帮助你的网站更快地恢复接受订单。
计算机仍然会出故障，即使是运行“云”的计算机也是如此。
这并不是说你不应该这样做。如果您遇到问题，准备好异地副本是有好处的，将整个基础架构迁移到云提供商也有好处，因此这两种方法都是有效的。您只需要清楚您购买的到底是什么（您不是购买一些“云”，您购买的是一项服务，您需要准确确定您将拥有哪些服务以及它们将是什么 SLA在下面。）
在这里澄清几点很重要：
一些云架构可以提供“没有停机时间进行定期维护”——来自于 VMotion 和类似的使用。
运行 VMWare Fault Tolerance 或类似功能的系统可以抵抗意外的硬件故障，但设置有很大的限制（使用 VMWare FT，受保护的 VM 只能有一个 CPU 内核）。
两者都不是自动的，因为你买了标有“云”的东西。
因此，为了可伸缩性，您可能希望使用主/从复制；这在云设置中和在专用硬件设置中一样有效。
由于数据库对磁盘性能特别敏感，您需要确保了解云提供商的 IO QoS 选项和超额订阅率。
RAID5观点
虽然有些人将 RAID5 视为穷人的磁盘冗余解决方案，但为了您自己的安全和理智，请尽快摆脱 RAID5。为什么 ？？？
现在让我们讨论一下 InnoDB 和 MyISAM
InnoDB
如果你不使用innodb_file_per_table，我的天哪，所有的活动都将只围绕一个文件 ibdata1。InnoDB 的 ibdata1 包含什么？
甚至 InnoDB 中的读取也倾向于使用 MVCC 保护来覆盖行，以允许可重复读取并允许事务命中正在读取的相同行。因此，读取和写入都会在 ibdata1 中产生磁盘 I/O。
通过将表数据和索引页从 ibdata1 分离到文件中，使用
innodb_file_per_table可以减轻一些磁盘 I/O 。.ibd然而，我希望在 RAID5 环境中仅在有限的时间内获得显着的性能改进。表交互仍然有些相同。每次访问.ibd文件之前总是先对 ibdata1 进行引用检查。虽然分离可以带来显着的性能变化，但 RAID5 将是他们在化学世界中所说的一种限制性试剂。InnoDB 布局更改带来的任何预期好处都会被外部因素抵消，例如 RAID5。
innodb_file_per_table随着时间的推移，额外表空间文件的存在不会给您带来任何好处，而只是额外表空间文件的存在。MyISAM
对于 MyISAM，如果您将所有临时表（使用tmpdir）映射到与 RAID5 分开的另一个磁盘，则 RAID5在读取密集型、写入较少的环境中是可行的。（听起来好像违背了 RAID5 的目的，是吗？）
请记住，表数据页存在于
.MYD文件中，其相应的索引页存在于.MYI文件中。大量写入的环境（INSERT、UPDATE、DELETE）将迫使 RAID5 减慢速度。考虑到 MyISAM 在写入密集型环境中的锁定行为（每次插入、更新和删除都会锁定全表），稳定的 DML 流将使 RAID5 相当繁忙，并让 DB 用户进入一个短暂但烦人的等待 DML 的时间扭曲去完成。RAID5 的结论
在引擎盖下，RAID5 具有以下用于奇偶校验写入的特征
如果这些步骤中的任何一个出现最轻微的间歇性，RAID5 集就会进入一个短暂但烦人的时间扭曲。将其乘以大量写入，您将在数据库性能中感受到它。这些步骤中的每一个都可能是一个失败点。为什么？
根据维基百科关于 RAID5
推荐（RAID5）
RAID10 不仅提供了稳定性，而且在大多数情况下在不关闭 mysql 的情况下允许磁盘维护有一些余地。镜像数据时，您知道数据的去向以及从何处读取数据。
我会说使用 RAID10。除非您不介意长时间的停机，否则您无法用 RAID5 磁盘维护来代替必要的磁盘同步。事实上，在 RAID10 中条带化的磁盘越小，RAID 10 磁盘维护后的同步时间就越快。
其他需要考虑的事情
VMWare观点
关于 VMWare 中的 Master 和 Slave，请确保 Master 和 Slave 位于不同的物理磁盘中。如果 VMWare 中的磁盘是 RAID5，请立即使用 RAID10 准备好另一个 VMWare 集群。
如果您想要可靠性，那么使用 RAID 10 而不是 RAID 5 和主/从设置（RAID 10 为您提供性能和可靠性）。我怀疑您能否通过任何云提供商获得物理服务器 (RAID 10) 的 IO 性能。当您的负载/流量不一致或您每天有 2-3 次流量高峰时，使用云非常有用。在这种情况下，您可以创建新的 Web 服务器和数据库实例，并在流量正常时丢弃它们。
定期备份您的数据，无论您是在云端、使用 RAID 10/RAID 5 或主/从复制的物理服务器上。最重要的是，经常测试您的备份健康状况。
您了解“云”只是运行虚拟化操作系统的普通服务器。与普通的专用服务器相比，它可以而且确实会遭受更多（通常更多）的停机时间和数据丢失。
此项目仅用于您的 Magento 商店数据库 - 还是用于更广泛的 ERP 实施？
如果是前者，则重新开始研究。Magento 不受其数据库的约束——在 MySQL 成为问题之前，您会遇到很多其他瓶颈。也就是说，如果您没有将 MySQL 服务器定位在通过高延迟、路由不良、高度拥塞、竞争激烈、低带宽 WAN 连接连接的远程“云”VPS 上。
与简单的单服务器解决方案相比，我在高可用性的 DIY 尝试中看到了更多的数据丢失和不可靠的存储。
看着你的其他问题。您每年在 Magento EE 许可证上花费 14,000 美元 - 但试图管理自己的服务器？
专业的 Magento 托管服务提供商的存在是有充分理由的 - 它可以防止您在尝试 DIY 时做出错误的决定而花费并可能损失一笔不小的财富。您应该专注于经营您的商店并做您擅长的事情——而不是试图成为系统管理员。