Esta matriz de software raid1 falhou? (mdadm)

1

Versão longa: Estou executando uma máquina Red Hat Enterprise Linux 5 (REHL5) com o software raid1 (mdadm).

Alguns dias atrás eu fui fazer backup de alguns dados do MySQL e de repente eu não consegui mais entrar na máquina. Eu digitei um nome de usuário para entrar e, em seguida, seria apenas sentar lá. Se uma seqüência de controle pressionada, eles apareceriam na tela, mas ela nunca entraria. Também não respondeu à ctrl + alt + delete. Então eu fiz um hard power down.

Eu inicializei o backup e monitorei o array raid1 via:

mdadm --detail /dev/md1

Esta matriz contém o ponto de montagem da raiz.

Começou a fazer uma ressincronização do array. Eu não tenho certeza se isso aconteceu por causa do acidente ou apenas porque eu fiz um disco rígido para baixo. De qualquer maneira eu deixo terminar:

[f@mysqldatanode ~]# mdadm --detail /dev/md1
/dev/md1:
        Version : 00.90.03
  Creation Time : Thu Apr 19 15:28:52 2007
     Raid Level : raid1
     Array Size : 479893568 (457.66 GiB 491.41 GB)
    Device Size : 479893568 (457.66 GiB 491.41 GB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 1
    Persistence : Superblock is persistent

    Update Time : Fri Dec 25 10:03:50 2009
          State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           UUID : ab4849de:1f4f41c4:defd01e8:a4979ca6
         Events : 0.78

    Number   Major   Minor   RaidDevice State
       0       8        2        0      active sync   /dev/sda2
       1       8       18        1      active sync   /dev/sdb2

Examinei alguns logs (/ var / log / messages *) e encontrei várias mensagens como a que está abaixo, indicando problemas no disco rígido:

Dec 21 11:39:47 localhost kernel: sd 0:0:1:0: SCSI error: return code = 0x08000002
Dec 21 11:39:47 localhost kernel: sdb: Current: sense key: Medium Error
Dec 21 11:39:47 localhost kernel:     Additional sense: Unrecovered read error
Dec 21 11:39:47 localhost kernel: Info fld=0x3348912
Dec 21 11:39:47 localhost kernel: end_request: I/O error, dev sdb, sector 53774610
Dec 21 11:39:47 localhost kernel: raid1:md1: read error corrected (8 sectors at 53565760 on sdb2)
Dec 21 11:39:48 localhost kernel: raid1: sdb2: redirecting sector 53565648 to another mirror

Então eu tentei procurar por badblocks e trancou novamente da mesma forma.

[f@mysqldatanode ~]# badblocks -s /dev/md1
Checking for bad blocks (read-only test):               0/      479893568

Então, como devo avaliar a integridade das duas unidades? Como a matriz em questão contém o ponto de montagem raiz, preciso movê-los para outra máquina para analisá-los?

    
por fredrick 28.12.2009 / 23:58

2 respostas

10

Você pode falhar o dispositivo / dev / sdb através do mdadm (é melhor falhar no dispositivo inteiro, isto é, todos os mds que o executam) e verificar se há erros, mas pelo que você está descrevendo, é mais provável substituindo o dispositivo.

Eu tive dispositivos ide que falharam regularmente, continuei adicionando novamente o dispositivo rejeitado até que, finalmente, o computador começou a funcionar como você descreveu. Substituir o dispositivo com falha resolveu o problema.

Em ambos os casos, você deve fazer um backup o mais rápido possível.

    
por 29.12.2009 / 00:20
2

Os erros de leitura são comuns, mas os discos corrigem a maioria deles por si mesmos. Alguns discos se encontram e relatam boas leituras nas informações SMART, e alguns relatam o número correto de erros e o número de ECC recuperados. Alguns discos (perpendicular em particular) podem ter milhões de erros de leitura e 99,99999% (ou mais) de recuperação de ECC.

No entanto, desta vez / dev / sdb2 não conseguiu ler corretamente 8 setores.

O softraid então simplesmente recuperou buscando os setores ausentes do outro disco e reescrevendo-os. Então decidiu que tudo está bem novamente.

Isso PODERIA ser um sinal de uma unidade defeituosa, mas também poderia ser um erro uma vez em um mtbf, uma partícula de poeira perdida ou o que quer que seja. Aguarde e veja se mais erros surgem antes de eliminar a unidade.

    
por 05.02.2010 / 16:18