诊断 Linux 上孤立 inode 的原因,MySQL 繁忙?

诊断 Linux 上孤立 inode 的原因,MySQL 繁忙?

我们的一台服务器最近遇到了文件系统损坏的问题,我们的根文件系统被自动重新挂载为只读。我采取的恢复步骤如下:

  1. 尝试remount > mount -n -o remount /失败
  2. 重启服务器
  3. 提示执行手动fsck,有 5 个孤立的 inode 需要修复。

执行完这些步骤后,我能够获得访问权限,文件系统再次可写入。不幸的是,我没有任何有用的日志,因为没有写入任何日志,否则我会把这些日志包括进去。

有人认为,其中一个原因是我们的数据库太忙,无法正确地将数据写入磁盘,这导致了这个问题,高水平的缓存内存表明情况可能如此。然而,我对此并不确定,因为尽管缓存很高,但我们根本没有使用交换(free下面的输出)。

$ free -m
             total       used       free     shared    buffers     cached
Mem:          2041       1879        162          0         62       1599
-/+ buffers/cache:        216       1825
Swap:          471          0        471

故障发生后,有什么方法可以诊断故障?MySQL 看起来是可能的故障吗?

如果没有的话,如果将来再次发生这种情况,我应该采取什么措施?

答案1

首先检查你的服务器是否健全:

  • 您使用 ECC 内存吗?
  • 您正在运行 RAID 吗?您是否看到任何 RAID 卡错误?(dmesg 当时会显示这些错误,但现在您已重新启动,它们可能已丢失)

高级别的缓存是可取的,并且不会以任何方式损坏您的文件系统。

答案2

孤立的 inode 是良性的,当您不干净地卸载时,这是完全正常的。它们只是已被删除的文件,但在 fs 以只读方式重新挂载时仍处于打开状态。它们不是原因,而只是一种症状。您需要检查内核日志以查看导致只读重新挂载的实际问题是什么。您可能还需要运行一些 SMART 诊断程序以确保驱动器没有故障。

相关内容