raid 5 适合安装 mysql 吗？

Question

raid 5 适合安装 mysql 吗？

让我进一步解释我的应用程序。我的应用程序是一个套接字编程，它将与 gps 设备连接以接收 gps 字符串，然后进行进一步处理。套接字编程将在另一台服务器中，而 db 将在另一台服务器中。因此，在进一步处理期间，它将从数据库查询。所以在这里我猜会有很多 i/o 仪式。在进一步的处理过程中，最少有 5 个选择，插入最少 1 个，但有时它甚至可能最少 4 个或更多，还有一些更新。希望我现在更清楚了。

Answer 1

在 RAID5 上的读取量大、写入量低的环境中，我会将其留给自己的预算、容忍度和血压。

在写重读低读或写重读重读的环境中，RAID5 简直是不可能的。对于 InnoDB 尤其如此。想想 InnoDB 的表交互。

数据库

如果您不使用innodb_file_per_table，我的天哪，所有活动都将围绕一个文件 ibdata1. 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 导致的额外表空间文件的存在随着时间的推移不会给您带来任何好处，而只会带来额外的表空间文件。

我的ISAM

当涉及到 MyISAM 时，RAID5 在读大量、低写的环境中是可以的，前提是您将所有临时表（使用tmpdir）映射到另一个磁盘，与 RAID5 分开。

请记住，表数据页存在于.MYD文件中，而其相应的索引页存在于.MYI文件中。大量写入的环境（插入、更新、删除）将迫使 RAID5 减慢速度。考虑到 MyISAM 在写密集环境中的锁定行为（每个 INSERT、UPDATE 和 DELETE 的全表锁定），稳定的 DML 流将使 RAID5 保持忙碌，并使 DB 用户进入等待 DML 的短暂但烦人的时间扭曲去完成。

结论

在引擎盖下，RAID5 具有以下用于奇偶校验写入的特性

• 读取旧数据块
• 读取旧的奇偶校验块
• 将旧数据块与写入请求进行比较。对于数据块中发生翻转（从 0 变为 1，或从 1 变为 0）的每一位，翻转奇偶校验块中的相应位
• 写入新数据块
• 写入新的奇偶校验块

如果这些步骤中的任何一个出现最轻微的间歇性，RAID5 集就会进入一个短暂但令人讨厌的时间扭曲。将其乘以大量写入，您会在数据库性能中感受到它。这些步骤中的每一个都可能是一个失败点。为什么？

根据维基百科

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

推荐

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

更新 2012-02-14 17:55 EDT

阅读您的问题更新后，我会说使用 RAID10。除非您不介意长时间的停机，否则您无法用 RAID5 磁盘维护来代替磁盘同步。事实上，您在 RAID10 中条带化的磁盘越小，RAID 10 磁盘维护后的同步时间就越快。

其他需要考虑的事项

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

这种性质的问题可以在 StackOverflow 中发布。您也可以在 DBA StackExchange 中发布此类问题。