In questo modo si inserisce semplicemente l'unità nell'array senza effettivamente fare nulla con essa, ovvero è un membro dell'array ma non è attiva in esso. Per impostazione predefinita, questo lo trasforma in un ricambio:
sudo mdadm /dev/md0 --add /dev/sdb1
Se si dispone di un'unità di riserva, è possibile aumentarla forzando la crescita del numero di unità attive per l'array. Con 3 unità e 2 previste attivo, dovresti aumentare il conteggio attivo a 3.
mdadm --grow /dev/md0 --raid-devices=3
Il driver dell'array raid noterà che sei "a corto" di un'unità, quindi cercherà un'unità di riserva. Trovando il ricambio, lo integrerà nell'array come unità attiva. Apri un terminale di riserva e lascia che questa riga di comando piuttosto grezza venga eseguita al suo interno, per tenere sotto controllo l'avanzamento della risincronizzazione. Assicurati di digitarlo come un'unica riga o usa il carattere di interruzione di riga (\) e, una volta terminata la ricostruzione, digita semplicemente Ctrl-C nel terminale.
while true; do sleep 60; clear; sudo mdadm --detail /dev/md0; echo; cat /proc/mdstat; done
Il tuo array ora avrà due unità attive sincronizzate, ma poiché non ci sono 3 unità, non sarà pulito al 100%. Rimuovere l'unità guasta, quindi ridimensionare l'array. Nota che il file --grow flag è un termine un po' improprio:può significare uno dei due crescere o restringersi:
sudo mdadm /dev/md0 --fail /dev/{failed drive}
sudo mdadm /dev/md0 --remove /dev/{failed drive}
sudo mdadm --grow /dev/md0 --raid-devices=2
Per quanto riguarda gli errori, un problema di collegamento con l'unità (ovvero la porta PATA/SATA, il cavo o il connettore dell'unità) non è sufficiente per attivare un failover di un hot spare, poiché il kernel in genere passerà all'utilizzo dell'altro "buono" drive mentre reimposta il collegamento all'unità "cattiva". Lo so perché eseguo un array di 3 unità, 2 calde, 1 di riserva e una delle unità ha recentemente deciso di vomitare un po 'nei registri. Quando ho testato tutte le unità dell'array, tutte e 3 hanno superato la versione "lunga" del test SMART, quindi non è un problema con i piatti, i componenti meccanici o il controller integrato, che lascia un cavo di collegamento instabile o un cattiva porta SATA. Forse questo è ciò che stai vedendo. Prova a collegare l'unità a una porta della scheda madre diversa o a utilizzare un cavo diverso e verifica se migliora.
Un follow-up:ho completato la mia espansione del mirror a 3 unità, non è riuscito e ho rimosso l'unità traballante dall'array md, ho sostituito a caldo il cavo con uno nuovo (la scheda madre lo supporta) e ho aggiunto nuovamente l'unità. Al momento della nuova aggiunta, ha immediatamente avviato una risincronizzazione dell'unità. Finora, non è apparso un singolo errore nel registro nonostante l'unità sia molto utilizzata. Quindi, sì, i cavi delle unità possono rompersi.
Ho avuto esattamente lo stesso problema e nel mio caso ho scoperto che il disco raid attivo soffriva di errori di lettura durante la sincronizzazione. Pertanto, il nuovo disco è stato sincronizzato con successo e quindi è stato mantenuto contrassegnato come di riserva.
Potresti voler controllare il tuo /var/log/messages e altri registri di sistema per errori. Inoltre, potrebbe anche essere una buona idea controllare lo stato SMART del tuo disco:
1) Esegui il breve test:
"smartctl -t short /dev/sda"
2) Visualizza i risultati del test:
"smartctl -l selftest /dev/sda"
Nel mio caso questo ha restituito qualcosa del genere:
===INIZIO LETTURA SEZIONE SMART DATA ===
Numero di revisione della struttura del registro dell'autotest SMART 1
Num Test_Description Stato Durata residua (ore) LBA_of_first_error
1 Offline esteso Completato:errore di lettura 90% 7564 27134728
2 Breve offline Completato:errore di lettura 90% 7467 1408449701
Ho dovuto avviare una distribuzione live e copiare manualmente i dati dal disco difettoso a quello nuovo (attualmente "di riserva").
Ho avuto esattamente lo stesso problema e ho sempre pensato che il mio secondo disco, che volevo aggiungere nuovamente all'array, avesse degli errori. Ma era il mio disco originale che aveva letto errori.
Puoi verificarlo con smartctl -t short /dev/sdX e vedere i risultati pochi minuti dopo con smartctl -l selftest /dev/sdX . Per me sembrava così:
=== 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 Short offline Completed: read failure 20% 25151 734566647
Ho provato a risolverli con questo manuale. È stato divertente :-). So che hai verificato la presenza di errori su entrambi i dischi, ma penso che il tuo problema sia che il disco che è ancora nell'array md ha errori di lettura, quindi l'aggiunta di un secondo disco non riesce.
Aggiorna
Dovresti inoltre eseguire un smartctl -a /dev/sdX Se vedi Current_Pending_Sector> 0 qualcosa non va
197 Current_Pending_Sector 0x0012 098 098 000 Old_age Sempre - 69
Per me è stato sicuramente il problema che ho rimosso un disco dal raid solo per i test e la risincronizzazione non poteva essere eseguita a causa di errori di lettura. La sincronizzazione è stata interrotta a metà. Quando ho controllato il mio disco che era ancora nell'array raid, smartctl ha segnalato problemi.
Potrei risolverli con il manuale sopra e ho visto ridurre il numero di settori in sospeso. Ma ce n'erano molti ed è una procedura lunga e noiosa, quindi ho utilizzato il mio backup e ripristinato i dati su un server diverso.
Dato che non hai avuto l'opportunità di utilizzare SMART, immagino che il tuo autotest non abbia mostrato quei settori rotti.
Per me è una lezione imparata:controlla i tuoi dischi prima di rimuoverne uno dal tuo array.