Este é um problema fundamental com o RAID5 - blocos ruins na reconstrução são um assassino.
Oct 2 15:08:51 it kernel: [1686185.573233] md/raid:md0: device xvdc operational as raid disk 0
Oct 2 15:08:51 it kernel: [1686185.580020] md/raid:md0: device xvde operational as raid disk 2
Oct 2 15:08:51 it kernel: [1686185.588307] md/raid:md0: device xvdd operational as raid disk 1
Oct 2 15:08:51 it kernel: [1686185.595745] md/raid:md0: allocated 4312kB
Oct 2 15:08:51 it kernel: [1686185.600729] md/raid:md0: raid level 5 active with 3 out of 4 devices, algorithm 2
Oct 2 15:08:51 it kernel: [1686185.608928] md0: detected capacity change from 0 to 2705221484544
⋮
O array foi montado, degradado. Foi montado com xvdc, xvde e xvdd. Aparentemente, há um hot spare:
Oct 2 15:08:51 it kernel: [1686185.615772] md: recovery of RAID array md0
Oct 2 15:08:51 it kernel: [1686185.621150] md: minimum _guaranteed_ speed: 1000 KB/sec/disk.
Oct 2 15:08:51 it kernel: [1686185.627626] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for recovery.
Oct 2 15:08:51 it kernel: [1686185.634024] md0: unknown partition table
Oct 2 15:08:51 it kernel: [1686185.645882] md: using 128k window, over a total of 880605952k.
A mensagem "tabela de partições" não está relacionada. As outras mensagens estão dizendo que o md está tentando fazer uma recuperação, provavelmente em um hot spare (que pode ser o dispositivo que falhou antes, se você tentou removê-lo / adicioná-lo novamente).
⋮
Oct 2 15:24:19 it kernel: [1687112.817845] end_request: I/O error, dev xvde, sector 881423360
Oct 2 15:24:19 it kernel: [1687112.820517] raid5_end_read_request: 1 callbacks suppressed
Oct 2 15:24:19 it kernel: [1687112.821837] md/raid:md0: read error not correctable (sector 881423360 on xvde).
Oct 2 15:24:19 it kernel: [1687112.821837] md/raid:md0: Disk failure on xvde, disabling device.
Oct 2 15:24:19 it kernel: [1687112.821837] md/raid:md0: Operation continuing on 2 devices.
E isso aqui é md tentando ler um setor de xvde (um dos três dispositivos restantes). Isso falha [setor ruim, provavelmente], e md (desde que a matriz é degradada) não pode se recuperar. Assim, o disco sai do array e, com uma falha de disco duplo, o RAID5 está morto.
Não sei por que ele está sendo rotulado como sobressalente - isso é estranho (embora eu normalmente veja o /proc/mdstat , então talvez seja assim que o mdadm rotula isso). Além disso, eu pensei que os kernels mais novos estivessem muito mais hesitantes em chutar por bloqueios ruins - mas talvez você esteja executando algo mais antigo?
O que você pode fazer sobre isso?
bons backups. Essa é sempre uma parte importante de qualquer estratégia para manter os dados vivos.
Certifique-se de que o array seja removido por blocos ruins rotineiramente. Seu sistema operacional já pode incluir uma tarefa cron para isso. Você faz isso exibindo repair ou check to /sys/block/md0/md/sync_action . "Reparar" também consertará todos os erros de paridade descobertos (por exemplo, o bit de paridade não corresponde aos dados nos discos).
# echo repair > /sys/block/md0/md/sync_action
#
O andamento pode ser observado com cat /proc/mdstat ou os vários arquivos nesse diretório sysfs. (Você pode encontrar documentação um pouco atualizada no artigo do Linux Raid Wiki mdstat .
NOTA: Nos kernels mais antigos - não tenho certeza da versão exata - a verificação pode não corrigir os blocos ruins.
Uma opção final é mudar para o RAID6. Isso exigirá outro disco (você pode executar um RAID6 de quatro ou até três discos, você provavelmente não deseja). Com novos kernels suficientes, os blocos defeituosos são corrigidos quando possível. O RAID6 pode sobreviver a duas falhas de disco, portanto, quando um disco falha, ele ainda pode sobreviver a um bloco defeituoso - e, portanto, mapeará o bloco defeituoso e continuará a reconstrução.