O Debian, mdadm, Degraded Array, disco tornou-se disponível após a re-adição

2

Esta noite recebi uma mensagem gerada pelo mdadm no meu servidor:

This is an automatically generated mail message from mdadm

A DegradedArray event had been detected on md device /dev/md3.

Faithfully yours, etc.

P.S. The /proc/mdstat file currently contains the following:

Personalities : [raid1]
md4 : active raid1 sdb4[0] sda4[1]
                 474335104       blocks [2/2] [UU]

md3 : active raid1 sdb3[2](F) sda3[1]
     10000384 blocks [2/1] [_U]

md2 : active (auto-read-only) raid1 sdb2[0] sda2[1]
     4000064 blocks [2/2] [UU]

md1 : active raid1 sdb1[0] sda1[1]
     48064 blocks [2/2] [UU]

Eu removi o / dev / sdb3 do / dev / md3 e o reinscrevi, ele estava sendo reconstruído por um tempo e se tornou um dispositivo de reserva, então agora eu tenho essas estatísticas:

cat /proc/mdstat
Personalities : [raid1]
md4 : active raid1 sdb4[0] sda4[1]
      474335104 blocks [2/2] [UU]

md3 : active raid1 sdb3[2](S) sda3[1]
      10000384 blocks [2/1] [_U]

md2 : active (auto-read-only) raid1 sdb2[0] sda2[1]
      4000064 blocks [2/2] [UU]

md1 : active raid1 sdb1[0] sda1[1]
      48064 blocks [2/2] [UU]

e

[CÓDIGO]

