Linux、ビジーMySQLで孤立したiノードの原因を診断しますか？

Question

最近、サーバーの1つでファイルシステムの破損が発生し、ルートファイルシステムが読み取り専用として自動的に再マウントされました。回復するために私が取った手順は次のとおりです。

1. remount > mount -n -o remount /しようとしましたが失敗しました
2. サーバーを再起動しました
3. 手動でfsckを実行するように求められた場合、修正が必要な孤立したiノードが5つありました。

これらの手順を実行した後、アクセスできるようになり、ファイルシステムは再び書き込み可能になりました。残念ながら、何も書かれていないか、これらを含めていたので、有益なログはありません。

提案された原因の1つは、データベースがビジー状態でデータをディスクに正しく書き込むことができず、これが問題の原因でした。これが当てはまる可能性があることを示すために、高レベルのキャッシュメモリが指定されました。ただし、キャッシュは高いものの、スワップをまったく使用していないため、これについてはよくわかりません（以下の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

孤立したiノードは良性であり、汚れた降車がある場合は常に完全に正常です。これらは単に削除されたファイルですが、fsが再マウントされたときに読み取り専用で開いたままでした。それらは原因ではなく、単なる症状です。カーネルログをチェックして、読み取り専用の再マウントの原因となった実際の問題を確認する必要があります。また、ドライブに障害が発生していないことを確認するために、いくつかのSMART診断を実行することもできます。