Backup e recuperação do Cassandra

Esta seção aborda como configurar o backup e a recuperação de dados para o anel de banco de dados do Apache Cassandra instalado no plano de ambiente de execução da Apigee híbrida. Consulte também o repositório de dados do Cassandra.

Por que os backups do Cassandra são importantes

Os backups são uma medida importante de proteção contra cenários de desastres. Cada backup é um snapshot consistente dos dados atuais do Cassandra que existiam no momento em que o backup foi criado. Isso inclui os dados do Cassandra com o esquema / metadados no cluster do Cassandra. Os backups permitem que os usuários restaurem a instância híbrida da Apigee para um estado bom conhecido anteriormente, um passo crucial para colocar uma instância híbrida novamente on-line em caso de desastre. Dependendo do tamanho da instância híbrida, pode haver um ou vários arquivos de backup para um único conjunto de backups. Por exemplo, se a instância híbrida tiver três nós do Cassandra, o conjunto de backup conterá três arquivos de backup. Se a instância híbrida tiver 30 nós do Cassandra, o conjunto de backup conterá 30 arquivos de backup. Isso significa que o tempo para restaurar uma instância híbrida a partir de um backup depende de quantos arquivos de backup em um conjunto de backup precisam ser restaurados.

O que você precisa saber sobre os backups do Cassandra

O Cassandra é um banco de dados replicado configurado para ter pelo menos 3 cópias dos dados em cada região ou data center. O Cassandra usa replicação de streaming e reparos de leitura para manter as réplicas de dados em cada região ou data center em um determinado ponto.

Em modelos híbridos, os backups do Cassandra não são ativados por padrão.No entanto, essa é uma prática recomendada para ativar os backups do Cassandra no caso de perda de dados devido a uma falha catastrófica. Os backups do Cassandra destinam-se ao uso em casos de recuperação de desastres e não para restaurar a perda de dados causada pela exclusão acidental.

Os backups são criados de acordo com a programação definida no arquivo overrides.yaml. Consulte a seção Como programar backups do Cassandra para instruções sobre como programar backups. Depois que uma programação de backup é aplicada ao cluster híbrido, um job de backup do Kubernetes é executado periodicamente de acordo com a programação. O job aciona um script de backup em cada nó do Cassandra no cluster híbrido que coleta todos os dados no nó, cria um arquivo dos dados e o envia para o bucket de armazenamento do Google Cloud especificado em a configuração de backup do Cassandra no arquivo overrides.yaml.

O que é incluído no backup?

A configuração de backup descrita neste tópico faz backup das seguintes entidades:

Esquema do Cassandra, incluindo o esquema do usuário (definições de keyspace da Apigee).
Informações do token de partição do Cassandra por nó.
Um snapshot dos dados do Cassandra.

Onde os dados de backup são armazenados?

Os dados de backup são armazenados em um bucket do Google Cloud Storage que você precisa criar. A criação e a configuração do bucket são abordadas neste tópico.

Como programar backups do Cassandra

Os backups são programados como cron jobs no plano do ambiente de execução. Para programar backups do Cassandra, siga estas etapas:

Execute o comando create-service-account a seguir para criar uma conta de serviço (SA, na sigla em inglês) do Google Cloud com o papel padrão roles/storage.objectAdmin. Esse papel da SA permite gravar dados de backup no Cloud Storage. Execute o seguinte comando no diretório raiz da instalação híbrida:
```
../tools/create-service-account --env prod \
  --profile apigee-cassandra \
  --name CASSANDRA_BACKUP_SA_NAME \
  --dir OUTPUT_DIR
```
Em que:
- CASSANDRA_BACKUP_SA_NAME é o nome da conta de serviço.
- OUTPUT_DIR é o diretório em que a ferramenta gerará o arquivo .json da conta de serviço.
Exemplo:
```
./tools/create-service-account --env prod \
  --profile apigee-cassandra \
  --name my-cassandra-backup-sa  --dir ./service-accounts
```
Para mais informações sobre as contas de serviço do Google Cloud, consulte Como criar e gerenciar contas de serviço.
O comando create-service-account salva um arquivo JSON que contém a chave privada da conta de serviço. O arquivo é salvo no mesmo diretório em que o comando é executado. Você precisará do caminho desse arquivo nas etapas a seguir.
Crie um bucket do Cloud Storage. Especifique uma política de retenção de dados razoável para o bucket. A Apigee recomenda uma política de retenção de dados de 15 dias.
Abra o arquivo overrides.yaml.

