2013-06-04 08:15:37 +0000 2013-06-04 08:15:37 +0000
22
22

Wie reaktiviere ich meinen MDADM RAID5-Verbund?

Ich bin gerade umgezogen und habe dabei meinen Server abgebaut und neu angeschlossen. Seitdem erscheint eines meiner MDADM-RAID5-Arrays als inaktiv:

root@mserver:/tmp# cat /proc/mdstat 
Personalities : [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid1] [raid10] 
md1 : active raid5 sdc1[1] sdh1[2] sdg1[0]
      3907023872 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]

md0 : inactive sdd1[0](S) sdf1[3](S) sde1[2](S) sdb1[1](S)
      3907039744 blocks

unused devices: <none>

Es sieht für mich so aus, als ob es alle Festplatten gefunden hat, aber aus irgendeinem Grund nicht benutzen will.

Was bedeuten die (S)-Bezeichnungen und wie kann ich MDADM anweisen, das Array wieder zu verwenden?

[Bearbeiten] Ich habe gerade versucht, das Array mit -v anzuhalten und wieder zusammenzusetzen:

root@mserver:~# mdadm --stop /dev/md0
mdadm: stopped /dev/md0

root@mserver:~# mdadm --assemble --scan -v
mdadm: /dev/sde1 is identified as a member of /dev/md0, slot 2.
mdadm: /dev/sdf1 is identified as a member of /dev/md0, slot 3.
mdadm: /dev/sdd1 is identified as a member of /dev/md0, slot 0.
mdadm: /dev/sdb1 is identified as a member of /dev/md0, slot 1.
mdadm: added /dev/sdd1 to /dev/md0 as 0 (possibly out of date)
mdadm: added /dev/sdb1 to /dev/md0 as 1 (possibly out of date)
mdadm: added /dev/sdf1 to /dev/md0 as 3 (possibly out of date)
mdadm: added /dev/sde1 to /dev/md0 as 2
mdadm: /dev/md0 assembled from 1 drive - not enough to start the array.

..und die Eingabe von cat /proc/mdstat sieht nicht anders aus.

[Bearbeiten2] Ich bin mir nicht sicher, ob es hilft, aber dies ist das Ergebnis der Untersuchung der einzelnen Platten:

root@mserver:~# mdadm –examine /dev/sdb1