mdadm -D /dev/md3
/dev/md3:
        Version : 0.90
  Creation Time : Sat Jun 28 14:47:58 2008
     Raid Level : raid1
     Array Size : 10000384 (9.54 GiB 10.24 GB)
  Used Dev Size : 10000384 (9.54 GiB 10.24 GB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 3
    Persistence : Superblock is persistent

    Update Time : Sun Sep  4 16:30:46 2011
          State : clean, degraded
 Active Devices : 1
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 1

           UUID : 1c32c34a:52d09232:fc218793:7801d094
         Events : 0.7172118

    Number   Major   Minor   RaidDevice State
       0       0        0        0      removed
       1       8        3        1      active sync   /dev/sda3

       2       8       19        -      spare   /dev/sdb3

Aqui estão os últimos registros em / var / log / messages

Sep  4 16:15:45 ogw2 kernel: [1314646.950806] md: unbind<sdb3>
Sep  4 16:15:45 ogw2 kernel: [1314646.950820] md: export_rdev(sdb3)
Sep  4 16:17:00 ogw2 kernel: [1314721.977950] md: bind<sdb3>
Sep  4 16:17:00 ogw2 kernel: [1314722.011058] RAID1 conf printout:
Sep  4 16:17:00 ogw2 kernel: [1314722.011064]  --- wd:1 rd:2
Sep  4 16:17:00 ogw2 kernel: [1314722.011070]  disk 0, wo:1, o:1, dev:sdb3
Sep  4 16:17:00 ogw2 kernel: [1314722.011073]  disk 1, wo:0, o:1, dev:sda3
Sep  4 16:17:00 ogw2 kernel: [1314722.012667] md: recovery of RAID array md3
Sep  4 16:17:00 ogw2 kernel: [1314722.012673] md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
Sep  4 16:17:00 ogw2 kernel: [1314722.012677] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for recovery.
Sep  4 16:17:00 ogw2 kernel: [1314722.012684] md: using 128k window, over a total of 10000384 blocks.
Sep  4 16:20:25 ogw2 kernel: [1314927.480582] md: md3: recovery done.
Sep  4 16:20:27 ogw2 kernel: [1314929.252395] ata2.00: configured for UDMA/133
Sep  4 16:20:27 ogw2 kernel: [1314929.260419] ata2.01: configured for UDMA/133
Sep  4 16:20:27 ogw2 kernel: [1314929.260437] ata2: EH complete
Sep  4 16:20:29 ogw2 kernel: [1314931.068402] ata2.00: configured for UDMA/133
Sep  4 16:20:29 ogw2 kernel: [1314931.076418] ata2.01: configured for UDMA/133
Sep  4 16:20:29 ogw2 kernel: [1314931.076436] ata2: EH complete
Sep  4 16:20:30 ogw2 kernel: [1314932.884390] ata2.00: configured for UDMA/133
Sep  4 16:20:30 ogw2 kernel: [1314932.892419] ata2.01: configured for UDMA/133
Sep  4 16:20:30 ogw2 kernel: [1314932.892436] ata2: EH complete
Sep  4 16:20:32 ogw2 kernel: [1314934.828390] ata2.00: configured for UDMA/133
Sep  4 16:20:32 ogw2 kernel: [1314934.836397] ata2.01: configured for UDMA/133
Sep  4 16:20:32 ogw2 kernel: [1314934.836413] ata2: EH complete
Sep  4 16:20:34 ogw2 kernel: [1314936.776392] ata2.00: configured for UDMA/133
Sep  4 16:20:34 ogw2 kernel: [1314936.784403] ata2.01: configured for UDMA/133
Sep  4 16:20:34 ogw2 kernel: [1314936.784419] ata2: EH complete
Sep  4 16:20:36 ogw2 kernel: [1314938.760392] ata2.00: configured for UDMA/133
Sep  4 16:20:36 ogw2 kernel: [1314938.768395] ata2.01: configured for UDMA/133
Sep  4 16:20:36 ogw2 kernel: [1314938.768422] sd 1:0:0:0: [sda] Unhandled sense code
Sep  4 16:20:36 ogw2 kernel: [1314938.768426] sd 1:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Sep  4 16:20:36 ogw2 kernel: [1314938.768431] sd 1:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
Sep  4 16:20:36 ogw2 kernel: [1314938.768438] Descriptor sense data with sense descriptors (in hex):
Sep  4 16:20:36 ogw2 kernel: [1314938.768441]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00
Sep  4 16:20:36 ogw2 kernel: [1314938.768454]         01 ac b6 4a
Sep  4 16:20:36 ogw2 kernel: [1314938.768459] sd 1:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
Sep  4 16:20:36 ogw2 kernel: [1314938.768468] sd 1:0:0:0: [sda] CDB: Read(10): 28 00 01 ac b5 f8 00 03 80 00
Sep  4 16:20:36 ogw2 kernel: [1314938.768527] ata2: EH complete
Sep  4 16:20:38 ogw2 kernel: [1314940.788406] ata2.00: configured for UDMA/133
Sep  4 16:20:38 ogw2 kernel: [1314940.796394] ata2.01: configured for UDMA/133
Sep  4 16:20:38 ogw2 kernel: [1314940.796415] ata2: EH complete
Sep  4 16:20:40 ogw2 kernel: [1314942.728391] ata2.00: configured for UDMA/133
Sep  4 16:20:40 ogw2 kernel: [1314942.736395] ata2.01: configured for UDMA/133
Sep  4 16:20:40 ogw2 kernel: [1314942.736413] ata2: EH complete
Sep  4 16:20:42 ogw2 kernel: [1314944.548391] ata2.00: configured for UDMA/133
Sep  4 16:20:42 ogw2 kernel: [1314944.556393] ata2.01: configured for UDMA/133
Sep  4 16:20:42 ogw2 kernel: [1314944.556414] ata2: EH complete
Sep  4 16:20:44 ogw2 kernel: [1314946.372392] ata2.00: configured for UDMA/133
Sep  4 16:20:44 ogw2 kernel: [1314946.380392] ata2.01: configured for UDMA/133
Sep  4 16:20:44 ogw2 kernel: [1314946.380411] ata2: EH complete
Sep  4 16:20:46 ogw2 kernel: [1314948.196391] ata2.00: configured for UDMA/133
Sep  4 16:20:46 ogw2 kernel: [1314948.204391] ata2.01: configured for UDMA/133
Sep  4 16:20:46 ogw2 kernel: [1314948.204411] ata2: EH complete
Sep  4 16:20:48 ogw2 kernel: [1314950.144390] ata2.00: configured for UDMA/133
Sep  4 16:20:48 ogw2 kernel: [1314950.152392] ata2.01: configured for UDMA/133
Sep  4 16:20:48 ogw2 kernel: [1314950.152416] sd 1:0:0:0: [sda] Unhandled sense code
Sep  4 16:20:48 ogw2 kernel: [1314950.152419] sd 1:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Sep  4 16:20:48 ogw2 kernel: [1314950.152424] sd 1:0:0:0: [sda] Sense Key : Medium Error [current] [descriptor]
Sep  4 16:20:48 ogw2 kernel: [1314950.152431] Descriptor sense data with sense descriptors (in hex):
Sep  4 16:20:48 ogw2 kernel: [1314950.152434]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00
Sep  4 16:20:48 ogw2 kernel: [1314950.152447]         01 ac b6 4a
Sep  4 16:20:48 ogw2 kernel: [1314950.152452] sd 1:0:0:0: [sda] Add. Sense: Unrecovered read error - auto reallocate failed
Sep  4 16:20:48 ogw2 kernel: [1314950.152461] sd 1:0:0:0: [sda] CDB: Read(10): 28 00 01 ac b6 48 00 00 08 00
Sep  4 16:20:48 ogw2 kernel: [1314950.152523] ata2: EH complete
Sep  4 16:20:48 ogw2 kernel: [1314950.575325] RAID1 conf printout:
Sep  4 16:20:48 ogw2 kernel: [1314950.575332]  --- wd:1 rd:2
Sep  4 16:20:48 ogw2 kernel: [1314950.575337]  disk 0, wo:1, o:1, dev:sdb3
Sep  4 16:20:48 ogw2 kernel: [1314950.575341]  disk 1, wo:0, o:1, dev:sda3
Sep  4 16:20:48 ogw2 kernel: [1314950.575344] RAID1 conf printout:
Sep  4 16:20:48 ogw2 kernel: [1314950.575347]  --- wd:1 rd:2
Sep  4 16:20:48 ogw2 kernel: [1314950.575350]  disk 1, wo:0, o:1, dev:sda3

Então eu não consigo entender porque este dispositivo (sdb3) se tornou SPARE e o RAID não está sincronizado ...

Alguém pode me apontar o que fazer?

UPDATE: esqueci de dizer que / dev / md3 está montado como partição / (root) e inclui todos os diretórios do sistema, exceto o / boot.

    
por cOnf_ua 04.09.2011 / 15:52

2 respostas

2

Parece que o MD manteve o dispositivo errado. sda está indo mal, um erro de leitura irrecuperável ao ler blocos dele para resync sdb.

Os dados foram alterados em sda depois que o sdb foi removido? Se não, então você pode estar com sorte - o sistema de arquivos em sdb ainda pode estar em um estado consistente, mesmo após a falha de ressincronização; obtenha o MD para montar o array com o sdb.

Isso é um pouco difícil, no entanto; É mais provável que você tenha uma boa chance de ver o desempenho da sua estratégia de backup.

    
por 04.09.2011 / 18:16
2

Observe que TODOS os arrays do MD estão em risco --- não apenas o que é "oficialmente" degradado --- pois todos são baseados em apenas dois dispositivos físicos: sda e sdb . Espero que você tenha backups adequados e / ou procedimentos de recuperação do sistema em vigor, apenas no caso de as coisas ficarem realmente em forma de pêra. Como Shane Madden observou, o log da ressincronização mostra um erro preocupante que pode estar indicando que sda é menor que a própria saúde.

A melhor coisa a fazer é puxar sdb e substituí-lo imediatamente. Se você não tem um substituto à mão, então peça um o mais rápido possível (e talvez use o tempo necessário para fazer um último backup completo de todos os seus arrays enquanto eles ainda estiverem bons!). Sua unidade de substituição precisará ser particionada apropriadamente e, em seguida, as partições serão adicionadas de maneira correspondente a cada uma das suas quatro matrizes. Espero que tudo corra bem e todos os arrays sejam ressincronizados com sucesso.

No entanto, se Shane estiver correto, e outros erros de uma falha sda impedirem a remontagem / ressincronização adequada, a próxima coisa a tentar será puxar sda , substituí-lo pelo antigo sdb (o que pode ainda seja bom), e veja se a combinação do seu antigo sdb e seu novo disco de substituição remontam e ressincronizam com sucesso.

E, finalmente, se nenhuma das opções acima funcionar, a última coisa a tentar (antes de uma reconstrução e restauração completa do sistema) é substituir o (s) controlador (es) da unidade. Eu vi floco-out controladores de unidade e causar problemas para matrizes saudáveis. Uma maneira de testar se um controlador pode ser a causa de erros MD é colocar uma de suas unidades "com falha" em outra máquina com Linux com um controlador em bom estado e as ferramentas mdadm instaladas. Como todos os seus arrays são RAID1, os arrays em qualquer unidade individual devem poder ser montados em um estado utilizável (embora degradado), onde é possível verificar sistemas de arquivos, fazer backups e assim por diante.

    
por 04.09.2011 / 21:48