Configuração de RAID1 de hardware - Possivelmente, setores com falha em um disco físico. O sistema operacional lê automaticamente do outro disco?

Question

Eu não sou um administrador de sistemas profissional, mas como não consegui encontrar respostas para o meu caso específico depois de pesquisar por um tempo, esperava poder obter alguma ajuda aqui. Nosso servidor usa o P222 - uma matriz de controlador HP Smart na configuração RAID1. Eu acredito que alguns setores em um dos discos rígidos físicos falharam. Eu usei a ferramenta hpacucli e a saída se parecia com: -

 $ hpacucli ctrl all show config 

 Smart Array P222 in Slot 1                (sn: PDSXH0ARH5I0SW)

 array A (SATA, Unused Space: 0  MB)


  logicaldrive 1 (2.7 TB, RAID 1, Ready for Rebuild)

  physicaldrive 2I:1:1 (port 2I:box 1:bay 1, SATA, 3 TB, OK)
  physicaldrive 2I:1:2 (port 2I:box 1:bay 2, SATA, 3 TB, Predictive Failure)

Eu executei a mesma ferramenta novamente algumas vezes para verificar o status e em um momento notei que "Falha Preditiva" foi substituída por "Reconstruindo 1%", aumentada para 2%. Eu não acho que fiz nada para iniciar a reconstrução. De qualquer forma, deixei-o correr e verifiquei o status depois de um tempo, no ponto em que estava de volta a "Falha Preditiva".

Na execução de testes longos e curtos do smartctl - os registros de autoteste relatados: -

=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed: read failure       90%     14368         334201968
# 2  Short offline       Completed: read failure       90%     14367         625082211

Estamos executando uma instância do MySQL neste servidor e ela continua falhando ao reclamar de um erro de leitura que indicou que pode ser devido a um disco rígido com falha / um setor defeituoso, portanto, as ferramentas usadas acima. Eu tive algumas perguntas: -

1. Eu não sei ao certo, mas parece que um dos discos rígidos está falhando em parte. Nesse caso, o SO (Ubuntu 12.04) não deveria apenas ler os dados do disco rígido espelhado? (o que significaria que o MySQL deveria continuar rodando)
2. Eu estava seguindo as etapas do link . O LBA 334201968 (LBA do longo teste de falha de leitura) corresponde ao arquivo de dados do MySQL. Mas eu não queria sobrescrever qualquer parte deste arquivo, pois não tenho certeza se o MySQL irá ver o arquivo permanentemente como corrompido. Qual seria a minha melhor opção para 'consertar' as partes corrompidas do disco?

Prazer em informar quaisquer detalhes adicionais que possam ser necessários para diagnosticar / corrigir isso

EDIT 1: Conforme solicitado, os logs de erro do MySQL assim: -

150824 10:27:00 InnoDB: Completed initialization of buffer pool
150824 10:27:00 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
150824 10:27:00  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
150824 10:27:00  InnoDB: Waiting for the background threads to start
150824 10:27:01 InnoDB: 5.5.35 started; log sequence number 2723867081864
150824 10:27:01 [Note] Server hostname (bind-address): <ip and port here>;
150824 10:27:01 [Note]   - <ip here> resolves to <ip here>;
150824 10:27:01 [Note] Server socket created on IP: <ip here>.
InnoDB: Error: tried to read 16384 bytes at offset 70 1898921984.
InnoDB: Was only able to read -1.
150824 10:27:01  InnoDB: Operating system error number 5 in a file operation.
InnoDB: Error number 5 means 'Input/output error'.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/operating-system-error-codes.html
InnoDB: File operation call: 'read'.
InnoDB: Cannot continue operation.

EDIT 2: com base no comentário link , abri um ticket para substituir o disco e substituí-lo e reconstruir o RAID . A saída do hpacucli se parece com: -

  physicaldrive 2I:1:1 (port 2I:box 1:bay 1, SATA, 3 TB, OK)
  physicaldrive 2I:1:2 (port 2I:box 1:bay 2, SATA, 3 TB, OK)

Portanto, a Falha Preditiva desapareceu. No entanto, o MySQL continuava me dando erros de leitura, então fiz o teste longctl long e short novamente. Enquanto o teste curto passou, o longo falhou com um erro de leitura: -

Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed: read failure       90%     14393         625116232
# 2  Short offline       Completed without error       00%     14392         -

Eu também verifiquei o syslog e notei que toda vez que o MySQL tenta iniciar, existe esse erro no syslog

Aug 25 14:23:41 kernel: [ 1603.911185] sd 6:0:0:1: [sda] Unhandled sense code
Aug 25 14:23:41 kernel: [ 1603.911186] sd 6:0:0:1: [sda]  Result: hostbyte=invalid driverbyte=DRIVER_SENSE
Aug 25 14:23:41 kernel: [ 1603.911188] sd 6:0:0:1: [sda]  Sense Key : Medium Error [current] 
Aug 25 14:23:41 kernel: [ 1603.911190] sd 6:0:0:1: [sda]  Add. Sense: Unrecovered read error
Aug 25 14:23:41 kernel: [ 1603.911192] sd 6:0:0:1: [sda] CDB: Read(10): 28 00 46 a2 d5 a0 00 00 08 00

O que isso indica? (parece ser um setor ruim no disco?) Se for esse o caso, existe uma maneira de corrigir isso?

    

Answer 1

Ok. Esta é uma pergunta longa, mas terá uma resposta curta:

Se você vir "Falha preditiva" ou "Falha", substitua o disco.

Ambas as condições são válidas para o propósito de estabelecer um tíquete de suporte e / ou substituição de peças de garantia da HP.

"Predictive Failure" incorpora S.M.A.R.T. dados, bem como outras heurísticas para determinar a integridade da unidade. Mas os detalhes não devem importar. Planeje a substituição da unidade.

O fato de você estar vendo um impacto no nível do aplicativo é outro sinal de que o curso correto da ação é substituir o disco. É fácil de fazer ... mesmo que seja uma unidade SATA, é uma parte da HP, então ela tem uma garantia (provavelmente 1 ano, mas está ligada ao número de série do seu servidor) .

Ligue para a HP ...

    

Answer 2

1. Sim, se uma unidade em RAID falhar, o controlador RAID a marcará como falha e será lida com outro HDD saudável.
2. Falha de previsão significa que o disco ainda funciona, mas você percebe que, em breve, ele falhará. Se você receber um erro de leitura, no seu teste, você deve substituir sua unidade por outra. Basta comprar unidade sobressalente em seu suporte de loja / fornecedor local, instalá-lo e o controlador RAID reconstruirá o array para um status saudável.

Answer 3

Você está usando discos rígidos da HP? Ou drives normais de consumo? As unidades têm Recuperação de Erro Limite de Tempo?

Se não, a unidade pode bloquear o controlador enquanto ele tenta ler um setor defeituoso. Levará um longo tempo para a unidade desistir, portanto, a leitura falhará. O controlador RAID não tem a chance de tentar a outra unidade porque está preso esperando a primeira unidade decidir que falhou.

Esse comportamento também faz com que as unidades caiam temporariamente da invasão, o que explicaria a reconstrução.

Isso só deve ser aplicado se você estiver usando unidades que não sejam da HP - as unidades suportadas estão programadas para desistir rapidamente e permitir que o controlador de ataque lide com o erro.