Informações gerais da restauração do Cassandra

Nesta página, fornecemos uma visão geral da restauração do Cassandra na Apigee híbrida.

Por que usar a restauração?

É possível usar backups para restaurar a infraestrutura da Apigee desde o início, em caso de falhas catastróficas, como perda de dados irrecuperável na sua instância híbrida da Apigee de um desastre. 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. O objetivo do processo de restauração é trazer uma instalação da Apigee híbrida de volta ao estado anteriormente operacional usando dados de backup de um snapshot.

O uso de backups para restauração não é recomendado nos seguintes cenários:

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

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. Na maioria dos casos, a implementação de produção híbrida multirregional recomendada significa que uma falha de região pode ser recuperada de outra região ativa usando procedimentos de desativação e expansão de região em vez de restaurar um backup. de dados.

Antes de começar a implementar uma restauração de um backup do Cassandra, esteja ciente do seguinte:

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

Pré-requisitos

Verifique se todos os pré-requisitos a seguir foram atendidos. Investigue qualquer falha de pré-requisito antes de prosseguir com a restauração.

  1. Verifique se todos os pods do Cassandra estão funcionando com o comando a seguir. 
    kubectl get pods -n apigee -l app=apigee-cassandra

    As saídas terão a aparência do exemplo a seguir: 

    NAME                         READY   STATUS    RESTARTS   AGE
apigee-cassandra-default-0   1/1     Running   0          14m
apigee-cassandra-default-1   1/1     Running   0          13m
apigee-cassandra-default-2   1/1     Running   0          11m
exampleuser@example hybrid-files %
  2. Verifique se o statefulset do Cassandra mostra que todos os pods estão em execução com o comando a seguir. 
    kubectl get sts -n apigee -l app=apigee-cassandra

    As saídas terão a aparência do exemplo a seguir: 

    NAME                       READY   AGE
apigee-cassandra-default   3/3     15m
  3. Verifique se o recurso ApigeeDatastore está no estado running com o comando a seguir. 
    kubectl get apigeeds -n apigee

    As saídas terão a aparência do exemplo a seguir: 

    NAME      STATE     AGE
default   running   16m
  4. Verifique se todos os PVCs do Cassandra estão com status Bound usando o comando a seguir. 
    kubectl get pvc -n apigee -l app=apigee-cassandra

    As saídas terão a aparência do exemplo a seguir: 

    NAME                                        STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
cassandra-data-apigee-cassandra-default-0   Bound    pvc-a14184e7-8745-4b30-8069-9d50642efe04   10Gi       RWO            standard-rwo   17m
cassandra-data-apigee-cassandra-default-1   Bound    pvc-ed129dcb-4706-4bad-a692-ac7c78bad64d   10Gi       RWO            standard-rwo   15m
cassandra-data-apigee-cassandra-default-2   Bound    pvc-faed0ad1-9019-4def-adcd-05e7e8bb8279   10Gi       RWO            standard-rwo   13m
  5. Verifique se todos os PVs do Cassandra estão com status Bound usando o comando a seguir. 
    kubectl get pv -n apigee

    As saídas terão a aparência do exemplo a seguir: 

    NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                                              STORAGECLASS   REASON   AGE
pvc-a14184e7-8745-4b30-8069-9d50642efe04   10Gi       RWO            Delete           Bound    apigee/cassandra-data-apigee-cassandra-default-0   standard-rwo            17m
pvc-ed129dcb-4706-4bad-a692-ac7c78bad64d   10Gi       RWO            Delete           Bound    apigee/cassandra-data-apigee-cassandra-default-1   standard-rwo            16m
pvc-faed0ad1-9019-4def-adcd-05e7e8bb8279   10Gi       RWO            Delete           Bound    apigee/cassandra-data-apigee-cassandra-default-2   standard-rwo            14m
  6. Verifique se o recurso controlador da Apigee está no status "Em execução" com o comando a seguir. 
    kubectl get pods -n apigee-system -l app=apigee-controller

    As saídas terão a aparência do exemplo a seguir: 

    NAME                                         READY   STATUS    RESTARTS   AGE
apigee-controller-manager-856d9bb7cb-cfvd7   2/2     Running   0          20m

Como restaurar?

As etapas de restauração do Cassandra vão ser um pouco diferentes se a Apigee híbrida for implantada em uma ou várias regiões. Para ver as etapas de restauração detalhadas, consulte a seguinte documentação: