Copia de seguridad y recuperación de Cassandra

En esta sección, se explica cómo configurar la copia de seguridad y recuperación de datos para el anillo de base de datos de Apache Cassandra instalado en el plano del entorno de ejecución Apigee Hybrid. Consulta también Almacén de datos de Cassandra.

¿Por qué son importantes las copias de seguridad de Cassandra?

Las copias de seguridad son una medida importante de protección contra situaciones de desastre. Cada copia de seguridad es una instantánea coherente de los datos actuales de Cassandra que existían en el momento en que se creó la copia de seguridad. Esto incluye los datos de Cassandra junto con el esquema o los metadatos dentro del clúster de Cassandra. Las copias de seguridad permiten a los usuarios restablecer su instancia de Apigee Hybrid a un estado adecuado conocido, un paso fundamental para volver a conectar una instancia de Hybrid en caso de que ocurra un desastre. Según el tamaño de la instancia de Hybrid, puede haber uno o varios archivos de copia de seguridad para un solo conjunto de copia de seguridad. Por ejemplo, si la instancia de Hybrid tiene tres nodos de Cassandra, el conjunto de copia de seguridad contiene tres archivos de copia de seguridad. Si la instancia de Hybrid tiene treinta nodos de Cassandra, el conjunto de copia de seguridad contiene treinta archivos de copia de seguridad. Esto significa que el tiempo para restablecer una instancia de Hybrid desde una copia de seguridad depende de la cantidad de archivos de copia de seguridad de un conjunto de copia de seguridad que se deben restablecer.

Qué necesitas saber sobre las copias de seguridad de Cassandra

Cassandra es una base de datos replicada que está configurada para tener al menos 3 copias de tus datos en cada región o centro de datos. Cassandra usa la replicación de transmisión y las reparaciones de lectura para mantener las réplicas de datos en cada región o el centro de datos en un momento determinado.

En Hybrid, las copias de seguridad de Cassandra no están habilitadas de forma predeterminada. Sin embargo, se recomienda habilitar las copias de seguridad de Cassandra en caso de que los datos se pierdan debido a una falla catastrófica. Las copias de seguridad de Cassandra están diseñadas para su uso en casos de recuperación ante desastres y no para la pérdida de datos causada por la eliminación accidental.

Las copias de seguridad se crean según el programa que se establece en el archivo overrides.yaml. Consulta la sección Programa copias de seguridad de Cassandra para obtener instrucciones sobre cómo programar copias de seguridad. Una vez que se aplicó una programación de copia de seguridad al clúster de Hybrid, se ejecuta de forma periódica un trabajo de copia de seguridad de Kubernetes según la programación. El trabajo activa una secuencia de comandos de copia de seguridad en cada nodo de Cassandra del clúster de Hybrid que recopila todos los datos del nodo, crea un archivo de datos y envía el archivo al bucket de Google Cloud Storage especificado en la configuración de copia de seguridad de Cassandra en tu archivo overrides.yaml.

¿Qué elementos tiene una copia de seguridad?

La configuración de copia de seguridad descrita en este tema crea una copia de seguridad de las siguientes entidades:

Esquema de Cassandra que incluye el esquema del usuario (definiciones del espacio de claves de Apigee)
Información del token de partición de Cassandra por nodo
Una instantánea de los datos de Cassandra

¿Dónde se almacenan los datos de la copia de seguridad?

Los datos de copia de seguridad se almacenan en un bucket de Google Cloud Storage que debes crear. En este tema, se describe la creación y configuración de buckets.

Programa las copias de seguridad de Cassandra

Las copias de seguridad se programan como trabajos croncron en el plano del entorno de ejecución. Para programar copias de seguridad de Cassandra, sigue estos pasos:

Ejecuta el siguiente comando de create-service-account para crear una cuenta de servicio de Google Cloud con la función estándar roles/storage.objectAdmin. Esta función de la cuenta de servicio te permite escribir datos de copia de seguridad en Cloud Storage. Ejecuta el siguiente comando en el directorio raíz de instalación híbrida:
```
../tools/create-service-account --env prod \
  --profile apigee-cassandra \
  --name CASSANDRA_BACKUP_SA_NAME \
  --dir OUTPUT_DIR
```
Aquí:
- CASSANDRA_BACKUP_SA_NAME es el nombre de la cuenta de servicio.
- OUTPUT_DIR es el directorio donde la herramienta monstrará el archivo .json de la cuenta de servicio.
Por ejemplo:
```
./tools/create-service-account --env prod \
  --profile apigee-cassandra \
  --name my-cassandra-backup-sa  --dir ./service-accounts
```
Para obtener más información sobre las cuentas de servicio de Google Cloud, consulta Crea y administra cuentas de servicio.
El comando create-service-account guarda un archivo JSON que contiene la clave privada de la cuenta de servicio. El archivo se guarda en el mismo directorio en el que se ejecuta el comando. Necesitarás la ruta a este archivo en los siguientes pasos.
Crea depósitos de almacenamiento. Especifica una política de retención de datos razonable para el bucket. Apigee recomienda una política de retención de datos de 15 días.
Abre el archivo overrides.yaml.

Agrega las siguientes propiedades de cassandra.backup para habilitar la copia de seguridad. No quites ninguna de las propiedades que ya están configuradas.

Parámetros

cassandra:
  ...

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

  ...

Ejemplo

...

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"

  ...

Propiedad	Descripción
`backup:enabled`	La copia de seguridad está inhabilitada de forma predeterminada. Debes establecer esta propiedad en `true`.
`backup:serviceAccountPath`	`SA_JSON_FILE_PATH` La ruta de tu sistema de archivos al archivo JSON de la cuenta de servicio que se descargó cuando ejecutaste `./tools/create-service-account`
`backup:dbStorageBucket`	`CLOUD_STORAGE_BUCKET_PATH` Ruta de acceso del bucket de Cloud Storage con este formato: `gs://BUCKET_NAME`. `gs://` es obligatorio.
`backup:schedule`	`BACKUP_SCHEDULE_CODE` El momento en el que se inicia la copia de seguridad, especificado en sintaxis de crontab estándar. Predeterminada: `0 2 * * ` Nota:* Evita programar una copia de seguridad que comienza poco tiempo después de que aplicas la configuración de copia de seguridad al clúster. Cuando aplicas la configuración de copia de seguridad, Kubernetes vuelve a crear los nodos de Cassandra. La copia fallará si la copia de seguridad comienza antes de que los nodos se reinicien (posiblemente varios minutos).

Aplica los cambios de configuración al clúster nuevo. Por ejemplo:
```
./apigeectl apply -f overrides.yaml
```

Verifica el trabajo de copia de seguridad. Por ejemplo:

kubectl get cronjob -n apigee

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

Restablecer las copias de seguridad

Usa copias de seguridad para restablecer la infraestructura de Apigee desde cero en caso de fallas catastróficas, como la pérdida irrecuperable de todos los datos en la instancia de Apigee Hybrid debido a un desastre. Ten en cuenta que, si tienes una implementación multirregión, la recuperación ante una falla de una sola región debe utilizar el retiro de servicio para limpiar la región afectada y, luego, usar la expansión de DN en la región afectada. Las implementaciones de Apigee Cassandra y la arquitectura operativa se encargan de la redundancia y la tolerancia a errores para una sola región. Como se recomienda implementar Apigee Hybrid en una configuración multirregional para casos de uso de producción, una falla de región se puede recuperar de una de las otras regiones live con los procedimientos documentados de retiro de servicio y expansión de la región en lugar de recuperarse de una copia de seguridad.

No uses copias de seguridad por las siguientes razones:

Fallas en los nodos de Cassandra
Eliminación accidental de datos como aplicaciones, desarrolladores y api_credentials.
Una o más regiones fallan en una implementación multirregional.

Consideraciones para tener en cuenta cuando restablezcas:

Tiempo de inactividad: se producirá tiempo de inactividad durante el restablecimiento.
Pérdida de datos: se producirá una pérdida de datos entre la última copia de seguridad válida y el momento en que se completa el restablecimiento.
Tiempo de restablecimiento: el tiempo de restablecimiento depende del tamaño de los datos y el clúster.
Datos de selección: no puedes seleccionar solo datos específicos para restablecer. El restablecimiento restablece toda la copia de seguridad que seleccionaste.

El restablecimiento toma tus datos de la ubicación de la copia de seguridad y los restablece en un clúster de Cassandra nuevo con la misma cantidad de nodos. No se toman datos del clúster anterior de Cassandra.

Las siguientes instrucciones de restablecimiento se aplican a implementaciones de una sola región que usan Google Cloud Storage para copias de seguridad. Para otras implementaciones, consulta lo siguiente:

Para implementaciones de una sola región que no usan Google Cloud Storage para copias de seguridad, consulta Copia de seguridad y recuperación sin Google Cloud.
Para implementaciones multirregionales, consulta Implementación multirregional en GKE y GKE On-Prem.

Para restablecer copias de seguridad de Cassandra, haz lo siguiente:

Crea un clúster de Kubernetes nuevo con un espacio de nombres nuevo en el que se restablezca la implementación del entorno de ejecución híbrido. No puedes usar el mismo clúster o espacio de nombres que usaste para la instalación híbrida original.
En el directorio raíz de la instalación híbrida, crea un archivo overrides-restore.yaml nuevo.
Copia la configuración completa del archivo overrides.yaml original al archivo overrides-restore.yaml nuevo. Por ejemplo:
```
cp ./overrides.yaml ./overrides-restore.yaml
```

En el nuevo overrides-restore.yaml, agrega los elementos namespace y restore y asegúrate de que las credenciales de autenticación TLS en las propiedades cassandra sean correctas.

Parámetros

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

Ejemplo

    ...

    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

    ...

Aquí:

Propiedad	Descripción
`sslRootCAPath` `sslCertPath` `sslKeyPath`	`PATH_TO_ROOT_CA_FILE` `PATH_TO_SSL_CERT_FILE` `PATH_TO_SSL_KEY_FILE` Usa las mismas credenciales de autenticación TLS que usaste para crear la base de datos original de Cassandra.
`namespace`	`YOUR_RESTORE_NAMESPACE` El nombre del espacio de nombres nuevo que creaste en el paso 1 para el clúster de Cassandra nuevo. No uses el mismo espacio de nombres que usaste para tu clúster original.
`restore:enabled`	La opción para restablecer está inhabilitada de forma predeterminada. Debes establecer esta propiedad en `true`.
`restore:snapshotTimestamp`	`TIMESTAMP` La marca de tiempo de la instantánea de la copia de seguridad que se restablecerá. Para comprobar qué marcas de tiempo se pueden usar, ve a `dbStorageBucket` y consulta los archivos que están presentes en el bucket. Cada nombre de archivo contiene un valor de marca de tiempo como el siguiente: `backup_20210203213003_apigee-cassandra-default-0.tgz` En el ejemplo anterior, `20210203213003` es el valor `snapshotTimestamp` que usarías si quisieras restablecer las copias de seguridad creadas en ese momento.
`restore:serviceAccountPath`	`SA_JSON_FILE_PATH` La ruta de acceso del sistema de archivos a la cuenta de servicio que creaste para la copia de seguridad.
`restore:dbStorageBucket`	`CLOUD_STORAGE_BUCKET_PATH` La ruta del bucket de Cloud Storage en la que se almacenan tus datos de copia de seguridad en el siguiente formato: `gs://BUCKET_NAME` `gs://` es obligatorio.

Cambia la etiqueta app en todos los nodos de Cassandra en el espacio de nombres antiguo mediante la ejecución del siguiente comando:
```
kubectl label pods --overwrite --namespace=OLD_NAMESPACE -l app=apigee-cassandra app=apigee-cassandra-old
```
Crea una nueva implementación de entorno de ejecución híbrido. Esto creará un nuevo clúster de Cassandra y comenzará a restablecer los datos de copia de seguridad en el clúster:
```
./apigeectl init  -f ../overrides-restore.yaml
```
```
./apigeectl apply  -f ../overrides-restore.yaml
```
Una vez que se completa el restablecimiento, se debe cambiar el tráfico para usar el clúster de Cassandra en el espacio de nombres nuevo. Ejecuta los siguientes comandos para cambiar el tráfico:
```
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}}'
```
Una vez que finalice el cambio del tráfico, puedes volver a configurar las copias de seguridad en el clúster restablecido si quitas la configuración restore y agregas la configuración backup al archivo overrides-restore.yaml. Reemplaza YOUR_RESTORE_NAMESPACE por el nombre del espacio de nombres nuevo que creaste en el paso 1.
```
namespace: YOUR_RESTORE_NAMESPACE
cassandra:
  ...
   backup:
    enabled: true
    serviceAccountPath: SA_JSON_FILE_PATH
    dbStorageBucket: CLOUD_STORAGE_BUCKET_PATH
    schedule: BACKUP_SCHEDULE_CODE
  ...
```
Luego, aplica la configuración backup con el siguiente comando:
```
./apigeectl apply  -f ../overrides-restore.yaml
```

Visualiza los registros de restablecimiento

Puedes verificar los registros de trabajos de restablecimiento y usar grep para buscar error con el fin de asegurarte de que el registro de restablecimiento no tenga errores.

Verifica si se completó el restablecimiento

Usa el siguiente comando para comprobar si la operación de restablecimiento se completó:

kubectl get pods

El resultado es similar al siguiente:

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

Visualiza los registros de restablecimiento

Usa el siguiente comando para ver los registros de restablecimiento:

kubectl logs -f apigee-cassandra-restore-b4lgf

El resultado es similar al siguiente:

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 el trabajo de la copia de seguridad

También puedes verificar el trabajo de copia de seguridad después de que se programe tu trabajo cron de copia de seguridad. Después de programar el trabajo cron, deberías ver algo como lo siguiente:

kubectl get pods

El resultado es similar al siguiente:

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

Revisa los registros de copia de seguridad

El trabajo de copia de seguridad, haz lo siguiente:

Crea un archivo schema.cql.
Lo sube a tu bucket de almacenamiento.
Repite el nodo para realizar una copia de seguridad de los datos y subirlos al mismo tiempo.
Espera hasta que se suban todos los datos.

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

El resultado es similar a este:

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

Validación

Para validar el restablecimiento, prueba la dirección IP de Ingress y pruébala con algo de tráfico.

Obtén el EXTERNAL-IP con el siguiente 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

En la línea de comandos, obtén o actualiza las credenciales de autenticación de gcloud, como se muestra en el siguiente ejemplo:
```
TOKEN=$(gcloud auth print-access-token)
```

Prueba Ingress mediante un apiproxy existente implementado en tu entorno de Apigee junto con la clave de API o el token de acceso:

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

Por ejemplo:

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

Configuración de DNS para la migración de sistemas del clúster y el tráfico nuevos

Una vez que estés satisfecho con la validación, redirecciona el tráfico al clúster nuevo y cambia la entrada de DNS a la dirección EXTERNAL-IP de Ingress nueva.