Auf dieser Seite wird beschrieben, wie Sie die Logs der Wiederherstellung prüfen können, um den Abschluss zu bestätigen und die Wiederherstellung zu validieren.
Abschluss prüfen
So prüfen Sie, ob der Wiederherstellungsvorgang erfolgreich abgeschlossen wurde:
Verwenden Sie den folgenden Befehl, um zu prüfen, ob der Wiederherstellungsvorgang ohne Fehler abgeschlossen wurde:
kubectl get pods -n -l job-name=apigee-cassandra-restore
Die Ausgabe sieht etwa so aus:
NAME READY STATUS RESTARTS AGE
apigee-cassandra-restore-6tttv 0/1 Completed 0 23m
Prüfen Sie mit dem folgenden Befehl, ob die Cassandra-Replikate aktiv sind:
kubectl get pods -n -l app=apigee-cassandra
Die Ausgabe sieht etwa so aus:
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
Wiederherstellungslogs anzeigen
Führen Sie den Befehl kubectl logs -f <pod_name> -n <namespace> aus, um die Wiederherstellungslogs eines Kubernetes-Pods zu sehen. Beispiel:
Nach Abschluss des Wiederherstellungsvorgangs können Sie über die Steuerungsebene prüfen, ob die Entwickler, Apps und API-Produkte Ihrer Organisation ordnungsgemäß wiederhergestellt wurden.
So rufen Sie die wiederhergestellten Daten auf:
Rufen Sie in der Befehlszeile Ihre gcloud-Authentifizierungsdaten ab oder aktualisieren Sie sie, wie das folgende Beispiel zeigt:
TOKEN=$(gcloud auth print-access-token)
Verwenden Sie den folgenden Befehl, um die Daten Ihrer Organisation zu validieren, wobei APIGEE_ORG eine Apigee-Organisation ist, die im Cluster bereitgestellt wird:
Während der Cassandra-Wiederherstellung in Apigee Hybrid können Fehler in den Wiederherstellungslogs auftreten. Informationen zu Fehlern, Ursachen und Möglichkeiten zur Behebung finden Sie unter Fehlerbehebung: Cassandra-Wiederherstellung.
DNS-Konfiguration für neue Cluster- und Trafficumstellung
Wenn Sie mit der Validierung zufrieden sind, leiten Sie den Traffic zum neuen Cluster um und ändern Sie den DNS-Eintrag in eine neue EXTERNAL-IP-Adresse für eingehenden Traffic.
Rufen Sie EXTERNAL-IP mit dem folgenden Befehl ab:
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
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-09-04 (UTC)."],[[["\u003cp\u003eThis documentation guides users on how to check restore job logs to confirm the successful completion and validation of an Apigee hybrid restore operation.\u003c/p\u003e\n"],["\u003cp\u003eYou can verify the successful completion of a restore operation by checking the status of the \u003ccode\u003eapigee-cassandra-restore\u003c/code\u003e job and the \u003ccode\u003eapigee-cassandra\u003c/code\u003e replicas in Kubernetes using \u003ccode\u003ekubectl\u003c/code\u003e commands.\u003c/p\u003e\n"],["\u003cp\u003eYou can view detailed logs of the restore process using the \u003ccode\u003ekubectl logs\u003c/code\u003e command to troubleshoot potential errors.\u003c/p\u003e\n"],["\u003cp\u003eAfter restoration, you can validate the restored developer, app, and API product data by querying the Apigee control plane using \u003ccode\u003ecurl\u003c/code\u003e commands and your gcloud authentication token.\u003c/p\u003e\n"],["\u003cp\u003eOnce data is validated, traffic can be directed to the restored cluster by updating the DNS entry to point to the new ingress's \u003ccode\u003eEXTERNAL-IP\u003c/code\u003e.\u003c/p\u003e\n"]]],[],null,["# Viewing restore logs\n\n| You are currently viewing version 1.9 of the Apigee hybrid documentation. **This version is end of life.** You should upgrade to a newer version. For more information, see [Supported versions](/apigee/docs/hybrid/supported-platforms#supported-versions).\n\nThis page describes how you can check the restore job logs to confirm completion and validate the restore.\n\nVerifying completion\n--------------------\n\nTo verify that the restore operation completed successfully:\n\n1.\n Use the following command to check if the restore operation completed without error:\n\n ```\n kubectl get pods -n -l job-name=apigee-cassandra-restore\n ```\n\n\n The output is similar to the following: \n\n ```text\n NAME READY STATUS RESTARTS AGE\n apigee-cassandra-restore-6tttv 0/1 Completed 0 23m\n ```\n2.\n Use the following command to check if the cassandra replicas are up and running:\n\n ```\n kubectl get pods -n -l app=apigee-cassandra\n ```\n\n\n The output is similar to the following: \n\n ```text\n NAME READY STATUS RESTARTS AGE\n apigee-cassandra-default-0 1/1 Running 0 24m\n apigee-cassandra-default-1 1/1 Running 0 23m\n apigee-cassandra-default-2 1/1 Running 0 22m\n ```\n\nViewing restore logs\n--------------------\n\nTo view the restore logs of a Kubernetes pod, run the\n`kubectl logs -f \u003cpod_name\u003e -n \u003cnamespace\u003e`\ncommand. For example: \n\n```\nkubectl logs -f apigee-cassandra-restore-b4lgf -n apigee\n```\n\nValidating restore\n------------------\n\nUpon completing the restore operation, you can use the control plane to confirm that your organization's developers,\napps, and API products were restored correctly.\n\nTo view the restored data:\n\n1. On the command line, get or refresh your gcloud authentication credentials, as the following\n example shows:\n\n ```\n TOKEN=$(gcloud auth print-access-token)\n ```\n2. Use the following command to validate your organization's data, where \u003cvar translate=\"no\"\u003eAPIGEE_ORG\u003c/var\u003e is an Apigee organization deployed in the cluster:\n - For developer data: \n\n ```\n curl -s -H \"$TOKEN\" https://apigee.googleapis.com/v1/organizations/APIGEE_ORG/developers\n ```\n - For apps data: \n\n ```\n curl -s -H \"$TOKEN\" https://apigee.googleapis.com/v1/organizations/APIGEE_ORG/apps\n ```\n - For API product data: \n\n ```\n curl -s -H \"$TOKEN\" https://apigee.googleapis.com/v1/organizations/APIGEE_ORG/apiproducts\n ```\n\n| **Note**: Confirm that your APIs are working as expected before adding a restored cluster to your traffic.\n\nTroubleshooting restore\n-----------------------\n\n\nDuring the Cassandra restoration in Apigee hybrid, you may encounter\nerrors in the restore logs. See\n[Troubleshooting Cassandra restore](/apigee/docs/api-platform/troubleshoot/playbooks/cassandra/ts-cassandra-restore) for\nerrors, causes, and how to resolve the issues.\n\nDNS Configuration for new cluster and traffic cutover\n-----------------------------------------------------\n\n\nOnce you are satisfied with validation, redirect the traffic to the new cluster and change the dns\nentry to new ingress `EXTERNAL-IP` address.\n\nGet the `EXTERNAL-IP` with the following command: \n\n```\nkubectl get svc -n istio-system\n``` \n\n```text\nNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE\nistio-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\n```\n\n\u003cbr /\u003e"]]