/dev/sdb1:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : 2f331560:fc85feff:5457a8c1:6e047c67 (local to host mserver)
  Creation Time : Sun Feb 1 20:53:39 2009
     Raid Level : raid5
  Used Dev Size : 976759936 (931.51 GiB 1000.20 GB)
     Array Size : 2930279808 (2794.53 GiB 3000.61 GB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 0

    Update Time : Sat Apr 20 13:22:27 2013
          State : clean
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0
       Checksum : 6c8f71a3 - correct
         Events : 955190

         Layout : left-symmetric
     Chunk Size : 64K

      Number Major Minor RaidDevice State
this 1 8 17 1 active sync /dev/sdb1

   0 0 8 113 0 active sync /dev/sdh1
   1 1 8 17 1 active sync /dev/sdb1
   2 2 8 97 2 active sync /dev/sdg1
   3 3 8 33 3 active sync /dev/sdc1

root@mserver:~# mdadm –examine /dev/sdd1

/dev/sdd1:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : 2f331560:fc85feff:5457a8c1:6e047c67 (local to host mserver)
  Creation Time : Sun Feb 1 20:53:39 2009
     Raid Level : raid5
  Used Dev Size : 976759936 (931.51 GiB 1000.20 GB)
     Array Size : 2930279808 (2794.53 GiB 3000.61 GB)
   Raid Devices : 4
  Total Devices : 2
Preferred Minor : 0

    Update Time : Sat Apr 20 18:37:23 2013
          State : active
 Active Devices : 2
Working Devices : 2
 Failed Devices : 2
  Spare Devices : 0
       Checksum : 6c812869 - correct
         Events : 955205

         Layout : left-symmetric
     Chunk Size : 64K

      Number Major Minor RaidDevice State
this 0 8 113 0 active sync /dev/sdh1

   0 0 8 113 0 active sync /dev/sdh1
   1 1 0 0 1 faulty removed
   2 2 8 97 2 active sync /dev/sdg1
   3 3 0 0 3 faulty removed

root@mserver: ~# mdadm –examine /dev/sde1

/dev/sde1:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : 2f331560:fc85feff:5457a8c1:6e047c67 (local to host mserver)
  Creation Time : Sun Feb 1 20:53:39 2009
     Raid Level : raid5
  Used Dev Size : 976759936 (931.51 GiB 1000.20 GB)
     Array Size : 2930279808 (2794.53 GiB 3000.61 GB)
   Raid Devices : 4
  Total Devices : 2
Preferred Minor : 0

    Update Time : Sun Apr 21 14:00:43 2013
          State : clean
 Active Devices : 1
Working Devices : 1
 Failed Devices : 2
  Spare Devices : 0
       Checksum : 6c90cc70 - correct
         Events : 955219

         Layout : left-symmetric
     Chunk Size : 64K

      Number Major Minor RaidDevice State
this 2 8 97 2 active sync /dev/sdg1

   0 0 0 0 0 removed
   1 1 0 0 1 faulty removed
   2 2 8 97 2 active sync /dev/sdg1
   3 3 0 0 3 faulty removed

root@mserver:~# mdadm –examine /dev/sdf1

/dev/sdf1:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : 2f331560:fc85feff:5457a8c1:6e047c67 (local to host mserver)
  Creation Time : Sun Feb 1 20:53:39 2009
     Raid Level : raid5
  Used Dev Size : 976759936 (931.51 GiB 1000.20 GB)
     Array Size : 2930279808 (2794.53 GiB 3000.61 GB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 0

    Update Time : Sat Apr 20 13:22:27 2013
          State : clean
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0
       Checksum : 6c8f71b7 - correct
         Events : 955190

         Layout : left-symmetric
     Chunk Size : 64K

      Number Major Minor RaidDevice State
this 3 8 33 3 active sync /dev/sdc1

   0 0 8 113 0 active sync /dev/sdh1
   1 1 8 17 1 active sync /dev/sdb1
   2 2 8 97 2 active sync /dev/sdg1
   3 3 8 33 3 active sync /dev/sdc1

Ich habe einige Notizen, die darauf hindeuten, dass die Laufwerke ursprünglich wie folgt zusammengesetzt waren:

md0 : active raid5 sdb1[1] sdc1[3] sdh1[0] sdg1[2]
      2930279808 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]

[Edit3]

Wenn ich mir das Protokoll ansehe, sieht es so aus, als wäre folgendes passiert (basierend auf dem Update Time in den --examine-Ergebnissen):

  1. sdb und sdf wurden irgendwann nach 13:22 am 20. ausgeschaltet
  2. sdd wurde irgendwann nach 18:37 am 20. ausgeschaltet
  3. der Server wurde irgendwann nach 14:00 Uhr am 1.

heruntergefahren. Angesichts der Tatsache, dass zwei Platten (anscheinend) gleichzeitig ausgefallen sind, denke ich, dass es einigermaßen sicher sein sollte, anzunehmen, dass das Array nach diesem Zeitpunkt nicht mehr beschrieben wurde(?) und es daher relativ sicher sein sollte, die Wiederherstellung in der richtigen Reihenfolge zu erzwingen? Was ist der sicherste Befehl, um das zu tun, und gibt es eine Möglichkeit, es zu tun, ohne Änderungen zu schreiben?

Antworten (3)

28
28
28
2013-06-04 09:14:49 +0000

Die Kennzeichnung S bedeutet, dass die Festplatte als “Reserve” betrachtet wird. Sie sollten versuchen, das Array zu stoppen und neu zu starten:

mdadm --stop /dev/md0
  mdadm --assemble --scan

, um das Array wieder zusammenzusetzen, und wenn das nicht funktioniert, müssen Sie möglicherweise Ihre mdadm.conf aktualisieren, siehe z.B. diese Frage für Details, wie man das macht.

9
9
9
2014-09-13 01:33:49 +0000

Diese Frage ist ein bisschen alt, aber die Antwort könnte jemandem helfen, der vor einer ähnlichen Situation steht. Wenn Sie sich die Ereigniszahlen aus der mdadm –examine-Ausgabe ansehen, die Sie bereitgestellt haben, scheinen sie nahe genug zu sein (955190 - für sdb1 und sdf1, 955219 für sde1 und für sdd1 haben Sie 955205). Wenn sie unter 40-50 liegen, ist das OK, und in diesem Fall ist die empfohlene Vorgehensweise, Ihr Array manuell zusammenzustellen und mdadm zu zwingen, die Laufwerke trotz der Differenz der Ereignisanzahl zu akzeptieren:

Stoppen Sie das Array:

mdadm --stop /dev/md0

Versuchen Sie dann, das Array manuell wieder zusammenzusetzen:

mdadm --assemble --force /dev/md0 /dev/sdb1 /dev/sdd1 /dev/sde1 /dev/sdf1

Überprüfen Sie den Status des Arrays, um zu prüfen, ob die Laufwerksliste/-struktur in Ordnung ist (unten in der Befehlsausgabe wird angezeigt, welches Laufwerk sich in welchem Status und an welcher Position im Array befindet):

mdadm --detail /dev/md0

& Wenn die Struktur in Ordnung ist, prüfen Sie den Fortschritt des Wiederaufbaus:

cat /proc/mdstat
0
0
0
2013-06-04 09:02:31 +0000

Sie können Raid md0 mit dem folgenden Befehl aktivieren

mdadm -A /dev/md0

und diesem Befehl, um die Datei mdadm.conf zu aktualisieren

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