Faire cela place simplement le lecteur dans le tableau sans rien faire avec, c'est-à-dire qu'il est membre du tableau mais n'y est pas actif. Par défaut, cela le transforme en pièce de rechange :
sudo mdadm /dev/md0 --add /dev/sdb1
Si vous avez une réserve, vous pouvez l'augmenter en forçant le nombre de disques actifs pour la baie à augmenter. Avec 3 disques et 2 prévus actif, vous devrez augmenter le nombre d'actifs à 3.
mdadm --grow /dev/md0 --raid-devices=3
Le pilote de la baie RAID remarquera que vous êtes "en court-circuit" sur un disque, puis cherchera un disque de rechange. En trouvant le disque de rechange, il l'intégrera dans la matrice en tant que lecteur actif. Ouvrez un terminal de rechange et laissez cette ligne de commande plutôt grossière s'y exécuter, pour garder un œil sur la progression de la resynchronisation. Assurez-vous de le saisir sur une seule ligne ou d'utiliser le caractère de saut de ligne (\), et une fois la reconstruction terminée, tapez simplement Ctrl-C dans le terminal.
while true; do sleep 60; clear; sudo mdadm --detail /dev/md0; echo; cat /proc/mdstat; done
Votre matrice aura maintenant deux disques actifs synchronisés, mais comme il n'y a pas 3 disques, elle ne sera pas propre à 100 %. Retirez le disque défaillant, puis redimensionnez la matrice. Notez que le --grow flag est un peu impropre - cela peut signifier soit grandir ou rétrécir :
sudo mdadm /dev/md0 --fail /dev/{failed drive}
sudo mdadm /dev/md0 --remove /dev/{failed drive}
sudo mdadm --grow /dev/md0 --raid-devices=2
En ce qui concerne les erreurs, un problème de liaison avec le lecteur (c'est-à-dire le port PATA/SATA, le câble ou le connecteur du lecteur) n'est pas suffisant pour déclencher un basculement d'un disque de secours, car le noyau bascule généralement vers l'utilisation de l'autre "bon" lecteur pendant qu'il réinitialise le lien vers le "mauvais" lecteur. Je le sais parce que j'exécute une baie de 3 disques, 2 chauds, 1 de rechange, et l'un des disques a récemment décidé de vomir un peu dans les journaux. Lorsque j'ai testé tous les disques de la baie, tous les 3 ont réussi la version "longue" du test SMART, donc ce n'est pas un problème avec les plateaux, les composants mécaniques ou le contrôleur intégré - qui laisse un câble de liaison floconneux ou un mauvais port SATA. C'est peut-être ce que vous voyez. Essayez de basculer le lecteur sur un autre port de la carte mère ou d'utiliser un autre câble, et voyez si cela s'améliore.
Un suivi :j'ai terminé mon extension du miroir à 3 disques, j'ai échoué et j'ai retiré le disque feuilleté de la matrice md, j'ai remplacé à chaud le câble par un nouveau (la carte mère le prend en charge) et j'ai rajouté le disque. Lors du rajout, il a immédiatement lancé une resynchronisation du lecteur. Jusqu'à présent, pas une seule erreur n'est apparue dans le journal malgré le lecteur étant fortement utilisé. Donc, oui, les câbles de lecteur peuvent devenir floconneux.
J'ai eu exactement le même problème et, dans mon cas, j'ai découvert que le disque RAID actif souffrait d'erreurs de lecture lors de la synchronisation. Par conséquent, le nouveau disque a été synchronisé avec succès et a donc été marqué comme disque de secours.
Vous voudrez peut-être vérifier votre /var/log/messages et d'autres journaux système pour les erreurs. De plus, il peut également être judicieux de vérifier l'état SMART de votre disque :
1) Lancez le petit test :
"smartctl -t court /dev/sda"
2) Affichez les résultats du test :
"smartctl -l autotest /dev/sda"
Dans mon cas, cela a renvoyé quelque chose comme ceci :
===DÉBUT DE LA SECTION LIRE LES DONNÉES INTELLIGENTES ===
Numéro de révision de la structure du journal d'autotest SMART 1
Num Test_Description Statut Durée de vie restante (heures) LBA_of_first_error
1 Hors ligne étendue Terminé :échec de lecture 90 % 7564 27134728
2 Court déconnecté Terminé :échec de lecture 90 % 7467 1408449701
J'ai dû démarrer une distribution en direct et copier manuellement les données du disque défectueux vers le nouveau (actuellement "de réserve").
J'ai eu exactement le même problème et j'ai toujours pensé que mon deuxième disque, que je voulais rajouter à la matrice, avait des erreurs. Mais c'était mon disque d'origine avait des erreurs de lecture.
Vous pouvez le vérifier avec smartctl -t short /dev/sdX et voir les résultats quelques minutes plus tard avec smartctl -l selftest /dev/sdX . Pour moi, cela ressemblait à ceci :
=== 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
J'ai essayé de les réparer avec ce manuel. C'était amusant :-). Je sais que vous avez vérifié les erreurs sur les deux disques, mais je pense que votre problème est que le disque qui est toujours dans le tableau md a des erreurs de lecture, donc l'ajout d'un deuxième disque échoue.
Mettre à jour
Vous devez en plus exécuter un smartctl -a /dev/sdX Si vous voyez Current_Pending_Sector> 0, quelque chose ne va pas
197 Current_Pending_Sector 0x0012 098 098 000 Old_age Toujours - 69
Pour moi, c'était définitivement le problème que j'ai retiré un disque du raid juste pour les tests et la resynchronisation n'a pas pu être effectuée en raison d'échecs de lecture. La synchronisation a été interrompue à mi-chemin. Lorsque j'ai vérifié mon disque qui était toujours dans le tableau RAID, smartctl a signalé des problèmes.
J'ai pu les corriger avec le manuel ci-dessus et j'ai vu le nombre de secteurs en attente réduit. Mais il y en avait trop et c'est une procédure longue et ennuyeuse donc j'ai utilisé ma sauvegarde et restauré les données sur un autre serveur.
Comme vous n'avez pas eu l'occasion d'utiliser SMART, je suppose que votre auto-test n'a pas révélé ces secteurs défectueux.
Pour moi, c'est une leçon apprise :vérifiez vos disques avant d'en supprimer un de votre baie.