Afficher les journaux de restauration

Sur cette page, nous expliquons comment vérifier les journaux d'un job de restauration pour en confirmer l'achèvement et valider la restauration.

Vérifier l'achèvement

Pour vérifier que l'opération de restauration a bien été effectuée :

  1. Utilisez la commande suivante pour vérifier si l'opération de restauration s'est terminée sans erreur : 

    kubectl get pods -n -l job-name=apigee-cassandra-restore

    Le résultat ressemble à ce qui suit : 

    NAME                               READY     STATUS      RESTARTS   AGE
apigee-cassandra-restore-6tttv     0/1       Completed   0          23m

  2. Exécutez la commande suivante pour vérifier si les instances répliquées Cassandra sont opérationnelles : 

    kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

    Le résultat ressemble à ce qui suit : 

    NAME                           READY     STATUS      RESTARTS   AGE
apigee-cassandra-default-0     1/1       Running     0          24m
apigee-cassandra-default-1     1/1       Running     0          23m
apigee-cassandra-default-2     1/1       Running     0          22m

Afficher les journaux de restauration

Pour afficher les journaux de restauration d'un pod Kubernetes, exécutez la commande kubectl logs -f <pod_name> -n <namespace> : 

kubectl logs -f CASSANDRA_POD_NAME -n APIGEE_NAMESPACE

Exemple :

kubectl logs -f apigee-cassandra-restore-b4lgf -n apigee

Valider la restauration

Une fois l'opération de restauration terminée, vous pouvez utiliser le plan de contrôle pour vérifier que les développeurs, les applications et les produits d'API de votre organisation ont été correctement restaurés.

Pour afficher les données restaurées :

  1. Sur la ligne de commande, obtenez ou actualisez vos identifiants d'authentification gcloud, comme le montre l'exemple suivant :

    TOKEN=$(gcloud auth print-access-token)
  2. Utilisez la commande suivante pour valider les données de votre organisation, où APIGEE_ORG est une organisation Apigee déployée dans le cluster :
    • Pour les données de développeur :

      Sans résidence des données

      curl -s -H "$TOKEN" https://apigee.googleapis.com/v1/organizations/APIGEE_ORG/developers

      Résidence des données

      curl -s -H "$TOKEN" https://CONTROL_PLANE_LOCATION-apigee.googleapis.com/v1/organizations/APIGEE_ORG/developers
    • Pour les données d'applications :

      Sans résidence des données

      curl -s -H "$TOKEN" https://apigee.googleapis.com/v1/organizations/APIGEE_ORG/apps

      Résidence des données

      curl -s -H "$TOKEN" https://CONTROL_PLANE_LOCATION-apigee.googleapis.com/v1/organizations/APIGEE_ORG/apps
    • Pour les données de produit d'API :

      Sans résidence des données

      curl -s -H "$TOKEN" https://apigee.googleapis.com/v1/organizations/APIGEE_ORG/apiproducts

      Résidence des données

      curl -s -H "$TOKEN" https://CONTROL_PLANE_LOCATION-apigee.googleapis.com/v1/organizations/APIGEE_ORG/apiproducts

Configuration DNS pour le nouveau cluster et le basculement du trafic

Une fois que vous êtes satisfait de la validation, redirigez le trafic vers le nouveau cluster et remplacez l'entrée DNS par la nouvelle adresse de l'entrée, EXTERNAL-IP.

Récupérez la valeur EXTERNAL-IP avec la commande suivante :

kubectl get svc -n istio-system
 
NAME                       TYPE           CLUSTER-IP     EXTERNAL-IP    PORT(S)                                                                      AGE
istio-ingressgateway       LoadBalancer   10.11.123.45   34.56.78.90   15021:32225/TCP,80:32208/TCP,443:31942/TCP,15012:32689/TCP,15443:31936/TCP   1d