Cassandra-Backup und -Wiederherstellung

Sie sehen sich gerade die Version 1.1 der Apigee Hybrid-Dokumentation an. This version is end of life. You should upgrade to a newer version. Weitere Informationen finden Sie unter Unterstützte Versionen.

Version 1.1 (unsupported)

Unterstützte Versionen:

• v1.13 (aktuellste Version)                        
• v1.12                         
• v1.11                         
• Liste der unterstützten Versionen

Nicht unterstützte Versionen:

• v1.10                                      
• v1.9                                         
• v1.8                                         
• v1.7                                         
• v1.6                                         
• v1.5                                         
• v1.4                                         
• v1.3                                         
• v1.2                                         
• v1.1                                         

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

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 der Hybridversion sind Cassandra-Backups nicht standardmäßig aktiviert. Es empfiehlt sich jedoch, Cassandra-Backups zu aktivieren, falls Ihre Daten versehentlich gelöscht werden.

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 Backup-Daten 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 Cronjobs auf der Laufzeitebene geplant. So planen Sie Cassandra-Backups:

1. Führen Sie folgenden create-service-account-Befehl aus, um ein GCP-Dienstkonto (SA) mit der Standardrolle roles/storage.objectAdmin zu erstellen. Mit dieser SA-Rolle können Sie Sicherungsdaten in Google Cloud Storage (GCS) schreiben. Führen Sie folgenden Befehl im Stammverzeichnis der Hybrid-Installation aus:

   ./tools/create-service-account apigee-cassandra output-dir

   Beispiel:

   ./tools/create-service-account apigee-cassandra ./service-accounts

   Weitere Informationen zu GCP-Dienstkonten finden Sie unter Dienstkonten erstellen und verwalten.
2. 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.
3. GCS-Bucket erstellen. Legen Sie eine angemessene Daten-Aufbewahrungsrichtlinie für den Bucket fest. Apigee empfiehlt eine Datenaufbewahrungszeit von 15 Tagen.
4. Öffnen Sie Ihre overrides.yaml-Datei.
5. Fügen Sie folgende cassandra.backup-Attribute hinzu, um das Backup zu aktivieren. Entfernen Sie keine der bereits konfigurierten Attribute.

   cassandra:
     ...
   
     backup:
       enabled: true
       serviceAccountPath: sa_json_file_path
       dbStorageBucket: gcs_bucket_path
       schedule: backup_schedule_code
   
     ...

   Wobei:

   Attribut	Beschreibung
   enabled	Die Sicherung ist standardmäßig deaktiviert. Sie müssen dieses Attribut auf true festlegen.
   serviceAccountPath	Der Pfad in Ihrem Dateisystem zur JSON-Datei des Dienstkontos, die beim Ausführen von ./tools/create-service-account heruntergeladen wurde
   dbStorageBucket	Pfad zum GCS-Speicher-Bucket in folgendem Format: gs://bucket_name. gs:// ist erforderlich.
   schedule	Die Zeit, zu der das Backup startet, angegeben in der Standard-Crontab-Syntax. Standard: 0 2 * * * Hinweis: Planen Sie keine Backups, die kurz nach dem Anwenden der Backup-Konfiguration 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.

   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.json"
       dbStorageBucket: "gs://myname-cassandra-backup"
       schedule: "45 23 * * 6"
   
     ... 

6. Wenden Sie die Konfigurationsänderungen auf den neuen Cluster an. Beispiel:

   ./apigeectl apply -c 2_cassandra -v beta2

Backups wiederherstellen

Die Wiederherstellung übernimmt die Daten aus dem Sicherungsspeicherort und stellt sie in einem neuen Cassandra-Cluster mit derselben Anzahl an Pods wieder her. Der neue Cluster muss einen Namespace haben, der sich von Ihrem Cluster auf Laufzeitebene unterscheidet.

So stellen Sie Cassandra-Backups wieder her:

1. Einen neuen Kubernetes-Cluster mit einem neuen Namespace erstellen. Sie können nicht den Cluster/Namespace verwenden, den Sie für die ursprüngliche Hybridinstallation verwendet haben.
2. Erstellen Sie im Stammverzeichnis der Hybridinstallation eine neue overrides-restore.yaml-Datei.
3. Kopieren Sie die gesamte Cassandra-Konfiguration aus der ursprünglichen overrides.yaml-Datei in die neue.
4. Fügen Sie ein Namespace-Element hinzu. Verwenden Sie nicht denselben Namespace, den Sie für den ursprünglichen Cluster verwendet haben.

namespace: your-restore-namespace

