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