Um dos nossos servidores experimentou recentemente alguma corrupção no sistema de arquivos e nosso sistema de arquivos raiz foi remontado automaticamente como somente leitura. Os passos que tomei para recuperar foram:
remount > mount -n -o remount / esta falha fsck , havia 5 inodes órfãos que precisavam ser corrigidos. Depois de executar estas etapas, consegui acesso e o sistema de arquivos foi gravável novamente. Infelizmente, não tenho registros informativos, pois nenhum deles foi escrito ou eu os incluiria.
Uma causa que foi sugerida foi que nosso banco de dados estava muito ocupado para gravar os dados no disco adequadamente e isso causou o problema, o alto nível de memória cache foi dado como uma indicação de que esse poderia ser o caso. No entanto, não tenho certeza sobre isso, pois, embora o cache seja alto, não estamos usando a troca (saída de free abaixo).
$ free -m
total used free shared buffers cached
Mem: 2041 1879 162 0 62 1599
-/+ buffers/cache: 216 1825
Swap: 471 0 471
Existe alguma maneira de diagnosticar a falha depois que ela aconteceu? O MySQL parece um provável candidato?
Se não houver alguma medida que eu deva tomar no futuro, se isso acontecer novamente?
Primeira sanidade, verifique seu servidor:
Um alto nível de cache é desejável e não deve corromper seu sistema de arquivos de qualquer forma.
Os inodes órfãos são benignos e perfeitamente normais sempre que você tem uma desumidificação impura. Eles são simplesmente arquivos que foram excluídos, mas ainda estavam abertos quando o fs foi remontado somente para leitura. Eles não são a causa, mas apenas um sintoma. Você precisa verificar seus logs de kernel para ver qual foi o problema real que causou a remontagem somente leitura. Você também pode querer executar alguns diagnósticos SMART para garantir que a unidade não está falhando.
Tags mysql inode linux filesystems corruption