Skip to main content
Eine neuere Version dieses Produkts ist erhältlich.
Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

Recovery ausgefallener Storage-Volumes und Wiederherstellung der Cassandra-Datenbank

Beitragende
PDFs

Sie müssen ein Skript ausführen, das den Speicher auf ausgefallenen Storage-Volumes neu formatiert und neu einbindet, und die Cassandra-Datenbank auf dem Storage-Node neu erstellen, falls das System den Bedarf ermittelt.

Bevor Sie beginnen

  • Sie haben die Passwords.txt Datei:

  • Die Systemlaufwerke auf dem Server sind intakt.

  • Die Fehlerursache wurde erkannt und ggf. Ersatz-Storage-Hardware bereits angeschafft.

  • Die Gesamtgröße des Ersatzspeichers ist mit dem Original identisch.

  • Sie haben überprüft, dass keine Ausmusterung von Storage-Nodes ausgeführt wird oder Sie den Vorgang zur Deaktivierung eines Node angehalten haben. (Wählen Sie im Grid Manager MAINTENANCE > Tasks > Decommission.)

  • Sie haben überprüft, dass keine Erweiterung ausgeführt wird. (Wählen Sie im Grid Manager MAINTENANCE > Tasks > Expansion.)

  • Das ist schon "Die Warnungen zur Wiederherstellung des Speichervolumens wurden überprüft".

Schritte

  1. Ersetzen Sie bei Bedarf den fehlerhaften physischen oder virtuellen Speicher, der mit den fehlerhaften Speicher-Volumes verbunden ist, die Sie zuvor ermittelt und abgehängt haben.

    Volumes sollten in diesem Schritt nicht erneut bereitgestellt werden. Der Speicher wird neu eingebunden und hinzugefügt /etc/fstab In einem späteren Schritt.

  2. Gehen Sie im Grid Manager zu NODES > appliance Storage Node > Hardware. Überprüfen Sie im Abschnitt StorageGRID-Gerät auf der Seite, ob der Speicher-RAID-Modus ordnungsgemäß funktioniert.

  3. Melden Sie sich beim fehlgeschlagenen Speicherknoten an:

    1. Geben Sie den folgenden Befehl ein: ssh admin@grid_node_IP

    2. Geben Sie das im aufgeführte Passwort ein Passwords.txt Datei:

    3. Geben Sie den folgenden Befehl ein, um zum Root zu wechseln: su -

    4. Geben Sie das im aufgeführte Passwort ein Passwords.txt Datei:

      Wenn Sie als root angemeldet sind, ändert sich die Eingabeaufforderung von $ Bis #.

  4. Verwenden Sie einen Texteditor (vi oder vim), um fehlgeschlagene Volumes aus dem zu löschen /etc/fstab Datei und dann speichern Sie die Datei.

    Hinweis Kommentieren eines ausgefallenen Volumes in /etc/fstab Datei reicht nicht aus. Das Volume muss aus gelöscht werden fstab Während der Wiederherstellungsvorgang überprüft, ob alle Leitungen im vorhanden sind fstab Die Datei stimmt mit den gemounteten Dateisystemen überein.

  5. Formatieren Sie alle ausgefallenen Storage-Volumes neu und stellen Sie ggf. die Cassandra-Datenbank wieder her. Geben Sie Ein: reformat_storage_block_devices.rb

    • Wenn Speicher-Volume 0 abgehängt ist, werden Eingabeaufforderungen und Meldungen darauf hinweisen, dass der Cassandra-Dienst angehalten wird.

    • Sie werden aufgefordert, die Cassandra-Datenbank bei Bedarf neu aufzubauen.

      • Überprüfen Sie die Warnungen. Falls keines dieser Beispiele zutreffend ist, bauen Sie die Cassandra-Datenbank neu aus. Geben Sie ein: Y

      • Wenn mehr als ein Speicherknoten offline ist oder wenn ein anderer Speicherknoten in den letzten 15 Tagen wieder aufgebaut wurde. Geben Sie: N ein

        Das Skript wird beendet, ohne dass Cassandra neu aufgebaut werden muss. Wenden Sie sich an den technischen Support.

    • Wenn Sie nach jedem Rangedb-Laufwerk auf dem Storage-Node gefragt werden: Reformat the rangedb drive <name> (device <major number>:<minor number>)? [y/n]?, Geben Sie eine der folgenden Antworten ein:

      • Y um ein Laufwerk neu zu formatieren, das Fehler hatte. Dadurch wird das Speichervolumen neu formatiert und das neu formatierte Speichervolume wird hinzugefügt /etc/fstab Datei:

      • N wenn das Laufwerk keine Fehler enthält und Sie es nicht neu formatieren möchten.

        Hinweis Durch Auswahl von n wird das Skript beendet. Entweder montieren Sie das Laufwerk (wenn Sie denken, dass die Daten auf dem Laufwerk beibehalten werden sollten und das Laufwerk fehlerhaft abgehängt wurde) oder entfernen Sie das Laufwerk. Führen Sie dann die aus reformat_storage_block_devices.rb Befehl erneut.
        Hinweis Einige StorageGRID-Wiederherstellungsverfahren verwenden Reaper für die Bearbeitung von Cassandra-Reparaturen. Reparaturen werden automatisch ausgeführt, sobald die entsprechenden oder erforderlichen Services gestartet wurden. Sie können die Skriptausgabe bemerken, die “reaper” oder “Cassandra Reparatur erwähnt.” Wenn eine Fehlermeldung angezeigt wird, dass die Reparatur fehlgeschlagen ist, führen Sie den in der Fehlermeldung angegebenen Befehl aus.

      Im folgenden Beispiel wird das Laufwerk ausgegeben /dev/sdf Muss neu formatiert werden, und Cassandra musste nicht neu aufgebaut werden:

    root@DC1-S1:~ # reformat_storage_block_devices.rb
Formatting devices that are not in use...
Skipping in use device /dev/sdc
Skipping in use device /dev/sdd
Skipping in use device /dev/sde
Reformat the rangedb drive /dev/sdf (device 8:64)? [Y/n]? y
Successfully formatted /dev/sdf with UUID b951bfcb-4804-41ad-b490-805dfd8df16c
All devices processed
Running: /usr/local/ldr/setup_rangedb.sh 12368435
Cassandra does not need rebuilding.
Starting services.
Informing storage services of new volume

Reformatting done.  Now do manual steps to
restore copies of data.

Nachdem die Speicher-Volumes neu formatiert und neu gemountet wurden und die erforderlichen Cassandra-Vorgänge abgeschlossen sind, können Sie dies tun "Stellen Sie Objektdaten mithilfe von Grid Manager wieder her".