newbie14 Asked: 2012-02-14 20:07:55 +0800 CST2012-02-14 20:07:55 +0800 CST 2012-02-14 20:07:55 +0800 CST raid 5 适合安装 mysql 吗？ 772 raid 5 适合安装 mysql 吗？ 让我进一步解释我的申请。我的应用程序是一个套接字编程，它将与 gps 设备连接以接收 gps 字符串，然后进行进一步处理。套接字编程将在另一台服务器中，而数据库在另一台服务器中。因此，在进一步处理期间，它将从数据库中查询。所以在这里我猜会有很多 i/o 仪式。在进一步的处理过程中，最少会有 5 次选择，插入最少 1 次，但有时甚至可以最少 4 次或更多，还有一些更新。希望我现在更清楚了。 mysql configuration 5 个回答 Voted Best Answer RolandoMySQLDBA 2012-02-15T08:40:39+08:002012-02-15T08:40:39+08:00 在 RAID5 上的重读、低写环境中，我只会将其留给一个人的预算、容忍度和血压。 在写重、读低或写重、读重的环境中，RAID5 根本不可能。对于 InnoDB 尤其如此。想想 InnoDB 的表交互。 InnoDB 如果您不使用innodb_file_per_table，OMG 所有活动都将集中在一个文件 ibdata1 上。ibdata1 中包含什么？ 表数据页 表索引页 用于管理表空间 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，如果您将所有临时表（使用tmpdir）映射到与 RAID5 分开的另一个磁盘，则 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 中发布此类问题。 Aaron Bertrand 2012-02-14T20:49:16+08:002012-02-14T20:49:16+08:00 对于随机访问，RAID 10 几乎肯定会比 RAID 5 更好（当然更贵）。RAID 5 对于您的安装是否足够快？对于其他人来说，这将很难回答。 gbn 2012-02-15T00:11:25+08:002012-02-15T00:11:25+08:00 由于奇偶校验计算，RAID 5 具有很高的写入开销。看到这个和这个。那么您期望的写入负载是多少？ 那么，您是否有足够的 RAM 来容纳整个数据库的内存？如果是这样，那么您不必太担心从磁盘读取数据？ 基本上，我们无法为您回答这个问题，因为我们没有足够的细节...... jcisio 2012-02-15T00:39:24+08:002012-02-15T00:39:24+08:00 使用当前技术，RAID 5 写入通常与 RAID 10 一样快（因为奇偶校验数据是透明计算的）。只有当应用程序是写密集型时，RAID 10 才更好。 RAID 5 读取比 RAID 10 稍慢，因为数据并不总是在同一个磁盘中。但同样，磁盘/操作系统缓冲区可能发挥重要作用取决于您的应用程序。 所以问题是：这取决于。我想如果你想使用 RAID 5，你需要一个巨大的磁盘大小（如果没有，那么使用 RAID 10）。然后您可能想分析您的 MySQL 查询模式，以了解它如何读取/写入数据，在这种情况下如何执行缓存...... 最后但同样重要的是，RAID 5 在磁盘故障方面比 RAID 10 风险更大。 Rick James 2015-10-11T17:26:33+08:002015-10-11T17:26:33+08:00 但首先让我们决定您使用的标准： 旋转驱动？还是固态硬盘？ 硬件 RAID 控制器？还是操作系统软件？ 电池支持的写缓存？或不？ 将 RAID-5 与无 RAID 进行比较？到 RAID-10？要复制以进行恢复？到 DRBD？ 如果比较 -5 和 -10，您是在比较相同数量的驱动器吗？还是同样的容量？ 你的目标是什么？高可用性？从单驱动器故障中恢复？其他？ 成本有多重要？ 快速写入？ 如果可行，我会使用多台机器从驱动器故障或系统故障中恢复。（在我看来，目前分布在 3 个物理位置的 Galera 是最好的。） 一台机器，您担心单个驱动器崩溃——RAID-5 和 RAID-10 大致相同。 某种 RAID 的每 GB 价格——显然 -5 胜。 写入——-5 和 -10 都可能在每次逻辑写入时执行 2 次物理写入。-5 需要写入块并更新奇偶校验（使用 XOR）。 数据分散——RAID条带化（在 -5 和 -10 中）比手动布局数据与索引、file_per_table 等的任何事情都要好。 -5 配置中 N 个驱动器的读取性能与 -10 配置中的 N 个驱动器几乎相同。（注：同样的N，但-5会有更高的容量。） 带有 BBWC 的硬件 RAID 控制器提供“瞬时”写入，不会在电源故障中丢失数据。所以，不管其他因素如何，我都投赞成票。 （我曾经在一家大型互联网公司工作，当时他们拥有数千台带有硬件 BBWC 的 MySQL RAID-5 服务器。我从未听说过将问题归咎于 RAID-5。）
在 RAID5 上的重读、低写环境中，我只会将其留给一个人的预算、容忍度和血压。
在写重、读低或写重、读重的环境中，RAID5 根本不可能。对于 InnoDB 尤其如此。想想 InnoDB 的表交互。
InnoDB
如果您不使用innodb_file_per_table，OMG 所有活动都将集中在一个文件 ibdata1 上。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
对于 MyISAM，如果您将所有临时表（使用tmpdir）映射到与 RAID5 分开的另一个磁盘，则 RAID5在读重、写低的环境中是可以的。
请记住，表数据页存在于
.MYD文件中，其相应的索引页存在于.MYI文件中。写入繁重的环境（插入、更新、删除）将迫使 RAID5 减慢速度。鉴于 MyISAM 在写入繁重的环境中的锁定行为（每个 INSERT、UPDATE 和 DELETE 的全表锁定），稳定的 DML 流将使 RAID5 相当繁忙，并使 DB 用户进入一个短暂但令人讨厌的时间扭曲等待 DML去完成。结论
在底层，RAID5 具有以下用于奇偶校验写入的特性
如果这些步骤中的任何一个出现最轻微的间歇性，RAID5 集就会进入一个短暂但令人讨厌的时间扭曲。将其乘以大量写入，您会在数据库性能中感受到它。这些步骤中的每一个都可能是一个失败点。为什么？
根据维基百科
推荐
RAID10 不仅提供了稳定性，而且在大多数情况下允许在磁盘维护方面留有一些余地，而不会导致 mysql 宕机。镜像数据时，您知道数据的去向以及从何处读取数据。
更新 2012-02-14 17:55 EDT
阅读您的问题更新后，我会说使用 RAID10。除非您不介意长时间停机，否则您无法承担 RAID5 磁盘维护来代替磁盘同步的费用。事实上，您在 RAID10 中条带化的磁盘越小，在 RAID 10 磁盘维护后同步时间就越快。
其他需要考虑的事项
这种性质的问题可以发布在 StackOverflow 中。您也可以在 DBA StackExchange 中发布此类问题。
对于随机访问，RAID 10 几乎肯定会比 RAID 5 更好（当然更贵）。RAID 5 对于您的安装是否足够快？对于其他人来说，这将很难回答。
由于奇偶校验计算，RAID 5 具有很高的写入开销。看到这个和这个。那么您期望的写入负载是多少？
那么，您是否有足够的 RAM 来容纳整个数据库的内存？如果是这样，那么您不必太担心从磁盘读取数据？
基本上，我们无法为您回答这个问题，因为我们没有足够的细节......
使用当前技术，RAID 5 写入通常与 RAID 10 一样快（因为奇偶校验数据是透明计算的）。只有当应用程序是写密集型时，RAID 10 才更好。
RAID 5 读取比 RAID 10 稍慢，因为数据并不总是在同一个磁盘中。但同样，磁盘/操作系统缓冲区可能发挥重要作用取决于您的应用程序。
所以问题是：这取决于。我想如果你想使用 RAID 5，你需要一个巨大的磁盘大小（如果没有，那么使用 RAID 10）。然后您可能想分析您的 MySQL 查询模式，以了解它如何读取/写入数据，在这种情况下如何执行缓存......
最后但同样重要的是，RAID 5 在磁盘故障方面比 RAID 10 风险更大。
但首先让我们决定您使用的标准：
如果可行，我会使用多台机器从驱动器故障或系统故障中恢复。（在我看来，目前分布在 3 个物理位置的 Galera 是最好的。）
一台机器，您担心单个驱动器崩溃——RAID-5 和 RAID-10 大致相同。
某种 RAID 的每 GB 价格——显然 -5 胜。
写入——-5 和 -10 都可能在每次逻辑写入时执行 2 次物理写入。-5 需要写入块并更新奇偶校验（使用 XOR）。
数据分散——RAID条带化（在 -5 和 -10 中）比手动布局数据与索引、file_per_table 等的任何事情都要好。
-5 配置中 N 个驱动器的读取性能与 -10 配置中的 N 个驱动器几乎相同。（注：同样的N，但-5会有更高的容量。）
带有 BBWC 的硬件 RAID 控制器提供“瞬时”写入，不会在电源故障中丢失数据。所以，不管其他因素如何，我都投赞成票。
（我曾经在一家大型互联网公司工作，当时他们拥有数千台带有硬件 BBWC 的 MySQL RAID-5 服务器。我从未听说过将问题归咎于 RAID-5。）