在高stream量的数据库服务器上安装一个非常完整的硬盘是不好的？

首先，您不希望将数据库备份与数据库保持在相同的物理驱动器或RAID组中。 这是因为磁盘故障（如果没有RAID保护的情况下运行）或灾难性的RAID故障（如果您使用的是RAID-1或RAID-5）将导致您丢失数据库和数据库备份。

您关于磁盘性能的问题与磁盘驱动器的完整程度有关，取决于磁盘上数据的访问方式。 对于旋转磁盘，有两个影响I / O性能的物理因素。 他们是：

• 寻道时间 – 这是磁盘驱动器将磁头从当前磁道位置移动到包含请求数据的磁道所用的时间

• 旋转延迟 – 这是所需数据在驱动器旋转时到达读取头所花费的平均时间 – 对于15K RPM驱动器，这是2毫秒（毫秒）

驱动器的满载可能会影响服务器I / O所经历的平均寻道时间。 例如，如果您的驱动器已满并且您的数据库表在物理上位于磁盘盘片两端的驱动器上，那么当您执行I / O从这些表中的每一个访问数据时，这些I / O将经历驱动器的最大查找时间。

然而，如果驱动器已满，而您的应用程序仅访问驱动器上存储的一小部分数据，并且所有这些数据都连续位于驱动器上，则这些I / O将受到查找时间的最小影响。

不幸的是，这个问题的答案是“你的里程会有所不同”，这意味着你的应用程序访问数据和数据的位置将决定你的I / O性能。

此外，正如@gravyface所述，将操作系统存储要求与数据库分开将是“最佳实践”。 同样，这将有助于最小化磁盘表面上的磁头移动，因为同一驱动器上的磁头移动可能导致操作系统和驱动器的数据库区域之间的不断寻求，因为操作系统和数据库软件都会发出I / O请求。

这里有两个angular度要考虑：性能和稳健性。

在性能方面，通常推荐使用单独的磁盘主轴（或RAID组/驱动器组）：

1. 操作系统的东西（二进制文件，日志，主目录等）
2. 交换空间（如果您不希望使用交换，可能会与（1）组合）
3. 生产数据库
4. 生产数据库的事务日志（如果使用的话）
5. 数据库转储/备份

这背后的原因是非常简单的：你不希望数据库的性能受到“其他的东西”要求的磁盘的影响（例如，如果机器开始大量交换，交换分区在数据库数据的磁盘另一侧有长盘寻求争夺）。

从稳健性的angular度来看，您希望得到同样的分解，但出于不同的原因：正如其他人指出的那样，您不希望发生故障的磁盘将数据库及其备份都删除（尽pipe实际上您应该将备份复制无论如何在发生灾难性故障的情况下服务器）。

你也希望避免任何包含所有内容的整体/分区的configuration – 这是Linux世界中的一个不幸的，悲惨的， 令人震惊的常见错误，而这个错误并不是其他类Unix系统共享的。
正如Gravyface在他的评论中提到的那样，如果你以某种方式设法填满/你的系统几乎肯定会崩溃，而且如果系统具有单个/分区而不是一个结构良好的挂载点层次结构，则清理/恢复可能是耗时和昂贵的。

我build议将数据库和临时（见下文）备份移动到不同于根（/）的分区。

此外，为您的（假设）压缩数据库转储备份提出一个明智的轮换/保留scheme。 通常没有理由在本地磁盘上保留多份备份。 什么都不做灾难恢复和移动到异地时，应该从磁盘上删除。

这几乎是标准的操作程序。

这让我想起了NetApp上的一个漏洞，那里的文件系统已经接近完整，性能下降很多（如一半）。 （不可否认，这是几年前）。

大家所说的答案是有所依赖的，但是值得思考。

完整的文件系统的主要缺点是免费的inode列表可能是分散的，到处都是。

数据库的硬盘上有三种types的数据。

1. 您的实际数据库文件。 这将是一个大的预分配文件，通常以大块（例如10％）增长。
2. 日志，正在连续写入，删除，写入等的事务日志…
3. 适用于无法在内存中运行的大型查询的临时文件。

（1）在为文件集分配更多空间时只需要空闲空间。 如果数据库没有增长，它应该不受低磁盘空间文件系统的影响。 如果它正在分配，它可能会要求一个非常大的块，不适合任何自由列表，你立即碎片化你的数据库，并导致寻求何时需要数据准备进入内存。

（2）使用操作系统来pipe理分配空间并删除它的日志将会受到影响。 假设你的数据库不是只读的，将会有一个不断的日志stream，它们会经常在一个很小的硬盘空间上碎片化。 最终这会伤害你的写作performance。

（3）tempDB，如果数据库需要伪造的查询，或没有足够的内存，那么你的问题会比磁盘空间不足，导致性能问题，因为即使你的读取性能可能会变成磁盘绑定。 如果MySql需要为tempDB分配磁盘空间并且硬盘用完，也可能会出现中断的风险。

关于备份…

1. 我工作过的每个企业都在同一台机器上进行备份。 当涉及到恢复（谁在乎备份，这是恢复计数）。 在同一个磁盘上，没有任何东西会打破数据库文件的速度。
2. 希望很明显，确保备份不仅仅是本地的。

总之，我会说你会生存，提供你的数据库不写重。 如果是这样，那么磁盘空间不足是个问题。 但是如果我是你，我会尽早而不是晚些地工作。

1. 确认我有足够的内存
2. 从数据库中分离日志和所有瞬态数据。
3. 隔离你的操作系统，从其余的MySql安装。

如果可以的话，使用单独的主轴和控制器。

随后是单独的纱锭

紧接着一个穷人的分开的分区。

当我用完某个复制服务器上的所有磁盘空间时，最近遇到类似的问题。 直接的影响是复制崩溃，然后我无法login到MySQL，因为mysqld.sock文件无法打开。