最近、サーバーの1つでファイルシステムの破損が発生し、ルートファイルシステムが読み取り専用として自動的に再マウントされました。回復するために私が取った手順は次のとおりです。
remount > mount -n -o remount /
しようとしましたが失敗しました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は有望な候補のように見えますか?
そうでない場合、これが再び発生した場合に将来実行する必要がある手順はありますか?
最初にサーバーをサニティチェックします。
高レベルのキャッシュが望ましく、ファイルシステムを破壊してはなりません。
孤立したiノードは良性であり、汚れた降車がある場合は常に完全に正常です。これらは単に削除されたファイルですが、fsが再マウントされたときに読み取り専用で開いたままでした。それらは原因ではなく、単なる症状です。カーネルログをチェックして、読み取り専用の再マウントの原因となった実際の問題を確認する必要があります。また、ドライブに障害が発生していないことを確認するために、いくつかのSMART診断を実行することもできます。