Skip to main content
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Identifier et réessayer les opérations de réplication ayant échoué

PDF

Après avoir résolu l'alerte Échec permanent de la réplication inter-grille, vous devez déterminer si des objets ou des marqueurs de suppression n'ont pas pu être répliqués sur l'autre grille. Vous pouvez ensuite réingérer ces objets ou utiliser l’API de gestion de grille pour réessayer la réplication.

L'alerte Échec permanent de la réplication inter-grille indique que les objets locataires ne peuvent pas être répliqués entre les buckets sur deux grilles pour une raison qui nécessite l'intervention de l'utilisateur pour être résolue. Cette alerte est généralement provoquée par une modification du bucket source ou de destination. Pour plus de détails, consultez la section "Résoudre les erreurs de fédération de grille" .

Déterminer si des objets n'ont pas pu être répliqués

Pour déterminer si des objets ou des marqueurs de suppression n'ont pas été répliqués sur l'autre grille, vous pouvez rechercher dans le journal d'audit"CGRR (demande de réplication inter-réseau)" messages. Ce message est ajouté au journal lorsque StorageGRID ne parvient pas à répliquer un objet, un objet en plusieurs parties ou à supprimer un marqueur dans le bucket de destination.

Vous pouvez utiliser le"outil d'audit-explication" pour traduire les résultats dans un format plus facile à lire.

Avant de commencer

  • Vous disposez de l'autorisation d'accès root.

  • Vous avez le Passwords.txt déposer.

  • Vous connaissez l’adresse IP du nœud d’administration principal.

Étapes

  1. Connectez-vous au nœud d’administration principal :

    1. Entrez la commande suivante : ssh admin@primary_Admin_Node_IP

    2. Entrez le mot de passe indiqué dans le Passwords.txt déposer.

    3. Entrez la commande suivante pour passer en root : su -

    4. Entrez le mot de passe indiqué dans le Passwords.txt déposer.

      Lorsque vous êtes connecté en tant que root, l'invite passe de $ à # .

  2. Recherchez les messages CGRR dans le journal d'audit et utilisez l'outil audit-explain pour formater les résultats.

    Par exemple, cette commande recherche tous les messages CGRR au cours des 30 dernières minutes et utilise l'outil 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

    Les résultats de la commande ressembleront à cet exemple, qui comporte des entrées pour six messages CGRR. Dans l'exemple, toutes les demandes de réplication inter-grille ont renvoyé une erreur générale car l'objet n'a pas pu être répliqué. Les trois premières erreurs concernent les opérations de « réplication d'objet » et les trois dernières erreurs concernent les opérations de « réplication de marqueur de suppression ».

    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

    Chaque entrée contient les informations suivantes :

    Champ Description

    Demande de réplication inter-réseau CGRR

    Le nom de la demande

    locataire

    L'identifiant du compte du locataire

    connexion

    L'ID de la connexion à la fédération de grille

    opération

    Le type d'opération de réplication qui était tentée :

    • répliquer l'objet

    • répliquer supprimer le marqueur

    • répliquer un objet en plusieurs parties

    seau

    Le nom du bucket

    objet

    Le nom de l'objet

    version

    L'ID de version de l'objet

    erreur

    Le type d'erreur. Si la réplication inter-grille échoue, l'erreur est « Erreur générale ».

Réessayer les réplications ayant échoué

Après avoir généré une liste d'objets et supprimé les marqueurs qui n'ont pas été répliqués dans le compartiment de destination et résolu les problèmes sous-jacents, vous pouvez réessayer la réplication de deux manières :

  • Réingérez chaque objet dans le bucket source.

  • Utilisez l’API privée Grid Management, comme décrit.

Étapes

  1. En haut du gestionnaire de grille, sélectionnez l’icône d’aide et sélectionnez Documentation API.

  2. Sélectionnez Accéder à la documentation de l'API privée.

    Remarque Les points de terminaison de l'API StorageGRID marqués « Privé » sont susceptibles d'être modifiés sans préavis. Les points de terminaison privés StorageGRID ignorent également la version API de la demande.

  3. Dans la section cross-grid-replication-advanced, sélectionnez le point de terminaison suivant :

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

  4. Sélectionnez Essayer.

  5. Dans la zone de texte body, remplacez l'exemple d'entrée pour versionID par un ID de version du fichier audit.log qui correspond à une demande de réplication inter-grille ayant échoué.

    Assurez-vous de conserver les guillemets doubles autour de la chaîne.

  6. Sélectionnez Exécuter.

  7. Confirmez que le code de réponse du serveur est 204, indiquant que l'objet ou le marqueur de suppression a été marqué comme en attente de réplication inter-grille vers l'autre grille.

    Remarque En attente signifie que la demande de réplication inter-grille a été ajoutée à la file d'attente interne pour traitement.

Surveiller les tentatives de réplication

Vous devez surveiller les opérations de nouvelle tentative de réplication pour vous assurer qu'elles se terminent.

Astuce La réplication d'un objet ou d'un marqueur de suppression sur l'autre grille peut prendre plusieurs heures, voire plus.

Vous pouvez surveiller les opérations de nouvelle tentative de deux manières :

  • Utiliser un S3"HeadObject" ou"Obtenir l'objet" demande. La réponse inclut le StorageGRID spécifique x-ntap-sg-cgr-replication-status en-tête de réponse, qui aura l'une des valeurs suivantes :

    Grille État de réplication

    Source

    • TERMINÉ : La réplication a réussi.

    • EN ATTENTE : L'objet n'a pas encore été répliqué.

    • ÉCHEC : La réplication a échoué avec un échec permanent. Un utilisateur doit résoudre l’erreur.

    Destination

    RÉPLIQUE : L'objet a été répliqué à partir de la grille source.

  • Utilisez l’API privée Grid Management, comme décrit.

Étapes

  1. Dans la section cross-grid-replication-advanced de la documentation de l'API privée, sélectionnez le point de terminaison suivant :

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

  2. Sélectionnez Essayer.

  3. Dans la section Paramètres, entrez l'ID de version que vous avez utilisé dans le cross-grid-replication-retry-failed demande.

  4. Sélectionnez Exécuter.

  5. Confirmez que le code de réponse du serveur est 200.

  6. Vérifiez l’état de réplication, qui sera l’un des suivants :

    • EN ATTENTE : L'objet n'a pas encore été répliqué.

    • TERMINÉ : La réplication a réussi.

    • ÉCHEC : La réplication a échoué avec un échec permanent. Un utilisateur doit résoudre l’erreur.