Como restaurar em várias regiões

Nesta página, descrevemos como recuperar ou restaurar o Cassandra em várias regiões.

Em uma implantação multirregional, a Apigee híbrida é implantada em vários locais geográficos em diferentes data centers. Se uma ou mais regiões falharem, mas as regiões íntegras permanecerem, use uma região íntegra para recuperar as regiões do Cassandra com falha que tenham os dados mais recentes.

Em caso de falha catastrófica de todas as regiões híbridas, é possível restaurar o Cassandra. É importante observar que, se você tiver várias organizações da Apigee na implantação, o processo de restauração restaura dados para todas as organizações. Em uma configuração de várias organizações, a restauração de apenas uma organização específica não é compatível.

Neste tópico, descrevemos as duas abordagens para salvar regiões com falha:

Recuperar regiões com falha: descreve as etapas para recuperar regiões com falha com base em uma região íntegra.
Restaurar regiões com falha: descreve as etapas para restaurar regiões com falha de um backup. Essa abordagem só será necessária se todas as regiões híbridas forem afetadas.

Recuperar regiões com falha

Para recuperar as regiões com falha de uma região íntegra, siga estas etapas:

Redirecione o tráfego da API das regiões afetadas para a boa região de trabalho. Planeje a capacidade de acordo com o tráfego desviado de regiões com falha.
Desativar a região afetada. Para cada região afetada, siga as etapas descritas em Desativar uma região híbrida. Aguarde a conclusão da desativação antes de passar para a próxima etapa.
Restaure a região afetada. Para restaurar, crie uma nova região, conforme descrito em Implantação multirregional no GKE, GKE On-Prem e AKS.

Como restaurar de um backup

Observação: se você quiser preservar uma configuração existente para a solução de problemas e a análise da causa raiz (RCA), exclua todos os componentes org e env da Cluster do Kubernetes exceto o controlador da Apigee e reter o cluster. O cluster vai ter o armazenamento de dados da Apigee (Cassandra) atual que pode ser usado para solução de problemas. Em seguida, crie um novo cluster do Kubernetes e restaure o Cassandra no novo cluster.

O backup do Cassandra pode residir no Cloud Storage ou em um servidor remoto com base na sua configuração. Para restaurar o Cassandra de um backup, execute as seguintes etapas:

Importante: se você instalou a Apigee híbrida em várias regiões, verifique o arquivo de modificação da região que está sendo restaurada para garantir que cassandra:hostNetwork esteja definido como false antes de realizar a restauração. Para verificar a configuração hostNetwork na região que você está tentando restaurar, use este comando:

kubectl -n apigee get apigeeds -o=jsonpath='{.items[].spec.components.cassandra.hostNetwork}'

Abra o arquivo de modificação para a região que você quer restaurar.
Defina cassandra:hostNetwork como false.

Aplique o arquivo de substituições:

helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace apigee \
  -f OVERRIDES_FILE

Antes de continuar, verifique se hostNetwork está definido como false:

kubectl -n apigee get apigeeds -o=jsonpath='{.items[].spec.components.cassandra.hostNetwork}'

Exclua o modelo híbrido da região que você está restaurando:
```
helm delete DATASTORE_RELEASE_NAME \
  --namespace apigee
```
Em que DATASTORE_RELEASE_NAME é o nome da versão do armazenamento de dados que você instalou o Cassandra na região, por exemplo, datastore-region1.

Observação: tome cuidado com qual versão do componente de repositório de dados você vai excluir. É possível conferir as versões com o comando helm -n apigee ls.
Restaure a região desejada de um backup. Para mais informações, consulte Como restaurar uma região a partir de um backup.
Remova as referências de regiões excluídas e adicione as referências de regiões restauradas nos metadados KeySpaces.
Encontre o nome do data center do Cassandra usando a opção nodetool status.
```
kubectl exec -n apigee -it apigee-cassandra-default-0 -- bash
      nodetool  -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status |grep -i Datacenter
```
onde:
- APIGEE_JMX_USER é o nome de usuário do usuário das operações JMX do Cassandra. Usado para autenticar e se comunicar com a interface do Cassandra JMX. Confira cassandra:auth:jmx:username.
- APIGEE_JMX_PASSWORD é a senha do usuário das operações JMX do Cassandra. Confira cassandra:auth:jmx:password.
Atualize a replicação KeySpaces.
1. Crie um contêiner de cliente e conecte-se ao cluster do Cassandra por meio da interface CQL.
2. Veja a lista de keyspaces do usuário na interface CQL:
```
cqlsh CASSANDRA_SEED_HOST -u APIGEE_DDL_USER -p APIGEE_DDL_PASSWORD
      --ssl -e "select keyspace_name from system_schema.keyspaces;"|grep -v system
```
  onde:
  - CASSANDRA_SEED_HOST é o host de multirregião do Cassandra. Para a maioria das instalações multirregionais, use o endereço IP de um host na sua primeira região. Consulte Configurar a Apigee híbrida para várias regiões e cassandra:externalSeedHost.
  - APIGEE_DDL_USER e APIGEE_DDL_PASSWORD são o nome de usuário e a senha de administrador do usuário da Linguagem de definição de dados (DDL, na sigla em inglês) do Cassandra. Os valores padrão são "ddl_user" e "iloveapis123".
    É possível verificar o nome de usuário e a senha DDL verificando o valor armazenado no secret apigee-datastore-default-creds. (em inglês). Você precisa ter privilégios de administrador para verificar esse secret. O comando a seguir retornará valores codificados em base64 para o nome de usuário e a senha DDL:
```
kubectl get secret apigee-datastore-default-creds -n apigee -o yaml
```
    Consulte cassandra.auth.ddl.password na referência das propriedades de configuração e opções de linha de comando na documentação do Apache Cassandra cqlsh.
3. Para cada keyspace, execute o seguinte comando na interface CQL para atualizar as configurações de replicação:
```
ALTER KEYSPACE KEYSPACE_NAME WITH replication = {'class': 'NetworkTopologyStrategy', 'DATACENTER_NAME':3};
```
  onde:
  - KEYSPACE_NAME é o nome do espaço de chave listado na saída da etapa anterior.
  - DATACENTER_NAME é o nome do datacenter do Cassandra que você recebeu com a opção nodetool status na etapa 8.