Vista geral da restauro do Cassandra

Esta página fornece uma vista geral da restauração do Cassandra no Apigee Hybrid.

Porquê usar a opção de restauro?

Pode usar cópias de segurança para restaurar a infraestrutura do Apigee desde o início em caso de falhas catastróficas, como perda de dados irrecuperável na sua instância híbrida do Apigee devido a um desastre. O restauro transfere os dados da localização da cópia de segurança e restaura-os num novo cluster do Cassandra com o mesmo número de nós. Não são usados dados de clusters do cluster do Cassandra antigo. O objetivo do processo de restauro é repor uma instalação híbrida do Apigee num estado operacional anterior através de dados de cópia de segurança de um instantâneo.

A utilização de cópias de segurança para restaurar não é recomendada nos seguintes cenários:

  • Falhas do nó do Cassandra.
  • Eliminação acidental de dados, como apps, developers e api_credentials.
  • Uma ou mais regiões a ficarem indisponíveis numa implementação híbrida de várias regiões.

As implementaçõ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 multirregional recomendada do híbrido significa que é possível recuperar de uma falha de região a partir de outra região ativa através de procedimentos de desativação e expansão de regiões, em vez de restaurar a partir de uma cópia de segurança.

Antes de começar a implementar um restauro a partir de uma cópia de segurança do Cassandra, tenha em atenção o seguinte:

  • Período de descanso: haverá um período de descanso durante o restauro.
  • Perda de dados: vai ocorrer uma perda de dados entre a última cópia de segurança válida e o momento em que a restauração estiver concluída.
  • Tempo de restauro: o tempo de restauro depende do tamanho dos dados e do cluster.
  • Selecionar dados específicos: não pode selecionar apenas dados específicos para restaurar. A restauração restaura toda a cópia de segurança que selecionar.

Restauros multirregionais

Se instalou o Apigee hybrid em várias regiões, tem de verificar o ficheiro de substituições da região para a qual está a fazer o restauro para se certificar de que cassandra:hostNetwork está definido como false antes de fazer o restauro. Para mais informações, consulte o artigo Restaurar em várias regiões.

Pré-requisitos

Verifique se todos os seguintes pré-requisitos foram cumpridos com êxito. Investigue quaisquer falhas de pré-requisitos antes de prosseguir com o restauro.

  1. Verifique se todos os pods do Cassandra estão em funcionamento com o seguinte comando. 
    kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

    O resultado deve ter um aspeto semelhante ao seguinte exemplo: 

    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 conjunto com estado do Cassandra mostra que todos os pods estão em execução com o seguinte comando. 
    kubectl get sts -n APIGEE_NAMESPACE -l app=apigee-cassandra

    O resultado deve ter um aspeto semelhante ao seguinte exemplo: 

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

    O resultado deve ter um aspeto semelhante ao seguinte exemplo: 

    NAME      STATE     AGE
default   running   16m
  4. Valide se todos os PVCs do Cassandra estão no estado Bound com o seguinte comando. 
    kubectl get pvc -n APIGEE_NAMESPACE -l app=apigee-cassandra

    O resultado deve ter um aspeto semelhante ao seguinte exemplo: 

    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 no estado Bound com o seguinte comando. 
    kubectl get pv -n APIGEE_NAMESPACE

    O resultado deve ter um aspeto semelhante ao seguinte exemplo: 

    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. Valide se o recurso Apigee Controller está no estado Running com o seguinte comando. 
    kubectl get pods -n APIGEE_NAMESPACE-system -l app=apigee-controller

    O resultado deve ter um aspeto semelhante ao seguinte exemplo: 

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

Como restaurar?

Os passos de restauro do Cassandra diferem ligeiramente consoante o seu Apigee hybrid esteja implementado numa única região ou em várias regiões. Para ver os passos detalhados de restauro, consulte a seguinte documentação: