Comment obtenir un périphérique RAID inactif fonctionnant à nouveau?

Pour votre question bonus:

 mdadm --examine --scan >> /etc/mdadm/mdadm.conf 

J'ai trouvé que je dois ajouter le tableau manuellement dans /etc/mdadm/mdadm.conf afin de faire monter Linux lors du redémarrage. Sinon, j'ai exactement ce que vous avez ici – md_d1 – les md_d1 inactifs, etc.

Le conf-file devrait ressembler ci-dessous – c'est-à-dire une ligne ARRAY pour chaque périphérique md. Dans mon cas, les nouveaux tableaux manquaient dans ce fichier, mais si vous les avez listés, cela n'est probablement pas une solution à votre problème.

 # definitions of existing MD arrays ARRAY /dev/md0 level=raid5 num-devices=3 UUID=f10f5f96:106599e0:a2f56e56:f5d3ad6d ARRAY /dev/md1 level=raid1 num-devices=2 UUID=aa591bbe:bbbec94d:a2f56e56:f5d3ad6d 

Ajoutez un tableau par périphérique md, et ajoutez-les après le commentaire inclus ci-dessus, ou si aucun commentaire n'existe, à la fin du fichier. Vous obtenez les UUID en faisant sudo mdadm -E --scan :

 $ sudo mdadm -E --scan ARRAY /dev/md0 level=raid5 num-devices=3 UUID=f10f5f96:106599e0:a2f56e56:f5d3ad6d ARRAY /dev/md1 level=raid1 num-devices=2 UUID=aa591bbe:bbbec94d:a2f56e56:f5d3ad6d 

Comme vous pouvez le voir, vous pouvez simplement copier la sortie du résultat d'analyse dans le fichier.

Je lance ubuntu desktop 10.04 LTS, et pour autant que je m'en souvienne, ce comportement diffère de la version du serveur d'Ubuntu, mais il y a longtemps que j'ai créé mes périphériques md sur le serveur, je me trompe peut-être. C'est peut-être aussi que j'ai raté une certaine option.

Quoi qu'il en soit, ajouter le tableau dans le conf-file semble faire l'affaire. J'ai parcouru le raid 1 et le raid ci-dessus 5 pendant des années sans problème.

Avertissement: Tout d'abord, permettez-moi de dire que ce qui suit (en raison de l'utilisation de «force») semble dangereux pour moi, et si vous avez des données irrécupérables, je recommande de faire des copies des partitions impliquées avant de commencer à essayer n'importe lequel Les choses ci-dessous. Cependant, cela a fonctionné pour moi.

J'ai eu le même problème, avec un tableau apparaissant inactif, et rien que j'ai inclus, y compris le "mdadm –examine –scan> /etc/mdadm.conf", comme cela a été suggéré par d'autres, aidé du tout.

Dans mon cas, quand il a essayé de démarrer le tableau RAID-5 après un remplacement de lecteur, il disait qu'il était sale (via dmesg ):

 md/raid:md2: not clean -- starting background reconstruction md/raid:md2: device sda4 operational as raid disk 0 md/raid:md2: device sdd4 operational as raid disk 3 md/raid:md2: device sdc4 operational as raid disk 2 md/raid:md2: device sde4 operational as raid disk 4 md/raid:md2: allocated 5334kB md/raid:md2: cannot start dirty degraded array. 

Cautant qu'il apparaisse comme inactif dans /proc/mdstat :

 md2 : inactive sda4[0] sdd4[3] sdc4[2] sde4[5] 3888504544 blocks super 1.2 

J'ai trouvé que tous les appareils avaient les mêmes événements sur eux, à l'exception du lecteur que j'avais remplacé ( /dev/sdb4 ):

 [root@nfs1 sr]# mdadm -E /dev/sd*4 | grep Event mdadm: No md superblock detected on /dev/sdb4. Events : 8448 Events : 8448 Events : 8448 Events : 8448 

Cependant, les détails du tableau ont montré qu'il disposait de 4 appareils sur 5:

 [root@nfs1 sr]# mdadm --detail /dev/md2 /dev/md2: [...] Raid Devices : 5 Total Devices : 4 [...] Active Devices : 4 Working Devices : 4 [...] Number Major Minor RaidDevice State 0 8 4 0 inactive dirty /dev/sda4 2 8 36 2 inactive dirty /dev/sdc4 3 8 52 3 inactive dirty /dev/sdd4 5 8 68 4 inactive dirty /dev/sde4 

(Ce qui précède est de la mémoire sur la colonne "Etat", je ne peux pas le trouver dans mon tampon scroll-back).

J'ai réussi à résoudre ce problème en arrêtant le tableau puis en le réassemblant:

 mdadm --stop /dev/md2 mdadm -A --force /dev/md2 /dev/sd[acde]4 

À ce moment-là, le tableau était en cours, fonctionnant avec 4 des 5 appareils, et j'ai pu ajouter le périphérique de remplacement et il est en train de reconstruire. Je peux accéder au système de fichiers sans problème.

J'avais des problèmes avec Ubuntu 10.04 où une erreur dans FStab empêchait le serveur de démarrer.

J'ai exécuté cette commande comme mentionné dans les solutions ci-dessus:

 mdadm --examine --scan >> /etc/mdadm/mdadm.conf 

Cela ajoutera les résultats de "mdadm –examine –scan" à "/etc/mdadm/mdadm.conf"

Dans mon cas, c'était:

 ARRAY /dev/md/0 metadata=1.2 UUID=2660925e:6d2c43a7:4b95519e:b6d110e7 name=localhost:0 

Ceci est un fakeraid 0. Ma commande dans / etc / fstab pour le montage automatique est:

 /dev/md0 /home/shared/BigDrive ext3 defaults,nobootwait,nofail 0 0 

L'important ici est que vous avez "nobootwait" et "nofail". Nobootwait sautera les messages système qui vous empêchent de démarrer. Dans mon cas, c'était sur un serveur distant, donc c'était essentiel.

J'espère que cela aidera certaines personnes.

Vous pouvez activer votre appareil md avec

 mdadm -A /dev/md_d0 

Je suppose qu'un script de démarrage commence trop tôt, avant que l'un des membres RAID ne soit découvert ou un problème similaire. En tant que solution de contournement rapide et sale, vous devriez pouvoir ajouter cette ligne à /etc/rc.local:

 mdadm -A /dev/md_d0 && mount /dev/md_d0 

Modifier: apparemment votre /etc/mdadm/mdadm.conf contient toujours l'ancien nom de configuration. Modifiez ce fichier et remplacez les occurrences de md0 par md_d0.

J'ai eu un problème similaire … mon serveur ne monterait pas md2 après avoir développé les partitions de périphériques associés. En lisant ce thread, j'ai constaté que le périphérique RAID md2 avait un nouvel UUID et la machine essayait d'utiliser l'ancien.

Comme suggéré … en utilisant la sortie 'md2' de

 mdadm --examine --scan 

J'ai édité /etc/mdadm/mdadm.conf et remplacé l'ancienne ligne UUID par la sortie issue de la commande ci-dessus et mon problème s'est éloigné.

Lorsque vous prétendez faire quelque chose avec /dev/md[012346789} cela va à /dev/md{126,127...} . /dev/md0 continue à être monté sur /dev/md126 ou /dev/md127 vous devez:

Umount /dev/md127 ou umount /dev/md126 .

Ceci est temporaire pour vous permettre d'exécuter des commandes et des applications sans arrêter votre système.

Un moyen simple d'exécuter le tableau en supposant qu'il n'y ait pas de problème de matériel et que vous avez suffisamment de lecteurs / partitions pour démarrer le tableau est le suivant:

 md20 : inactive sdf1[2](S) 732442488 blocks super 1.2 sudo mdadm --manage /dev/md20 --run 

Il se pourrait que, pour quelque raison que ce soit, le tableau est bien mais quelque chose l'a empêché de démarrer ou de construire. Dans mon cas, c'est parce que mdadm ne savait pas que le nom du tableau original était md127 et que tous les lecteurs étaient débranchés pour ce tableau. Lors de la recharge, je devais monter manuellement (probablement un bug où mdadm pensait que le tableau était déjà actif en raison de l'ancien nom de réseau hors ligne).

md_d0 : inactive sda4[0](S) semble erroné pour un tableau RAID1. Il semble suggérer que le tableau n'a pas de périphériques actifs et un périphérique de rechange ^{_{(indiqué par le (S), vous}} verriez ^{_{(F) un périphérique défectueux et rien pour un périphérique OK / actif)}} – pour un réseau RAID1 qui n'est pas En cas de détérioration, il devrait y avoir au moins deux dispositifs OK / actifs ^{_{(et pour un réseau dégradé, au moins un périphérique OK / actif)}} et vous ne pouvez pas activer un réseau RAID1 sans aucun périphérique échoué (comme pièces détachées Ne contiennent pas une copie des données jusqu'à ce qu'elles soient activées lorsqu'un autre disque échoue). Si je lis cette sortie /proc/mdstat à droite, vous ne pourrez pas activer le tableau dans son état actuel.

Avez-vous des disques physiques dans la machine qui n'ont pas réussi à tourner? Est-ce que ls /dev/sd* tous les lecteurs et les partitions que vous attendez normalement de voir sur cette machine?