Cassandra-Backup und -Wiederherstellung

In diesem Abschnitt wird erläutert, wie Sie die Datenbackup und -wiederherstellung für den Apache Cassandra-Datenbankring konfigurieren, der auf der Apigee Hybrid-Laufzeitebene installiert ist. Siehe auch Cassandra-Datenspeicher.

Warum Cassandra-Sicherungen wichtig sind

Sicherungen sind ein wichtiger Schutz für Notfallszenarien. Jede Sicherung ist ein konsistenter Snapshot der aktuellen Cassandra-Daten zum Zeitpunkt der Sicherung. Dazu gehören die Cassandra-Daten sowie Schema/Metadaten innerhalb des Cassandra-Clusters. Mit Sicherungen können Nutzer ihre Apigee Hybrid-Instanz in einem bekannten einwandfreiem Zustand wiederherstellen, ein entscheidender Schritt, um eine Hybrid-Instanz im Falle einer Katastrophe wieder online zu bringen. Je nach Größe der Hybridinstanz kann eine oder mehrere Sicherungsdateien für einen einzelnen Sicherungssatz vorhanden sein. Wenn die Hybrid-Instanz beispielsweise drei Cassandra-Knoten hat, enthält der Sicherungssatz drei Sicherungsdateien. Wenn die Hybrid-Instanz 30 Cassandra-Knoten hat, enthält der Sicherungssatz 30 Sicherungsdateien. Der Zeitraum für die Wiederherstellung einer Hybridinstanz aus einer Sicherung hängt also davon ab, wie viele Sicherungsdateien in einem Sicherungssatz wiederhergestellt werden müssen.

Wissenswertes über Cassandra-Backups

Cassandra ist eine replizierte Datenbank, die zum Erhalt von mindestens drei Kopien Ihrer Daten pro Region oder Rechenzentrum konfiguriert ist. Cassandra verwendet Streamingreplikation und Lesereparaturen, um die Datenreplikate pro Region und Rechenzentrum zu verwalten.

In Hybrid sind Cassandra-Sicherungen standardmäßig nicht aktiviert. Es empfiehlt sich jedoch, Cassandra-Sicherungen für den Fall zu aktivieren, dass Ihre Daten aufgrund eines Totalausfalls verloren gehen. Cassandra-Sicherungen sind für die Verwendung im Notfall und nicht für die Wiederherstellung von Datenverlusten vorgesehen, die durch ein versehentliches Löschen verursacht wurden.

Sicherungen werden nach dem Zeitplan erstellt, der in der Datei overrides.yaml festgelegt ist. Eine Anleitung zum Planen von Sicherungen finden Sie im Abschnitt Cassandra-Sicherungen planen. Nachdem ein Sicherungszeitplan auf Ihren Hybrid-Cluster angewendet wurde, wird regelmäßig ein Kubernetes-Sicherungsjob gemäß dem Zeitplan ausgeführt. Der Job löst ein Sicherungsskript auf jedem Cassandra-Knoten in Ihrem Hybrid-Cluster aus, das alle Daten auf dem Knoten sammelt, eine Archivdatei der Daten erstellt und das Archiv an den Google Cloud Storage-Bucket sendet, der in der Cassandra-Sicherungskonfiguration in der Datei overrides.yaml angegeben ist.

Was wird gesichert?

Die in diesem Thema beschriebene Backup-Konfiguration sichert folgende Entitäten:

Cassandra-Schema mit Nutzerschema (Apigee-Keyspace-Definitionen)
Cassandra-Partitionstoken-Informationen pro Knoten
Ein Snapshot der Cassandra-Daten

Wo werden Backupdaten gespeichert?

Gesicherte Daten werden in einem Google Cloud Storage-Bucket gespeichert, den Sie erstellen müssen. Das Erstellen und Konfigurieren von Buckets wird in diesem Thema behandelt.

Cassandra-Backups planen

