在高流量数据库服务器上拥有非常完整的硬盘驱动器是否不好？

为高流量生产数据库服务器运行带有MySQL的Ubuntu服务器。除MySQL实例外，计算机上没有其他任何运行。

我们将每日数据库备份存储在DB服务器上，是否有任何性能下降或原因，为什么我们应该将硬盘保持相对空白？如果磁盘上的数据库和所有备份都占到86％以上，那么它是否会损害性能？

那么，运行满容量为86-90％+的DB服务器在任何方面都不会比仅运行10％满盘的服务器性能更好吗？

服务器上的磁盘总大小超过1 TB，因此，即使磁盘的10％也足以进行基本的O / S交换等。

首先，您不想将数据库备份与数据库保留在同一物理驱动器或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请求时，在驱动器的操作系统和数据库区域之间不断寻找。

这里有两个角度需要考虑：性能和鲁棒性。

在性能方面，通常建议为以下各项使用单独的磁盘轴（或RAID组/驱动器集）：

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

这背后的原因很简单：您不希望“其他东西”对磁盘的需求影响数据库性能（例如，如果计算机开始大量交换并且交换分区位于磁盘数据的另一侧）有较长的磁盘试图与之抗衡）。

从健壮性的角度来看，您希望进行同样的故障处理，但是出于不同的原因：正如其他人指出的那样，您不希望出现故障的磁盘同时删除数据库及其备份（尽管实际上您应该复制备份）无论如何，如果发生灾难性故障，则服务器）。

您还希望避免使用/包含所有内容的整体式分区进行任何配置-这是在Linux世界中发生的不幸，悲剧和令人震惊的常见错误，其他类Unix系统无法共享。
正如Gravyface在他的评论中提到的那样，如果以某种方式设法填满/系统几乎肯定会崩溃，并且如果系统具有单个/分区而不是结构良好的安装点层次结构，则清理/恢复可能既耗时又成本高昂。

我建议将数据库和临时备份（请参见下文）移动到与根目录（/）不同的分区。

另外，为您的（假定的）压缩数据库转储备份提供合理的循环/保留方案。（通常）没有理由将那么多备份副本保留在本地磁盘上。对于灾难恢复没有任何作用，当移至异地时，应将其从磁盘上删除。

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

这让我想起了NetApp上的一个错误，即接近满的文件系统的性能显着下降（如一半）。（当然，那是几年前的事）。

每个人都说答案是取决于情况，但值得深思。

完整文件系统的主要缺点是，空闲索引节点的列表很可能是零散的。

数据库硬盘上存在三种类型的数据。

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

（1）仅在为文件集分配更多空间时需要可用空间。如果数据库没有增长，则应该不受磁盘空间不足的文件系统的影响。如果是分配的话，它可能会请求一个很大的块，该块不适合任何空闲列表，您已经立即将数据库弄成碎片，并在需要何时将数据准备好放入内存时引起搜索。

（2）使用OS来管理分配空间并删除它的日志的幼稚实现。假设您的数据库不是只读的，则将有恒定的日志流，它们将经常分散在低硬盘空间上。最终，这会损害您的写入性能。

（3）tempDB，如果数据库需要它来进行劣质的书面查询，或者没有足够的RAM，那么问题就比磁盘空间不足会引起更大的问题，因为这会导致性能问题，甚至读性能也会受到磁盘的限制。如果MySql需要为tempDB分配磁盘空间并且硬盘用完了，您还存在断电的风险。

关于备份...

1. 我从事过的每个企业都将备份保存在同一台计算机上。当涉及到还原时（关心备份的人，最重要的是还原）。在同一个磁盘上拥有db文件的速度无可匹敌。
2. 希望显而易见，请确保备份不只是本地的。

简而言之，我要说的是，只要您的数据库不繁重，您就可以生存。如果是这样，则磁盘空间不足是个问题。但是，如果我是您，那么我会尽快进行以下工作。

1. 确认我有足够的RAM
2. 从数据库中隔离日志和所有临时数据。
3. 隔离您的OS，其余部分安装MySql。

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

随后是独立的主轴

紧接着是一个穷人的独立隔断。

最近，当我用完一台复制服务器上的所有磁盘空间时，我遇到了类似的问题。即时效果是复制崩溃，然后由于无法打开mysqld.sock文件而无法登录MySQL。