На одном из наших серверов недавно произошло некоторое повреждение файловой системы, и наша корневая файловая система была автоматически перемонтирована как доступная только для чтения. Для восстановления я предпринял следующие шаги:
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 выглядит вероятным кандидатом?
Если нет, что я должен предпринять в будущем, если это повторится?
Осиротевшие иноды безвредны и совершенно нормальны, когда у вас нечистый соскок. Это просто файлы, которые были удалены, но все еще были открыты, когда fs была перемонтирована только для чтения. Они не причина, а всего лишь симптом. Вам необходимо проверить журналы ядра, чтобы увидеть, какая реальная проблема вызвала перемонтирование только для чтения. Вы также можете запустить диагностику SMART, чтобы убедиться, что диск не выходит из строя.
Сначала проверьте работоспособность вашего сервера:
Желателен высокий уровень кеширования, который никоим образом не должен повредить вашу файловую систему.