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ãoroles/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.
./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" ...
Em que:
- 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
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 |
backup:dbStorageBucket |
CLOUD_STORAGE_BUCKET_PATH O caminho do bucket do Cloud Storage neste formato: |
backup:schedule |
BACKUP_SCHEDULE_CODE O horário de início do backup, especificado na
sintaxe padrão de crontab. Padrão: |
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 novooverrides-restore.yaml
. Exemplo:cp ./overrides.yaml ./overrides-restore.yaml
- No novo
overrides-restore.yaml
, adicione os elementosnamespace
erestore
e verifique se as credenciais de autenticação de TLS nas propriedadescassandra
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_FILEUse 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çãobackup
ao arquivooverrides-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.