Backups werden als cron-Jobs auf der Laufzeitebene geplant. So planen Sie Cassandra-Sicherungen:

Führen Sie den folgenden Befehl create-service-account aus, um ein Google Cloud-Dienstkonto (Service Account, SA) mit der Standardrolle roles/storage.objectAdmin zu erstellen. Mit dieser SA-Rolle können Sie Backupdaten in Cloud Storage schreiben. Führen Sie folgenden Befehl im Stammverzeichnis der Hybrid-Installation aus:
```
../tools/create-service-account --env prod \
  --profile apigee-cassandra \
  --name CASSANDRA_BACKUP_SA_NAME \
  --dir OUTPUT_DIR
```
Wobei:
- CASSANDRA_BACKUP_SA_NAME ist der Name des Dienstkontos.
- OUTPUT_DIR ist das Verzeichnis, in dem das Tool die .json-Datei des Dienstkontos ausgibt.
Beispiel:
```
./tools/create-service-account --env prod \
  --profile apigee-cassandra \
  --name my-cassandra-backup-sa  --dir ./service-accounts
```
Weitere Informationen zu Google Cloud-Dienstkonten finden Sie unter Dienstkonten erstellen und verwalten.
Mit dem Befehl create-service-account wird eine JSON-Datei mit dem privaten Schlüssel des Dienstkontos gespeichert. Die Datei wird im selben Verzeichnis gespeichert, in dem der Befehl ausgeführt wird. Sie benötigen den Pfad zu dieser Datei in den folgenden Schritten.
Cloud Storage-Bucket erstellen Legen Sie für den Bucket eine angemessene Aufbewahrungsrichtliniefür Daten fest. Apigee empfiehlt eine Datenaufbewahrungszeit von 15 Tagen.
Öffnen Sie Ihre overrides.yaml-Datei.

Fügen Sie folgende cassandra.backup-Attribute hinzu, um das Backup zu aktivieren. Entfernen Sie keine der bereits konfigurierten Attribute.

Parameter

cassandra:
  ...

  backup:
    enabled: true
    serviceAccountPath: SA_JSON_FILE_PATH
    dbStorageBucket: CLOUD_STORAGE_BUCKET_PATH
    schedule: BACKUP_SCHEDULE_CODE

  ...

Beispiel

...

cassandra:
  storage:
    type: gcepd
    capacity: 50Gi
    gcepd:
      replicationType: regional-pd
  sslRootCAPath: "/Users/myhome/ssh/cassandra.crt"
  sslCertPath: "/Users/myhome/ssh/cassandra.crt"
  sslKeyPath: "/Users/myhome/ssh/cassandra.key"
  auth:
    default:
      password: "abc123"
    admin:
      password: "abc234"
    ddl:
      password: "abc345"
    dml:
      password: "abc456"
  nodeSelector:
    key: cloud.google.com/gke-nodepool
    value: apigee-data
  backup:
    enabled: true
    serviceAccountPath: "/Users/myhome/.ssh/my-cassandra-backup-sa.json"
    dbStorageBucket: "gs://myname-cassandra-backup"
    schedule: "45 23 * * 6"

  ...

Attribut	Beschreibung
`backup:enabled`	Die Sicherung ist standardmäßig deaktiviert. Sie müssen dieses Attribut auf `true` festlegen.
`backup:serviceAccountPath`	`SA_JSON_FILE_PATH` Der Pfad in Ihrem Dateisystem zur JSON-Datei des Dienstkontos, die beim Ausführen von `./tools/create-service-account` heruntergeladen wurde
`backup:dbStorageBucket`	`CLOUD_STORAGE_BUCKET_PATH` Der Cloud Storage-Bucket-Pfad im Format `gs://BUCKET_NAME`. `gs://` ist erforderlich.
`backup:schedule`	`BACKUP_SCHEDULE_CODE` Die Zeit, zu der das Backup startet, angegeben in der Standard-Crontab-Syntax. Standard: `0 2 * * ` Hinweis:* Planen Sie kein Backup, das kurz nach dem Anwenden der Backupkonfiguration auf den Cluster startet. Wenn Sie die Backup-Konfiguration anwenden, erstellt Kubernetes die Cassandra-Knoten neu. Wenn das Backup vor dem Neustart der Knoten (möglicherweise mehrere Minuten) startet, schlägt die Backup fehl.