Adicione as seguintes propriedades cassandra.backup para ativar o backup. Não remova nenhuma das propriedades já configuradas.

Parâmetros

cassandra:
  ...

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

  ...

Exemplo

...

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"

  ...

Propriedade	Descrição
`backup:enabled`	O backup está desativado por padrão. É preciso definir essa propriedade como `true`.
`backup:serviceAccountPath`	`SA_JSON_FILE_PATH` O caminho no sistema de arquivos para o arquivo JSON da conta de serviço que foi salvo quando você executou `./tools/create-service-account`
`backup:dbStorageBucket`	`CLOUD_STORAGE_BUCKET_PATH` O caminho do bucket do Cloud Storage neste formato: `gs://BUCKET_NAME`. O `gs://` é obrigatório.
`backup:schedule`	`BACKUP_SCHEDULE_CODE` O horário de início do backup, especificado na sintaxe padrão de crontab. Padrão: `0 2 * * ` Observação*: evite programar um backup que inicie pouco tempo depois de aplicar a configuração de backup ao cluster. Quando você aplica a configuração de backup, o Kubernetes recria os nós do Cassandra. Se o backup começar antes da reinicialização dos nós (possivelmente vários minutos), ele falhará.

Aplique as alterações de configuração ao novo cluster. Exemplo:
```
./apigeectl apply -f overrides.yaml
```

Verifique a tarefa de backup. Exemplo:

kubectl get cronjob -n apigee

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

Como restaurar backups

Use backups para restaurar a infraestrutura da Apigee desde o início em caso de falhas catastróficas, como a perda irrecuperável de todos os dados na instância híbrida da Apigee devido a um desastre. Esteja ciente de que você tem uma implantação de várias regiões, a recuperação de uma falha de região única deve usar a desativação para limpar a região afetada e, em seguida, use a expansão de DN na região afetada. As implantações e a arquitetura operacional do Apigee Cassandra cuidam da redundância e da tolerância a falhas para uma única região. Como é recomendável implantar a Apigee híbrida em uma configuração multirregional para casos de uso de produção, uma falha de região pode ser recuperada de uma das outras regiões ativas usando os procedimentos documentados de desativação e expansão da região de um backup.

Não use backups pelos seguintes motivos:

Falhas no nó do Cassandra.
Exclusão acidental de dados, como apps, developers e api_credentials.
Uma ou mais regiões caindo em uma implantação multirregional.

Considerações a serem consideradas ao restaurar:

Inatividade: haverá inatividade durante a restauração.
Perda de dados: haverá perda de dados entre o último backup válido e o momento em que a restauração é concluída.
Tempo de restauração: o tempo de restauração depende do tamanho dos dados e do cluster.
Dados da cereja: não é possível selecionar apenas dados específicos para restaurar. A restauração restaura todo o backup selecionado.

A restauração retira os dados do local de backup e os restaura em um novo cluster do Cassandra com o mesmo número de nós. Nenhum cluster de dados é retirado do cluster antigo do Cassandra.

As instruções de restauração abaixo se destinam a implantações de região única que usam o Google Cloud Storage para backups. Para outras implantações, consulte:

Para implantações de região única que não usam o Google Cloud Storage para backups, consulte Backup e recuperação sem o Google Cloud.
Para implantações multirregionais, consulte Implantação multirregional no GKE e no GKE On-Prem.

Para restaurar backups do Cassandra:

Crie um novo cluster do Kubernetes com um novo namespace para restaurar a implantação do ambiente de execução híbrido. Não é possível usar o mesmo cluster e namespace que você utilizou para a instalação híbrida original.
No diretório raiz da instalação híbrida, crie um novo arquivo overrides-restore.yaml.
Copie a configuração completa do arquivo overrides.yaml original para o novo overrides-restore.yaml. Exemplo:
```
cp ./overrides.yaml ./overrides-restore.yaml
```

No novo overrides-restore.yaml, adicione os elementos namespace e restore e verifique se as credenciais de autenticação de TLS nas propriedades cassandra estão corretas.

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

Exemplo

    ...

    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

    ...

Em que:

