Afficher les journaux de restauration

Cette page décrit comment vérifier les journaux d'une tâche de restauration pour 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, procédez comme suit :

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

Exécutez la commande suivante pour vérifier si les instances dupliquées Cassandra sont opérationnelles :

kubectl get pods -n -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>. 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, procédez comme suit :

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)
```

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.

Obtenez l'élément 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