Wenden Sie die Konfigurationsänderungen auf den neuen Cluster an. Beispiel:
```
./apigeectl apply -f overrides.yaml
```

Überprüfen Sie den Sicherungsjob. Beispiel:

kubectl get cronjob -n apigee

NAME                      SCHEDULE     SUSPEND   ACTIVE   LAST SCHEDULE   AGE
apigee-cassandra-backup   33 * * * *   False     0        <none>          94s

Sicherungen wiederherstellen

Verwenden Sie Sicherungen, um die Apigee-Infrastruktur von Grund auf wiederherzustellen, falls es zu katastrophalen Ausfällen kommt, z. B. wenn alle Daten in der Apigee-Hybrid-Instanz aufgrund eines Unglücks unwiederbringlich verloren gehen. Wenn Sie eine Bereitstellung mit mehreren Regionen haben, sollten Sie bei der Wiederherstellung nach einem Ausfall einer einzelnen Region die Außerbetriebnahme verwenden, um die betroffene Region zu bereinigen, und dann die DN-Erweiterung für die betroffene Region verwenden. Apigee Cassandra-Bereitstellungen und die betriebsbereite Architektur sorgen für Redundanz und Fehlertoleranz für eine einzelne Region. Es wird empfohlen, Apigee Hybrid in einer Konfiguration mit mehreren Regionen für Produktionsanwendungen bereitzustellen. Dann kann ein Regionsausfall von einer der anderen Live-Regionen unter Verwendung der dokumentierten Verfahren zur Außerbetriebnahme und Erweiterung von Regionen wiederhergestellt werden und es muss keine Sicherung verwendet werden.

Sicherungen sollten aus folgenden Gründen nicht verwendet werden:

Cassandra-Knotenfehler.
Versehentliches Löschen von Daten wie Anwendungen, Entwicklern und API-Anmeldedaten.
Ausfall einer oder mehrerer Regionen bei einer Bereitstellung mit mehreren Regionen.

Bei der Wiederherstellung zu beachtende Punkte:

Ausfallzeit: Es kommt zu einer Ausfallzeit für die Dauer der Wiederherstellung.
Datenverlust: Zwischen der letzten gültigen Sicherung und dem Zeitpunkt, zu dem die Wiederherstellung abgeschlossen ist, tritt ein Datenverlust auf.
Wiederherstellungszeit: Die Wiederherstellungszeit hängt von der Größe der Daten und dem Cluster ab.
Gezielt Daten auswählen: Sie können nicht gezielt Daten zur Wiederherstellung auswählen. Die Wiederherstellung stellt die gesamte ausgewählte Sicherung wieder her.

Die Wiederherstellung verwendet Ihre Daten vom Backup-Speicherort und stellt die Daten in einem neuen Cassandra-Cluster mit der gleichen Anzahl von Knoten wieder her. Es werden keine Clusterdaten aus dem alten Cassandra-Cluster übernommen.

Die folgende Wiederherstellungsanleitung gilt für Bereitstellungen in einer einzigen Region, die Google Cloud Storage für Backups verwenden. Für weitere Bereitstellungen:

Informationen zu Bereitstellungen in einer Region, die Google Cloud Storage nicht für Backups verwenden, finden Sie unter Backup und Wiederherstellung ohne Google Cloud.
Informationen zu multiregionalen Bereitstellungen finden Sie unter Multiregionale Bereitstellung in GKE und GKE On-Prem.

So stellen Sie Cassandra-Backups wieder her:

