运行带有 MySQL 的 Ubuntu 服务器，用于高流量生产数据库服务器。除了 MySQL 实例外，机器上没有运行任何其他东西。
我们每天将数据库备份存储在数据库服务器上，这是否会对性能造成影响？或者我们为什么要保持硬盘相对空闲？如果数据库和所有备份占用了磁盘空间的 86% 以上，这会对性能造成影响吗？
那么，以 86-90% 以上的满容量运行的数据库服务器的性能是否会比仅以 10% 的磁盘容量运行的服务器更差？
服务器上的总磁盘大小超过 1 TB，因此即使 10% 的磁盘也足以进行基本的操作系统交换等。
答案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 请求。
答案2
这里有两个角度需要考虑：性能和稳健性。
从性能角度来看，通常建议为以下设备配备单独的磁盘主轴（或 RAID 组/驱动器集）：
- 操作系统内容（二进制文件、日志、主目录等）
- 交换空间（如果不想使用交换，可以与（1）结合使用）
- 生产数据库
- 生产数据库的事务日志（如果使用）
- 数据库转储/备份
这背后的原因很简单：您不希望数据库性能受到需要磁盘的“其他东西”的影响（例如，如果机器开始大量交换，并且交换分区位于磁盘的另一侧，而数据库数据则需要长时间的磁盘寻道才能处理）。
从稳健性的角度来看，您希望发生相同类型的故障，但原因不同：正如其他人指出的那样，您不希望故障磁盘同时取出您的数据库及其备份（尽管实际上，如果发生灾难性故障，您应该从服务器上复制备份）。
您还希望避免任何/包含所有内容的单片分区配置——这是一个不幸的、悲剧的和极其普遍Linux 世界中犯下的错误，其他类 Unix 系统不会犯下这种错误。
正如 Gravyface 在其评论中提到的，如果您设法填满，您的系统几乎肯定会崩溃，并且如果系统只有一个分区而不是结构良好的挂载点层次结构，则/清理/恢复可能非常耗时且成本高昂。/
答案3
我建议将数据库和临时（见下文）备份移动到与根（/）不同的分区。
此外，为您的（假设的）压缩数据库转储备份制定合理的轮换/保留方案。通常没有理由在本地磁盘上保留那么多备份副本。对于灾难恢复没有任何作用，当移出现场时，应该从磁盘中删除。
这几乎是标准操作程序。
答案4
我最近也遇到过类似的问题，当时我的一台复制服务器的磁盘空间全部用完了。直接的影响就是复制崩溃，然后我无法登录 MySQL，因为无法打开 mysqld.sock 文件。