Backup e ripristino di Cassandra

Questa sezione illustra come configurare il backup e il ripristino dei dati per l'anello del database Apache Cassandra installato nel piano di runtime ibrido Apigee. Vedi anche il datastore Casandra.

Perché i backup di Cassandra sono importanti

I backup rappresentano una misura importante di protezione dagli scenari di emergenza. Ogni backup è uno snapshot coerente dei dati attuali di Cassandra esistenti al momento della creazione del backup. Sono inclusi i dati Cassandra insieme a schemi / metadati all'interno del cluster Cassandra. I backup consentono agli utenti di ripristinare lo stato precedente di un'istanza ibrida Apigee, un passaggio fondamentale per ripristinare un'istanza ibrida in caso di emergenza. A seconda delle dimensioni dell'istanza ibrida, potrebbero essere presenti uno o più file di backup per un singolo set di backup. Ad esempio, se l'istanza ibrida ha tre nodi Cassandra, il set di backup contiene tre file di backup. Se l'istanza ibrida ha trenta nodi Cassandra, il set di backup contiene trenta file di backup. Ciò significa che il tempo necessario per ripristinare un'istanza ibrida da un backup dipende da quanti file di backup in un set di backup devono essere ripristinati.

Cosa devi sapere sui backup di Cassandra

Cassandra è un database replicato configurato per contenere almeno tre copie dei tuoi dati in ogni area geografica o data center. Cassandra utilizza la replica dei flussi di dati e le riparazioni in lettura per mantenere le repliche dei dati in ogni area geografica o data center in qualsiasi momento.

In un contesto ibrido, i backup di Cassandra non sono attivati per impostazione predefinita.È comunque buona norma attivarli in caso di perdita dei dati a causa di un errore catastrofico. I backup di Cassandra sono progettati per essere utilizzati in caso di ripristino di emergenza e non per ripristinare la perdita di dati causata da un'eliminazione accidentale.

I backup vengono creati in base alla pianificazione impostata nel file override.yaml. Consulta la sezione Pianificare i backup di Cassandra per istruzioni su come pianificare i backup. Dopo aver applicato una pianificazione di backup al tuo cluster ibrido, viene eseguito periodicamente un job di backup di Kubernetes in base alla pianificazione. Il job attiva uno script di backup su ogni nodo Cassandra nel tuo cluster ibrido, che raccoglie tutti i dati sul nodo, crea un file di archivio dei dati e invia l'archivio al bucket di archiviazione Google Cloud specificato nella configurazione di backup di Cassandra nel file override.yaml.

Che cos'è il backup?

La configurazione del backup descritta in questo argomento esegue il backup delle seguenti entità:

  • Schema di Cassandra che include lo schema utente (definizioni degli spazi dei chiavi Apigee)
  • Informazioni sul token di partizione Cassandra per nodo
  • Un'istantanea dei dati di Cassandra

Dove vengono archiviati i dati di backup?

I dati di cui hai effettuato il backup vengono archiviati in un bucket Google Cloud Storage che devi creare. La creazione e la configurazione dei bucket sono trattate in questo argomento.

Pianificazione dei backup Cassandra

I backup sono pianificati come job cron nel piano di runtime. Per pianificare i backup di Cassandra:

  1. Esegui il comando create-service-account seguente per creare un account di servizio Google Cloud (SA) con il ruolo standard roles/storage.objectAdmin. Questo ruolo SA consente di scrivere dati di backup in Cloud Storage. Esegui questo comando nella directory radice dell'installazione ibrida: 
    ../tools/create-service-account --env prod \
  --profile apigee-cassandra \
  --name CASSANDRA_BACKUP_SA_NAME \
  --dir OUTPUT_DIR

    Dove:

    • CASSANDRA_BACKUP_SA_NAME è il nome dell'account di servizio.
    • OUTPUT_DIR è la directory in cui lo strumento genererà il file .json dell'account di servizio.

    Ad esempio: 
    ./tools/create-service-account --env prod \
  --profile apigee-cassandra \
  --name my-cassandra-backup-sa  --dir ./service-accounts
    Per ulteriori informazioni sugli account di servizio Google Cloud, consulta l'articolo sulla creazione e gestione degli account di servizio.
  2. Il comando create-service-account salva un file JSON contenente la chiave privata dell'account di servizio. Il file viene salvato nella stessa directory in cui viene eseguito il comando. Per farlo, dovrai utilizzare il percorso a questo file:
  3. Crea un bucket Cloud Storage. Specifica un criterio di conservazione dei dati ragionevole per il bucket. Apigee consiglia un criterio di conservazione dei dati di 15 giorni.
  4. Apri il file overrides.yaml.
  5. Aggiungi le seguenti proprietà cassandra.backup per abilitare il backup. Non rimuovere nessuna delle proprietà già configurate.

    Parametri

    cassandra:
  ...

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

  ...

    Esempio

    ...

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"

  ...
    6. Dove:
    Proprietà Descrizione
    backup:enabled Il backup è disattivato per impostazione predefinita. Devi impostare questa proprietà su true.
    backup:serviceAccountPath

    SA_JSON_FILE_PATH

    Il percorso del file system al file JSON dell'account di servizio che è stato scaricato quando hai eseguito ./tools/create-service-account
    backup:dbStorageBucket

    CLOUD_STORAGE_BUCKET_PATH

    Percorso del bucket Cloud Storage in questo formato: gs://BUCKET_NAME. Il campo gs:// è obbligatorio.
    backup:schedule

    BACKUP_SCHEDULE_CODE

    L'ora di inizio del backup, specificata nella sintassi crontab standard. Valore predefinito: 0 2 * * *
  6. Applica le modifiche alla configurazione al nuovo cluster. Ad esempio: 
    ./apigeectl apply -f overrides.yaml
  7. Verifica il job di backup. Ad esempio: 
    kubectl get cronjob -n apigee
    NAME                      SCHEDULE     SUSPEND   ACTIVE   LAST SCHEDULE   AGE