Erstellen Sie einen neuen Kubernetes-Cluster mit einem neuen Namespace, in dem die Bereitstellung der Hybrid-Laufzeit wiederhergestellt wird. Sie können nicht den Cluster und Namespace verwenden, den Sie für die ursprüngliche Hybridinstallation verwendet haben.
Erstellen Sie im Stammverzeichnis der Hybridinstallation eine neue overrides-restore.yaml-Datei.
Kopieren Sie die gesamte Konfiguration aus der ursprünglichen overrides.yaml-Datei in die neue overrides-restore.yaml-Datei. Beispiel:
```
cp ./overrides.yaml ./overrides-restore.yaml
```

In der neuen overrides-restore.yaml fügen Sie die Elemente namespace und restore hinzu und stellen sicher, dass die TLS-Authentifizierungsdaten in den cassandra-Eigenschaften korrekt sind.

Parameter

    namespace: YOUR_RESTORE_NAMESPACE
    cassandra:
      ...
      sslRootCAPath: PATH_TO_ROOT_CA_FILE
      sslCertPath: PATH_TO_SSL_CERT_FILE
      sslKeyPath: PATH_TO_SSL_KEY_FILE
      ...
      restore:
        enabled: true
        snapshotTimestamp: TIMESTAMP
        serviceAccountPath: SA_JSON_FILE_PATH
        dbStorageBucket: CLOUD_STORAGE_BUCKET_PATH
             image:
               pullPolicy: Always
      ...

Beispiel

    ...

    namespace: cassandra-restore

    cassandra:
      storage:
        type: gcepd
        capacity: 50Gi
        gcepd:
          replicationType: regional-pd
      sslRootCAPath: "/Users/myhome/ssh/cassandra.crt"
      sslCertPath: "/Users/myhome/ssh/cassandra.crt"
      sslKeyPath: "/Users/myhome/ssh/cassandra.key"
      auth:
        default:
          password: "abc123"
        admin:
          password: "abc234"
        ddl:
          password: "abc345"
        dml:
          password: "abc456"
      nodeSelector:
        key: cloud.google.com/gke-nodepool
        value: apigee-data

      restore:
        enabled: true
        snapshotTimestamp: "20210203213003"
        serviceAccountPath: "/Users/myhome/.ssh/my_cassandra_backup.json"
        dbStorageBucket: "gs://myname-cassandra-backup"
        image:
          pullPolicy: Always

    ...

Wobei:

Attribut	Beschreibung
`sslRootCAPath` `sslCertPath` `sslKeyPath`	`PATH_TO_ROOT_CA_FILE` `PATH_TO_SSL_CERT_FILE` `PATH_TO_SSL_KEY_FILE` Verwenden Sie dieselben TLS-Authentifizierungsdaten, mit denen Sie auch die ursprüngliche Cassandra-Datenbank erstellt haben.
`namespace`	`YOUR_RESTORE_NAMESPACE` Der Name des neuen Namespace, den Sie in Schritt 1 für den neuen Cassandra-Cluster erstellt haben. Verwenden Sie nicht denselben Namespace, den Sie für den ursprünglichen Cluster verwendet haben.
`restore:enabled`	Die Wiederherstellung ist standardmäßig deaktiviert. Sie müssen dieses Attribut auf `true` festlegen.
`restore:snapshotTimestamp`	`TIMESTAMP` Der Zeitstempel des wiederherzustellenden Backup-Snapshots. Wenn Sie prüfen möchten, welche Zeitstempel verwendet werden können, rufen Sie `dbStorageBucket` auf und sehen Sie sich die Dateien im Bucket an. Jeder Dateiname enthält einen Zeitstempelwert wie den folgenden: `backup_20210203213003_apigee-cassandra-default-0.tgz` Dabei ist `20210203213003` der `snapshotTimestamp`-Wert, den Sie verwenden würden, wenn Sie die Backups zu diesem Zeitpunkt wiederherstellen wollten.
`restore:serviceAccountPath`	`SA_JSON_FILE_PATH` Der Pfad in Ihrem Dateisystem zum Dienstkonto, das Sie für das Backup erstellt haben.
`restore:dbStorageBucket`	`CLOUD_STORAGE_BUCKET_PATH` Der Cloud Storage-Bucket-Pfad, in dem Ihre Backup-Daten gespeichert werden, im folgenden Format: `gs://BUCKET_NAME` `gs://` ist erforderlich.