cassandra:
  storage:
    type: gcepd
    capacity: 50Gi
    gcepd:
      replicationType: regional-pd
  nodeSelector:
    key: cloud.google.com/gke-nodepool
    value: apigee-data
  sslRootCAPath: path_to_root_ca_file
  sslCertPath: path_to_ssl_cert_file
  sslKeyPath: path_to_ssl_key_file
  auth:
    default:
      password: your_cassandra_password
    admin:
      password: admin_password
    ddl:
      password: ddl_password
    dml:
      password: dml_password

  restore:
      enabled: true
      snapshotTimestamp: timestamp
      serviceAccountPath: sa_json_file_path
      dbStorageBucket: gcs_bucket_path
      image:
        pullPolicy: Always

Wobei:

Attribut	Beschreibung
ssl*Path, auth.*	Verwenden Sie dieselben TLS-Authentifizierungsdaten, mit denen Sie auch die ursprüngliche Cassandra-Datenbank erstellt haben.
snapshotTimestamp	Der Zeitstempel des wiederherzustellenden Backup-Snapshots.
serviceAccountPath	Der Pfad in Ihrem Dateisystem zum Dienstkonto, das Sie für das Backup erstellt haben.
dbStorageBucket	Pfad zum GCS-Speicher-Bucket, in dem Ihre Sicherung gespeichert wird, in diesem Format: gs://bucket_name. gs:// ist erforderlich.

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: "20190417002207"
    serviceAccountPath: "/Users/myhome/.ssh/my_cassandra_backup.json"
    dbStorageBucket: "gs://myname-cassandra-backup"
    image:
      pullPolicy: Always

Dabei ist snapshotTimestamp der Zeitstempel für das Backup, das Sie wiederherstellen möchten.

5. Erstellen Sie den neuen Cassandra-Cluster:
   Wenn Sie eine neue oder geänderte Backup-Konfiguration auf Ihren Cluster anwenden, werden die vorhandenen Cassandra-Knoten neu gestartet.

     ./apigeectl apply -c 2_cassandra -v beta2 -f ./overrides-restore.yaml
     ./apigeectl apply -c 2_cassandra-role -v beta2 

Wiederherstellungslogs anzeigen

Sie können die Logs der Wiederherstellung und das grep für error prüfen, um sicherzustellen, dass das Wiederherstellungsprotokoll keine Fehler enthält.

Prüfen Sie, ob die Wiederherstellung abgeschlossen wurde

So prüfen Sie, ob der Wiederherstellungsvorgang abgeschlossen wurde:

kubectl get pods

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

Wiederherstellungsprotokolle anzeigen

So rufen Sie die Wiederherstellungslogs auf:

kubectl logs -f apigee-cassandra-restore-b4lgf

Restore Logs:

Activated service account credentials for: [[e-mail]]
to download file gs://gce-myusername-apigee-cassandra-backup/apigeecluster/dc-1/backup_20190405011309_schema.tgz
INFO: download sucessfully 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-0 in default
starting apigee-cassandra-1 in default
starting apigee-cassandra-2 in default
84 95 106
waiting on waiting nodes $pid to finish  84
Activated service account credentials for: [[e-mail]]
Activated service account credentials for: [[e-mail]]
Activated service account credentials for: [[e-mail]]
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.155]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.155]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
NAME                        READY     STATUS      RESTARTS   AGE
apigee-cassandra-0          1/1       Running     0          2h
apigee-cassandra-1          1/1       Running     0          2h
apigee-cassandra-2          1/1       Running     0          2h
apigee-cassandra-backup-1554515580-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-1554515580-pff6s

myusername-macbookpro:cassandra-backup-utility myusername$ kubectl logs -f apigee-cassandra-backup-1554577680-f9sc4
starting apigee-cassandra-0 in default
starting apigee-cassandra-1 in default
starting apigee-cassandra-2 in default
35 46 57
waiting on process  35
Activated service account credentials for: [[e-mail]]
Activated service account credentials for: [[e-mail]]
Activated service account credentials for: [[e-mail]]
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 transfered the file to gs://gce-myusername-apigee-cassandra-backup/apigeecluster/dc-1
INFO: removing cassandra snapshot
INFO: backup created tarball and transfered 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: [[e-mail]]
tar: removing leading '/' from member names
tmp/schema.cql
Copying from ...
/ [1 files][    0.0 B/    0.0 B]
Operation completed over 1 objects.
INFO: backup created tarball and transfered the file to gs://gce-myusername-apigee-cassandra-backup/apigeecluster/dc-1
finished uploading schema.cql