apigee-cassandra-backup   33 * * * *   False     0        <none>          94s

Ripristino dei backup

Utilizza i backup per ripristinare completamente l'infrastruttura Apigee in caso di errori catastrofici, come tutti i dati nell'istanza di Apigee Hybrid, che andranno persi in modo irreversibile dopo una catastrofe. Tieni presente che se hai un deployment a più aree geografiche, il ripristino da un errore di una singola area geografica deve essere ritirato per pulire l'area geografica interessata, quindi utilizzare l'espansione di DN sull'area geografica interessata. I deployment e l'architettura operativa di Apigee Cassandra si occupano di ridondanza e tolleranza di errore per una singola area geografica. Poiché consigliamo di eseguire il deployment di Apigee Hybrid in una configurazione con più aree geografiche per i casi d'uso in produzione, un errore in un'area geografica può essere recuperato da una delle altre aree geografiche attive usando le procedure documentate per il ritiro e l'espansione, anziché eseguire il ripristino da un backup.

Non utilizzare i backup per i seguenti motivi:

  • Errori del nodo Cassandra.
  • Eliminazione accidentale di dati come app, sviluppatori e api_credentials.
  • Una o più aree geografiche in un deployment con più aree geografiche.

Considerazioni da tenere presenti durante il ripristino:

  • Tempo di inattività. Si verificherà un tempo di inattività della durata del ripristino.
  • Perdita dei dati:si verificherà una perdita di dati tra l'ultimo backup valido e il completamento del ripristino.
  • Tempo di ripristino: il tempo di ripristino dipende dalla dimensione dei dati e del cluster.
  • Dati sulla selezione dei ciliegi: non puoi selezionare solo i dati specifici da ripristinare. Il ripristino ripristina l'intero backup selezionato.

Il ripristino recupera i dati dalla località di backup e li ripristina in un nuovo cluster Cassandra con lo stesso numero di nodi. I dati del cluster non sono recuperati dal vecchio cluster Cassandra.

Le istruzioni di ripristino riportate di seguito si riferiscono ai deployment in una singola area geografica che utilizzano Google Cloud Storage per i backup. Per gli altri deployment, vedi:

Per ripristinare i backup di Cassandra:

  1. Crea un nuovo cluster Kubernetes con un nuovo spazio dei nomi in cui ripristinare il deployment del runtime ibrido. Non puoi utilizzare lo stesso cluster e lo stesso spazio dei nomi utilizzati per l'installazione ibrida originale.
  2. Crea un nuovo file overrides-restore.yaml nella directory di installazione ibrida di root.
  3. Copia la configurazione completa dal file overrides.yaml originale nel nuovo file overrides-restore.yaml. Ad esempio: 
    cp ./overrides.yaml ./overrides-restore.yaml
  4. Nei nuovi elementi overrides-restore.yaml, aggiungi elementi namespace e restore e assicurati che le credenziali di autenticazione TLS nelle proprietà cassandra siano corrette.

    Parametri

        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
      ...

    Esempio

        ...

    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

    ...

    Dove:

    Proprietà Descrizione
    sslRootCAPath
    sslCertPath
    sslKeyPath

    PATH_TO_ROOT_CA_FILE
    PATH_TO_SSL_CERT_FILE
    PATH_TO_SSL_KEY_FILE

    Utilizza le stesse credenziali di autenticazione TLS che hai utilizzato per creare il database di Cassandra originale.
    namespace

    YOUR_RESTORE_NAMESPACE

    Il nome del nuovo spazio dei nomi creato nel passaggio 1 per il nuovo cluster Cassandra. Non utilizzare lo stesso spazio dei nomi utilizzato per il cluster originale.
    restore:enabled Il ripristino è disattivato per impostazione predefinita. Devi impostare questa proprietà su true.
    restore:snapshotTimestamp

    TIMESTAMP

    Il timestamp dell'istantanea di backup da ripristinare. Per verificare quali timestamp possono essere utilizzati, vai a dbStorageBucket e controlla i file presenti nel bucket. Ogni nome di file contiene un valore di timestamp come il seguente:

    backup_20210203213003_apigee-cassandra-default-0.tgz

    Dove 20210203213003 è il valore snapshotTimestamp che utilizzeresti se volessi ripristinare i backup creati in quel momento.

    restore:serviceAccountPath

    SA_JSON_FILE_PATH

    Il percorso del tuo file system all'account di servizio che hai creato per il backup.
    restore:dbStorageBucket

    CLOUD_STORAGE_BUCKET_PATH

    Percorso del bucket Cloud Storage in cui sono archiviati i dati di backup nel seguente formato:

    gs://BUCKET_NAME

    Il campo gs:// è obbligatorio.

  5. Modifica l'etichetta app in tutti i nodi Cassandra nel vecchio spazio dei nomi eseguendo il comando seguente: 
    kubectl label pods --overwrite --namespace=OLD_NAMESPACE -l app=apigee-cassandra app=apigee-cassandra-old
  6. Crea un nuovo deployment di runtime ibrido. Verrà creato un nuovo cluster Cassandra e inizierà il ripristino dei dati di backup nel cluster: 
    ./apigeectl init  -f ../overrides-restore.yaml

    ./apigeectl apply  -f ../overrides-restore.yaml

  7. Una volta completato il ripristino, il traffico deve essere trasferito per utilizzare il cluster Cassandra nel nuovo spazio dei nomi. Esegui i seguenti comandi per cambiare il traffico: 

    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}}'
  8. Una volta completato il passaggio al traffico, puoi riconfigurare i backup sul cluster ripristinato rimuovendo la configurazione restore e aggiungendo la configurazione backup al file overrides-restore.yaml. Sostituisci YOUR_RESTORE_NAMESPACE con il nuovo nome dello spazio dei nomi creato nel passaggio 1. 
    namespace: YOUR_RESTORE_NAMESPACE
cassandra:
  ...
   backup:
    enabled: true
    serviceAccountPath: SA_JSON_FILE_PATH
    dbStorageBucket: CLOUD_STORAGE_BUCKET_PATH
    schedule: BACKUP_SCHEDULE_CODE
  ...

    Quindi applica la configurazione backup con il seguente comando: 

    ./apigeectl apply  -f ../overrides-restore.yaml

Visualizzazione dei log di ripristino

Puoi controllare i log del job di ripristino e utilizzare grep per cercare error, per assicurarti che non contenga errori.

Verificare il ripristino completato

Utilizza il seguente comando per verificare se l'operazione di ripristino è stata completata: 

kubectl get pods

L'output è simile al seguente: 

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

Visualizza i log di ripristino

Per visualizzare i log di ripristino, utilizza il comando seguente: 

kubectl logs -f apigee-cassandra-restore-b4lgf

L'output è simile al seguente: 

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

Verifica il job di backup

Puoi verificare il job di backup anche dopo aver pianificato il cronjob di backup. Dopo aver pianificato il cronjob, dovresti vedere qualcosa di simile a questo: 

kubectl get pods

L'output è simile al seguente: 

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

Controllare i log di backup

Il job di backup:

  • Crea un file schema.cql.
  • Carica l'elemento nel tuo bucket di archiviazione.
  • Ripulisce il nodo per eseguire il backup dei dati e li carica nello stesso momento.
  • Attendi che vengano caricati tutti i dati.
kubectl logs -f apigee-cassandra-backup-1.6451.680-pff6s

L'output è simile al seguente: 

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

Convalida

Convalida il ripristino testando l'indirizzo IP del tuo traffico in entrata e testandolo con del traffico.

  1. Ottieni EXTERNAL-IP con il seguente comando: 
    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

  2. Dalla riga di comando, recupera o aggiorna le credenziali di autenticazione gcloud, come illustrato nell'esempio seguente: 

    TOKEN=$(gcloud auth print-access-token)
  3. Testa l'ingress tramite un apiproxy esistente nel tuo ambiente Apigee insieme alla chiave API o al token di accesso: 
    Curl -v https://EXTERNAL-IP/basepath -H 'envgroup hostalias'

    Ad esempio: 

    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}'

Configurazione DNS per il nuovo cluster e la migrazione del traffico

Quando la convalida ti soddisfa, reindirizza il traffico al nuovo cluster e modifica la voce DNS in un nuovo indirizzo EXTERNAL-IP in entrata.