Ändern Sie das Label app auf allen Cassandra-Knoten im alten Namespace. Führen Sie dazu den folgenden Befehl aus:
```
kubectl label pods --overwrite --namespace=OLD_NAMESPACE -l app=apigee-cassandra app=apigee-cassandra-old
```
Erstellen Sie eine neue Hybrid-Laufzeitbereitstellung. Damit wird ein neuer Cassandra-Cluster erstellt und die Backupdaten werden im Cluster wiederhergestellt:
```
./apigeectl init  -f ../overrides-restore.yaml
```
```
./apigeectl apply  -f ../overrides-restore.yaml
```
Nach Abschluss der Wiederherstellung muss der Traffic umgeschaltet werden, damit er den Cassandra-Cluster im neuen Namespace verwendet. Führen Sie die folgenden Befehle aus, um den Traffic umzuschalten:
```
kubectl get rs -n OLD_NAMESPACE # look for the 'apigee-connect' replicaset
```
```
kubectl patch rs -n OLD_NAMESPACE APIGEE_CONNECT_RS_NAME -p '{"spec":{"replicas" : 0}}'
```
Sobald die Traffic-Umschaltung abgeschlossen ist, können Sie die Backups auf dem wiederhergestellten Cluster neu konfigurieren. Entfernen Sie dazu die Konfiguration restore und fügen Sie die Konfiguration backup zur Datei overrides-restore.yaml hinzu. Ersetzen Sie YOUR_RESTORE_NAMESPACE durch den in Schritt 1 erstellten neuen Namespace-Namen.
```
namespace: YOUR_RESTORE_NAMESPACE
cassandra:
  ...
   backup:
    enabled: true
    serviceAccountPath: SA_JSON_FILE_PATH
    dbStorageBucket: CLOUD_STORAGE_BUCKET_PATH
    schedule: BACKUP_SCHEDULE_CODE
  ...
```
Wenden Sie dann die backup-Konfiguration mit dem folgenden Befehl an:
```
./apigeectl apply  -f ../overrides-restore.yaml
```

Wiederherstellungslogs anzeigen

Sie können die Joblogs prüfen und grep zum Suchen nach error verwenden, um sicherzustellen, dass das Wiederherstellungslog keine Fehler enthält.

Prüfen Sie, ob die Wiederherstellung abgeschlossen wurde

Verwenden Sie den folgenden Befehl, um zu prüfen, ob der Wiederherstellungsvorgang abgeschlossen wurde:

kubectl get pods

Die Ausgabe sieht etwa so aus:

NAME                           READY     STATUS      RESTARTS   AGE
apigee-cassandra-default-0     1/1       Running     0          1h
apigee-cassandra-default-1     1/1       Running     0          1h
apigee-cassandra-default-2     1/1       Running     0          59m
apigee-cassandra-restore-b4lgf 0/1       Completed   0          51m

Wiederherstellungsprotokolle anzeigen

Rufen Sie die Wiederherstellungslogs mit folgendem Befehl auf:

kubectl logs -f apigee-cassandra-restore-b4lgf

Die Ausgabe sieht etwa so aus:

Restore Logs:

Activated service account credentials for: [apigee-cassandra-backup-svc@gce-myusername.iam.gserviceaccount.com]
to download file gs://gce-myusername-apigee-cassandra-backup/apigeecluster/dc-1/backup_20190405011309_schema.tgz
INFO: download successfully extracted the backup files from gs://gce-myusername-apigee-cassandra-backup/apigeecluster/dc-1
finished downloading schema.cql
to create schema from 10.32.0.28

