我们的一台服务器最近遇到了文件系统损坏的问题,我们的根文件系统被自动重新挂载为只读。我采取的恢复步骤如下:
- 尝试
remount > mount -n -o remount /
失败 - 重启服务器
- 提示执行手动
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 诊断程序以确保驱动器没有故障。