Propriedade	Descrição
`sslRootCAPath` `sslCertPath` `sslKeyPath`	`PATH_TO_ROOT_CA_FILE` `PATH_TO_SSL_CERT_FILE` `PATH_TO_SSL_KEY_FILE` Use as mesmas credenciais de autenticação TLS que você usou para criar o banco de dados original do Cassandra.
`namespace`	`YOUR_RESTORE_NAMESPACE` O nome do novo namespace que você criou na etapa 1 do novo cluster do Cassandra. Não use o mesmo namespace usado no cluster original.
`restore:enabled`	A restauração é desativada por padrão. É preciso definir essa propriedade como `true`.
`restore:snapshotTimestamp`	`TIMESTAMP` O carimbo de data/hora do snapshot de backup a ser restaurado. Para verificar quais carimbos de data/hora podem ser usados, acesse `dbStorageBucket` e observe os arquivos presentes no bucket. Cada nome de arquivo contém um valor de carimbo de data/hora como o seguinte: `backup_20210203213003_apigee-cassandra-default-0.tgz` Onde `20210203213003` é o valor `snapshotTimestamp` que você usaria se quisesse restaurar os backups criados nesse momento.
`restore:serviceAccountPath`	`SA_JSON_FILE_PATH` O caminho no sistema de arquivos para a conta de serviço que você criou para o backup.
`restore:dbStorageBucket`	`CLOUD_STORAGE_BUCKET_PATH` O caminho do bucket do Cloud Storage em que os dados de backup são armazenados no seguinte formato: `gs://BUCKET_NAME` O `gs://` é obrigatório.

Altere o rótulo app em qualquer nó do Cassandra no namespace antigo. Para isso, execute o seguinte comando:
```
kubectl label pods --overwrite --namespace=OLD_NAMESPACE -l app=apigee-cassandra app=apigee-cassandra-old
```
Crie uma nova implantação híbrida de ambiente de execução. Isso criará um novo cluster do Cassandra e começará a restaurar os dados de backup no cluster:
```
./apigeectl init  -f ../overrides-restore.yaml
```
```
./apigeectl apply  -f ../overrides-restore.yaml
```
Após a conclusão da restauração, o tráfego precisa ser alternado para usar o cluster do Cassandra no novo namespace. Execute os comandos a seguir para alternar o tráfego:
```
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}}'
```
Quando a alternância de tráfego for concluída, é possível reconfigurar os backups no cluster restaurado removendo a configuração restore e adicionando a configuração backup ao arquivo overrides-restore.yaml. Substitua YOUR_RESTORE_NAMESPACE pelo novo nome do namespace criado na etapa 1.
```
namespace: YOUR_RESTORE_NAMESPACE
cassandra:
  ...
   backup:
    enabled: true
    serviceAccountPath: SA_JSON_FILE_PATH
    dbStorageBucket: CLOUD_STORAGE_BUCKET_PATH
    schedule: BACKUP_SCHEDULE_CODE
  ...
```
Em seguida, aplique a configuração backup com o seguinte comando:
```
./apigeectl apply  -f ../overrides-restore.yaml
```

Como ver os registros de restauração

Verifique os registros do job de restauração e use grep para verificar error se o registro de restauração não tem erros.

Verificar se a restauração foi concluída

Use o seguinte comando para verificar se a operação de restauração foi concluída:

kubectl get pods

A resposta será semelhante a:

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

Ver os registros de restauração

Use o seguinte comando para ver os registros de restauração:

kubectl logs -f apigee-cassandra-restore-b4lgf

A resposta será semelhante a:

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

Verificar o job de backup

Também é possível verificar o job de backup depois que o cron job de backup estiver programado. Depois que o cron job for programado, você verá algo mais ou menos assim:

kubectl get pods

A resposta será semelhante a:

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

Verificar os registros de backup

O job de backup:

cria um arquivo schema.cql;
faz upload dele para seu bucket de armazenamento;
repete o nó para fazer backup dos dados e fazer upload deles ao mesmo tempo;
aguarda até que todos os dados sejam enviados.

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

A saída será assim:

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

Validação

Valide a restauração testando o endereço IP da entrada e testando-o com algum tráfego.

Receba o EXTERNAL-IP com o seguinte 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

Na linha de comando, receba ou atualize as credenciais de autenticação da gcloud, como mostra o exemplo a seguir:
```
TOKEN=$(gcloud auth print-access-token)
```

Teste a entrada usando um apiproxy existente implantado no ambiente da Apigee com a chave de API ou o token de acesso:

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

Exemplo:

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

Configuração de DNS para novo cluster e transição de tráfego

Quando estiver satisfeito com a validação, redirecionar o tráfego para o novo cluster e alterar a entrada dns para o novo endereço EXTERNAL-IP de entrada.