Warnings :
dclocal_read_repair_chance table option has been deprecated and will be removed in version 4.0

dclocal_read_repair_chance table option has been deprecated and will be removed in version 4.0

Warnings :
dclocal_read_repair_chance table option has been deprecated and will be removed in version 4.0

dclocal_read_repair_chance table option has been deprecated and will be removed in version 4.0

INFO: the schema has been restored
starting apigee-cassandra-default-0 in default
starting apigee-cassandra-default-1 in default
starting apigee-cassandra-default-2 in default
84 95 106
waiting on waiting nodes $pid to finish  84
Activated service account credentials for: [apigee-cassandra-backup-svc@gce-myusername.iam.gserviceaccount.com]
Activated service account credentials for: [apigee-cassandra-backup-svc@gce-myusername.iam.gserviceaccount.com]
Activated service account credentials for: [apigee-cassandra-backup-svc@gce-myusername.iam.gserviceaccount.com]
INFO: restore downloaded  tarball and extracted the file from  gs://gce-myusername-apigee-cassandra-backup/apigeecluster/dc-1
INFO: restore downloaded  tarball and extracted the file from  gs://gce-myusername-apigee-cassandra-backup/apigeecluster/dc-1
INFO: restore downloaded  tarball and extracted the file from  gs://gce-myusername-apigee-cassandra-backup/apigeecluster/dc-1
INFO  12:02:28 Configuration location: file:/etc/cassandra/cassandra.yaml
…...

