诊断 Linux 上孤立 inode 的原因，MySQL 繁忙？

Question

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

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 看起来是可能的故障吗？

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

Answer 1

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

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

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

Answer 2

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