主从MySQL安装在VMWare云上--需要吗？

Question

我们目前正处于为我们的电子商务业务建立一个“主”数据库的研究阶段，该数据库将集中所有数据，包括产品信息、供应商信息、Magento信息、Amazon等。我们已经研究了两种“物理硬件”(两台RAID 5机器，主/从机，与硬盘备份从-和一个单独的应用服务器).或者我们可以做一个“基于云”的系统。

问题的核心是，在云上复制有什么好处吗？云的全部要点是可伸缩性和“没有硬件停机时间”，因此不会因为硬件不好而丢失数据。在基于云的系统上发生的数据丢失(如果有的话)将基于软件。尽管如此，作为一个基于软件的问题，会导致数据丢失，这个问题很可能会被复制，对吗？因此，我们会有两台具有相同损坏数据的机器？

我们正试图分析这两种解决方案的成本/效益。当然，如果在云上复制没有好处，那么云必须提供的好处超过硬件解决方案。但是，如果在云上复制解决方案是一个更好的选择，那么硬件解决方案将大大降低成本，包括物理管理时间。

这里有人有什么经验或见解吗？

Answer 1

关于虚拟机(这本质上就是你从‘云’提供商那里得到的东西)，最需要记住的是，仅仅因为有人说了“虚拟”，就没有什么神奇的事情发生。或者“云”。

您仍然需要计划和测试高可用性，而不是仅仅假设它能工作。您仍然需要担心将数据损坏写入副本，等等。

从本质上说，推到云上所能得到的就是平台的访问性降低--人们很容易把这看作是较少的责任，但如果你的业务需要云资源，而且它们是不可用的(例如，设想几个月前，一家位于纽约的公司拥有一台现场服务器，云故障--转到新泽西的一家数据中心)，那么你就能够指向一个云供应商，并说“这是你的错”，这无助于你的网站更快地接受订单。

即使是那些运行“云”的计算机，也仍然会崩溃。

这并不是说你不应该这么做。如果你有问题的话，让一个站点外的副本准备好介入是有好处的，而且将整个基础设施转移到云提供商也有好处，所以这两种方法都是有效的。你只需要弄清楚你到底在买什么(你不是在买一些“云”，你是在购买一项服务，你需要精确地确定你将拥有哪些服务，以及他们将使用什么SLA )。

Answer 2

在这里澄清几点很重要：

• 一些云体系结构可以通过使用VMotion和类似的方法来提供“无停机时间进行定期维护”。
• 运行具有VMWare容错或类似功能的系统可以抵抗意外的硬件故障，但是设置有很大的限制(使用VMWare FT，受保护的VM只能有一个CPU核心)。
• 这两者都不是自动的，仅仅是因为你买了一些标有“云”的东西。

因此，对于可伸缩性，您可能希望使用主/从复制；这在云设置和专用硬件设置中同样有效。

由于数据库对磁盘性能特别敏感，因此需要确保您了解云提供商的IO QoS选项和超额订阅率。

Answer 3

RAID5 Viewpoint

虽然有些人认为RAID5是穷人的磁盘冗余解决方案，但为了您自己的安全和理智，请尽快摆脱RAID5。为什么？

• 在RAID5上的读取量大、低写入的环境中，我只需将其留给处理。
  • 你的预算
  • 你的宽容
  • 你的血压

• 在写量大、低读或写重、读量大的环境中，RAID5根本就不可能了.对于InnoDB来说尤其如此。

现在让我们讨论一下InnoDB和MyISAM

InnoDB

如果您不使用诺姆b，OMG所有的活动都将集中在一个文件ibdata1上。InnoDB的ibdata1中包含了什么？

• 表数据页
• 表索引页
• 用于管理TableSpace ID的表元数据
• MVCC数据(用于ACID遵从性和事务隔离)

即使是InnoDB中的读取，也倾向于用MVCC保护覆盖行，以允许可重复读取，并允许事务访问正在读取的同一行。因此，读写都会在ibdata1中产生磁盘I/O。

使用innodb_file_per_table可以通过将表数据和索引页从ibdata1中分离到.ibd文件来缓解一些磁盘I/O。然而，在RAID5环境中，我只期望在有限的时间内会有显著的性能改进。表之间的交互在某种程度上仍然相同。每次对.ibd文件的访问之前都会对ibdata1进行引用检查。

虽然分离可以带来显着的性能变化，RAID5将是他们所称的化学世界，一种限制剂。InnoDB布局更改所带来的任何好处都将被外部因素(如RAID5 )所抵消。由于innodb_file_per_table的存在，额外表空间文件的存在不会给您带来什么，而是额外表空间文件的存在。

MyISAM

当涉及到MyISAM时，如果您将所有临时表(使用未定义)映射到与RAID5分离的另一个磁盘，那么在读取量大的低写入环境中，RAID5是可以的。(听起来像是挫败了RAID5的目的，嗯？)

请记住，表数据页位于.MYD文件中，相应的索引页位于.MYI文件中。一个写量大的环境(插入、更新、删除)将迫使RAID5放慢速度.考虑到MyISAM的锁定行为(每次插入、更新和删除都有完整的表锁)，稳定的DML流将使RAID5保持相当繁忙的状态，并让DB用户输入一个简短但烦人的时间偏差，等待DML完成。

关于RAID5

的结论

在此框架下，RAID5具有以下特点，可用于使用奇偶性写入

• 读取旧数据块
• 读取旧的奇偶校验块
• 将旧数据块与写入请求进行比较。对于数据块中已翻转(从0到1，或从1到0)的每个位，在奇偶校验块中翻转相应的位。
• 编写新的数据块
• 写入新的奇偶校验块

如果这些步骤中的任何一个看到了最轻微的间歇性，RAID5集就会进入一个短暂但烦人的时间偏差。将其乘以大量的写操作，您将从数据库的性能中感受到它。这些步骤中的每一个都可能是一个失败点。为什么？

根据维基百科关于RAID5

在系统发生故障时，如果存在活动写操作，则条带的奇偶性可能与数据不一致。如果在磁盘或块失败之前没有检测和修复这一点，则可能会导致数据丢失，因为将使用不正确的奇偶校验来重建该条中丢失的块。这个潜在的漏洞有时被称为写洞。电池支持的高速缓存和类似的技术通常用于减少发生这种情况的机会窗口。

推荐(RAID5)

在大多数情况下，RAID10不仅提供了稳定性，而且允许在磁盘维护方面有一定的回旋余地，而不影响mysql。当数据被镜像时，您知道数据的去向以及数据读取的位置。

我会说和RAID10一起去吧。除非您不介意长时间的停机，否则您不能用RAID5磁盘维护来代替必要的磁盘同步。实际上，在RAID10中条纹越小的磁盘，在RAID 10磁盘维护之后同步时间就会越快。

其他需要考虑的事情

• 调优查询
• 删除冗余索引
• 尽可能多地缓存数据
• 明智地使用覆盖索引

VMWare Viewpoint

关于VMWare中的主与奴，请确保主与奴坐在单独的物理磁盘中。如果VMWare中的磁盘是RAID5，请立即使用RAID10准备另一个VMWare集群。