INFO  12:02:41 [Stream #e013ee80-5863-11e9-8458-353e9e3cb7f9] All sessions completed

Summary statistics:
   Connections per host    : 3
   Total files transferred : 2
   Total bytes transferred : 0.378KiB
   Total duration          : 5048 ms
   Average transfer rate   : 0.074KiB/s
   Peak transfer rate      : 0.075KiB/s

progress: [/10.32.1.1.6]0:1/1 100% 1:1/1 100% [/10.32.0.28]1:1/1 100% 0:1/1 100% [/10.32.3.220]0:1/1 100% 1:1/1 100% total: 100% 0.000KiB/s (avg: 0.074KiB/s)
INFO  12:02:41 [Stream #e013ee80-5863-11e9-8458-353e9e3cb7f9] All sessions completed
progress: [/10.32.1.1.6]0:1/1 100% 1:1/1 100% [/10.32.0.28]1:1/1 100% 0:1/1 100% [/10.32.3.220]0:1/1 100% 1:1/1 100% total: 100% 0.000KiB/s (avg: 0.074KiB/s)
INFO  12:02:41 [Stream #e013ee80-5863-11e9-8458-353e9e3cb7f9] All sessions completed
INFO  12:02:41 [Stream #e013ee80-5863-11e9-8458-353e9e3cb7f9] All sessions completed
INFO: ./apigee/data/cassandra/data/ks1/user-9fbae960571411e99652c7b15b2db6cc restored successfully
INFO: Restore 20190405011309 completed
INFO: ./apigee/data/cassandra/data/ks1/user-9fbae960571411e99652c7b15b2db6cc restored successfully
INFO: Restore 20190405011309 completed
waiting on waiting nodes $pid to finish  106
Restore finished

Backupjob prüfen

Sie können den Backupjob auch nach der Planung Ihres Backup-Cronjobs prüfen. Nachdem der Cronjob geplant wurde, sollte etwa Folgendes angezeigt werden:

kubectl get pods

Die Ausgabe sieht etwa so aus:

NAME                                       READY     STATUS      RESTARTS   AGE
apigee-cassandra-default-0                 1/1       Running     0          2h
apigee-cassandra-default-1                 1/1       Running     0          2h
apigee-cassandra-default-2                 1/1       Running     0          2h
apigee-cassandra-backup-1.6451.680-pff6s   0/1       Running     0          54s

Backupprotokolle prüfen

Der Backup-Job:

Erstellt eine schema.cql-Datei.
Lädt den Speicher in Ihren Storage-Bucket hoch.
Weist den Knoten an, die Daten zu sichern und gleichzeitig hochzuladen.
Wartet, bis alle Daten hochgeladen sind.

kubectl logs -f apigee-cassandra-backup-1.6451.680-pff6s

Die Ausgabe sieht etwa so aus:

myusername-macbookpro:cassandra-backup-utility myusername$ kubectl logs -f apigee-cassandra-backup-1.64577680-f9sc4
starting apigee-cassandra-default-0 in default
starting apigee-cassandra-default-1 in default
starting apigee-cassandra-default-2 in default
35 46 57
waiting on process  35
Activated service account credentials for: [apigee-cassandra-backup-svc@gce-myusername.iam.gserviceaccount.com]
Activated service account credentials for: [apigee-cassandra-backup-svc@gce-myusername.iam.gserviceaccount.com]
Activated service account credentials for: [apigee-cassandra-backup-svc@gce-myusername.iam.gserviceaccount.com]
Requested creating snapshot(s) for [all keyspaces] with snapshot name [20190406190808] and options {skipFlush=false}
Snapshot directory: 20190406190808
INFO: backup created cassandra snapshot 20190406190808
tar: Removing leading `/' from member names
/apigee/data/cassandra/data/ks1/mytest3-37bc2df0587811e98e8d875b0ed64754/snapshots/
/apigee/data/cassandra/data/ks1/mytest3-37bc2df0587811e98e8d875b0ed64754/snapshots/20190406190808/
/apigee/data/cassandra/data/ks1/mytest3-37bc2df0587811e98e8d875b0ed64754/snapshots/20190406190808/mc-1-big-Data.db
Requested creating snapshot(s) for [all keyspaces] with snapshot name [20190406190808] and options {skipFlush=false}
Requested creating snapshot(s) for [all keyspaces] with snapshot name [20190406190808] and options {skipFlush=false}
Snapshot directory: 20190406190808
INFO: backup created cassandra snapshot 20190406190808
tar: Removing leading `/' from member names
/apigee/data/cassandra/data/system/hints-2666e20573ef38b390fefecf96e8f0c7/snapshots/
/apigee/data/cassandra/data/system/hints-2666e20573ef38b390fefecf96e8f0c7/snapshots/20190406190808/
/apigee/data/cassandra/data/system/hints-2666e20573ef38b390fefecf96e8f0c7/snapshots/20190406190808/manifest.json
/apigee/data/cassandra/data/system/prepared_statements-18a9c2576a0c3841ba718cd529849fef/snapshots/
/apigee/data/cassandra/data/system/prepared_statements-18a9c2576a0c3841ba718cd529849fef/snapshots/20190406190808/
/apigee/data/cassandra/data/system/prepared_statements-18a9c2576a0c3841ba718cd529849fef/snapshots/20190406190808/manifest.json
/apigee/data/cassandra/data/system/range_xfers-55d764384e553f8b9f6e676d4af3976d/snapshots/
/apigee/data/cassandra/data/system/range_xfers-55d764384e553f8b9f6e676d4af3976d/snapshots/20190406190808/
/apigee/data/cassandra/data/system/range_xfers-55d764384e553f8b9f6e676d4af3976d/snapshots/20190406190808/manifest.json
/apigee/data/cassandra/data/system/peer_events-59dfeaea8db2334191ef109974d81484/snapshots/
/apigee/data/cassandra/data/system/peer_events-59dfeaea8db2334191ef109974d81484/snapshots/20190406190808/
/apigee/data/cassandra/data/system/peer_events-59dfeaea8db2334191ef109974d81484/snapshots/20190406190808/manifest.json
/apigee/data/cassandra/data/system/built_views-4b3c50a9ea873d7691016dbc9c38494a/snapshots/
/apigee/data/cassandra/data/system/built_views-4b3c50a9ea873d7691016dbc9c38494a/snapshots/20190406190808/
/apigee/data/cassandra/data/system/built_views-4b3c50a9ea873d7691016dbc9c38494a/snapshots/20190406190808/manifest.json
……
/apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/
/apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/
/apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-3-big-Filter.db
/apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-2-big-CompressionInfo.db
/apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-2-big-Index.db
/apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-3-big-Statistics.db
/apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-2-big-Data.db
/apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-1-big-Index.db
/apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-1-big-Statistics.db
/apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-2-big-TOC.txt
/apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-2-big-Statistics.db
/apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-1-big-Summary.db
/apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-1-big-Filter.db
/apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-2-big-Summary.db
/apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-3-big-Index.db
/apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/manifest.json
/apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-2-big-Filter.db
/apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-2-big-Digest.crc32
/apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-3-big-Summary.db
/apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-3-big-Data.db
/apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-1-big-TOC.txt
/apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/schema.cql
/apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-3-big-CompressionInfo.db
/apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-1-big-Digest.crc32
/apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-3-big-TOC.txt
/apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-1-big-Data.db
/apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-3-big-Digest.crc32
/apigee/data/cassandra/data/ks2/user-d6d39d70586311e98e8d875b0ed64754/snapshots/20190406190808/mc-1-big-CompressionInfo.db
……
/tmp/tokens.txt
/ [1 files][    0.0 B/    0.0 B]
Operation completed over 1 objects.
/ [1 files][    0.0 B/    0.0 B]
Operation completed over 1 objects.
INFO: backup created tarball and transferred the file to gs://gce-myusername-apigee-cassandra-backup/apigeecluster/dc-1
INFO: removing cassandra snapshot
INFO: backup created tarball and transferred the file to gs://gce-myusername-apigee-cassandra-backup/apigeecluster/dc-1
INFO: removing cassandra snapshot
Requested clearing snapshot(s) for [all keyspaces]
INFO: Backup 20190406190808 completed
waiting on process  46
Requested clearing snapshot(s) for [all keyspaces]
INFO: Backup 20190406190808 completed
Requested clearing snapshot(s) for [all keyspaces]
waiting on process  57
INFO: Backup 20190406190808 completed
waiting result
to get schema from 10.32.0.28
INFO: /tmp/schema.cql has been generated
Activated service account credentials for: [apigee-cassandra-backup-svc@gce-myusername.iam.gserviceaccount.com]
tar: removing leading '/' from member names
tmp/schema.cql
Copying from <TDIN>...
/ [1 files][    0.0 B/    0.0 B]
Operation completed over 1 objects.
INFO: backup created tarball and transferred the file to gs://gce-myusername-apigee-cassandra-backup/apigeecluster/dc-1
finished uploading schema.cql

Validierung

Überprüfen Sie die Wiederherstellung. Testen Sie dazu die IP-Adresse Ihres Ingress-Objekts und testen Sie sie mit einem Teil des Traffics.

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

Rufen Sie in der Befehlszeile Ihre gcloud-Authentifizierungsdaten ab oder aktualisieren Sie sie, wie das folgende Beispiel zeigt:
```
TOKEN=$(gcloud auth print-access-token)
```

Testen Sie den eingehenden Traffic mit einem vorhandenen API-Proxy, der zusammen mit einem API-Schlüssel oder Zugriffstoken in Ihrer Apigee-Umgebung bereitgestellt wird:

Curl -v https://EXTERNAL-IP/basepath -H 'envgroup hostalias'

Beispiel:

curl -v 'https://example.com/oauth/client_credential' \
  --resolve edgehybrid-staging-func-runtime-wf.hybrid.e2e.apigeeks.net:443:34.56.78.90 \
  -H 'Authorization: Bearer ${TOKEN}'

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.