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.

Fehlgeschlagene StorageGRID Replikationsvorgänge identifizieren und wiederholen

Änderungen vorschlagen

Nachdem die Warnung „Permanenter Fehler bei der Cross-grid replication“ behoben wurde, sollte festgestellt werden, ob Objekte oder Löschmarkierungen nicht in das andere Grid repliziert werden konnten. Anschließend können diese Objekte erneut importiert oder die Grid Management API verwendet werden, um die Replikation erneut zu versuchen.

Die Warnung „Permanenter Fehler bei der netzübergreifenden Replikation“ weist darauf hin, dass Mandantenobjekte aus einem Grund, der ein Eingreifen des Benutzers erfordert, nicht zwischen den Buckets auf zwei Grids repliziert werden können. Diese Warnung wird typischerweise durch eine Änderung am Quell- oder Ziel-Bucket verursacht. Weitere Informationen finden sich unter "Fehler in der Grid-Federation beheben".

Feststellen, ob Objekte nicht repliziert wurden.

Um festzustellen, ob Objekte oder Löschmarkierungen nicht in das andere Grid repliziert wurden, kann das Revisionsprotokoll nach "CGRR (Cross-Grid-Replikationsanforderung)" Meldungen durchsucht werden. Diese Meldung wird dem Protokoll hinzugefügt, wenn StorageGRID ein Objekt, ein Multipart-Objekt oder eine Löschmarkierung nicht in den Ziel-Bucket replizieren kann.

Sie können das "audit-explain Tool" verwenden, um die Ergebnisse in ein leichter lesbares Format zu übersetzen.

Bevor Sie beginnen
  • Sie verfügen über Root-Zugriffsberechtigung.

  • Sie haben die Passwords.txt Datei.

  • Sie kennen die IP-Adresse des primären Admin-Knotens.

Schritte
  1. ${post_edited_translations.segment}

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

    2. Geben Sie das in der Passwords.txt Datei aufgeführte Passwort ein.

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

    4. Geben Sie das in der Passwords.txt Datei aufgeführte Passwort ein.

      Wenn Sie als Root angemeldet sind, ändert sich die Eingabeaufforderung von $ zu #.

  2. Im Revisionsprotokoll nach CGRR-Meldungen suchen und das Tool audit-explain verwenden, um die Ergebnisse zu formatieren.

    Beispielsweise durchsucht dieser Befehl alle CGRR-Meldungen der letzten 30 Minuten und verwendet das Tool audit-explain.

    # awk -vdate=$(date -d "30 minutes ago" '+%Y-%m-%dT%H:%M:%S') '$1$2 >= date { print }' audit.log | grep CGRR | audit-explain

    Die Ergebnisse des Befehls sehen wie in diesem Beispiel aus, das Einträge für sechs CGRR-Meldungen enthält. In diesem Beispiel gaben alle Cross-Grid-Replikationsanforderungen einen allgemeinen Fehler zurück, da das Objekt nicht repliziert werden konnte. Die ersten drei Fehler beziehen sich auf „replicate object“-Operationen, die letzten drei auf „replicate delete marker“-Operationen.

    CGRR Cross-Grid Replication Request tenant:50736445269627437748 connection:447896B6-6F9C-4FB2-95EA-AEBF93A774E9 operation:"replicate object" bucket:bucket123 object:"audit-0" version:QjRBNDIzODAtNjQ3My0xMUVELTg2QjEtODJBMjAwQkI3NEM4 error:general error
    CGRR Cross-Grid Replication Request tenant:50736445269627437748 connection:447896B6-6F9C-4FB2-95EA-AEBF93A774E9 operation:"replicate object" bucket:bucket123 object:"audit-3" version:QjRDOTRCOUMtNjQ3My0xMUVELTkzM0YtOTg1MTAwQkI3NEM4 error:general error
    CGRR Cross-Grid Replication Request tenant:50736445269627437748 connection:447896B6-6F9C-4FB2-95EA-AEBF93A774E9 operation:"replicate delete marker" bucket:bucket123 object:"audit-1" version:NUQ0OEYxMDAtNjQ3NC0xMUVELTg2NjMtOTY5NzAwQkI3NEM4 error:general error
    CGRR Cross-Grid Replication Request tenant:50736445269627437748 connection:447896B6-6F9C-4FB2-95EA-AEBF93A774E9 operation:"replicate delete marker" bucket:bucket123 object:"audit-5" version:NUQ1ODUwQkUtNjQ3NC0xMUVELTg1NTItRDkwNzAwQkI3NEM4 error:general error

    Jeder Eintrag enthält die folgenden Informationen:

    Feld Beschreibung

    CGRR Cross-Grid Replikationsanfrage

    Der Name der Anfrage

    Mandant

    Die Konto-ID des Mandanten

    Verbindung

    Die ID der Grid Federation Verbindung

    Betrieb

    Die Art des Replikationsvorgangs, der versucht wurde:

    • Objekt replizieren

    • Löschmarkierung replizieren

    • mehrteiliges Objekt replizieren

    Bucket

    Der Bucket Name

    Objekt

    Der Objektname

    Version

    Die Versions-ID für das Objekt

    Fehler

    Die Art des Fehlers. Wenn die netzübergreifende Replikation fehlgeschlagen ist, lautet die Fehlermeldung „Allgemeiner Fehler“.

Fehlgeschlagene Replikationen wiederholen

Nachdem eine Liste der Objekte und Löschmarkierungen erstellt wurde, die nicht in den Ziel-Bucket repliziert wurden, und die zugrunde liegenden Probleme behoben sind, besteht die Möglichkeit, die Replikation auf eine der beiden folgenden Arten erneut durchzuführen:

  • Jedes Objekt wird erneut in den Quell-Bucket reingestellt.

  • Die private Grid Management API wird wie beschrieben verwendet.

Schritte
  1. Oben im Grid Manager das Hilfesymbol auswählen und anschließend API documentation wählen.

  2. Zur privaten API-Dokumentation auswählen.

    Hinweis Die als „Privat“ gekennzeichneten StorageGRID API-Endpunkte können ohne Vorankündigung geändert werden. StorageGRID private Endpunkte ignorieren außerdem die API-Version der Anfrage.
  3. Im Abschnitt cross-grid-replication-advanced ist der folgende Endpunkt auszuwählen:

    POST /private/cross-grid-replication-retry-failed

  4. Ausprobieren auswählen.

  5. Im Textfeld body ist der Beispiel-Eintrag für versionID durch eine Versions-ID aus dem Revisionsprotokoll audit.log zu ersetzen, die einer fehlgeschlagenen Cross-Grid-Replikationsanforderung entspricht.

    ${post_edited_translations.segment}

  6. Ausführen auswählen.

  7. Bestätigt wird, dass der Server-Antwortcode 204 ist, was darauf hinweist, dass das Objekt oder die Löschmarkierung als ausstehend für die gridübergreifende Replikation in das andere Grid markiert wurde.

    Hinweis „Ausstehend“ bedeutet, dass die Cross-Grid-Replikationsanfrage zur Bearbeitung in die interne Warteschlange aufgenommen wurde.

Replikationswiederholungen überwachen

Es empfiehlt sich, die Replikationswiederholungsvorgänge zu überwachen, um sicherzustellen, dass sie abgeschlossen werden.

Tipp Es kann mehrere Stunden oder länger dauern, bis ein Objekt oder eine Löschmarkierung in das andere Grid repliziert wird.

Wiederholungsvorgänge lassen sich auf zwei Arten überwachen:

  • Eine S3 "HeadObject"- oder "GetObject"-Anfrage kann verwendet werden. Die Antwort enthält den StorageGRID-spezifischen x-ntap-sg-cgr-replication-status-Antwortheader, der einen der folgenden Werte aufweist:

    Grid Replikationsstatus

    Quelle

    • ABGESCHLOSSEN: Die Replikation war erfolgreich.

    • AUSSTEHEND: Das Objekt ist noch nicht repliziert worden.

    • FEHLER: Die Replikation ist dauerhaft fehlgeschlagen. Ein Benutzer muss den Fehler beheben.

    Ziel

    REPLICA: Das Objekt wurde aus dem Quellgrid repliziert.

  • Die private Grid Management API wird wie beschrieben verwendet.

Schritte
  1. Im Abschnitt cross-grid-replication-advanced der privaten API-Dokumentation ist der folgende Endpunkt auszuwählen:

    GET /private/cross-grid-replication-object-status/{id}

  2. Ausprobieren auswählen.

  3. Im Abschnitt „Parameter“ die Versions-ID eingeben, die in der `cross-grid-replication-retry-failed`Anfrage verwendet wurde.

  4. Ausführen auswählen.

  5. Es wird bestätigt, dass der Server-Antwortcode 200 ist.

  6. Der Replikationsstatus ist einer der folgenden:

    • AUSSTEHEND: Das Objekt ist noch nicht repliziert worden.

    • ABGESCHLOSSEN: Die Replikation war erfolgreich.

    • FEHLGESCHLAGEN: Die Replikation ist dauerhaft fehlgeschlagen. Ein Benutzer muss den Fehler beheben.