在高流量数据库服务器上拥有一个非常满的硬盘驱动器是不是很糟糕？

Question

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

我们每天在数据库服务器上存储数据库备份，是否有任何性能损失或我们应该保持硬盘相对空的原因？如果磁盘被数据库和所有备份填满了 86% 以上，它会影响性能吗？

那么，以 86-90%+ 满容量运行的数据库服务器在任何方面都比仅使用 10% 满磁盘运行的服务器性能差吗？

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

Answer 1

首先，您不想将数据库备份保存在与数据库相同的物理驱动器或 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 请求。

Answer 2

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

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

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

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

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

您还希望避免使用/包含所有内容的整体分区进行任何配置——这是在 Linux 世界中犯下的一个不幸的、悲惨的、令人震惊的常见错误，其他类 Unix 系统没有共享。
正如 Gravyface 在他的评论中提到的，如果你以某种方式设法填满/你的系统几乎肯定会崩溃，如果系统只有一个/分区而不是一个结构良好的挂载点层次结构，清理/恢复可能既耗时又昂贵。

Answer 3

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

此外，为您的（假设的）压缩数据库转储备份提出合理的轮换/保留方案。（通常）没有理由在本地磁盘上保留那么多备份副本。对灾难恢复没有任何作用，当移到异地时，应该从磁盘中删除。

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