诊断 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

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

Answer 2

首先检查您的服务器：

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

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