Présentation de la restauration Cassandra

Cette page explique comment restaurer Cassandra dans Apigee hybrid.

Pourquoi utiliser la restauration ?

Vous pouvez utiliser des sauvegardes pour restaurer entièrement l'infrastructure Apigee en cas de défaillances catastrophiques, telles qu'une perte de données irrécupérable dans votre instance hybride Apigee. La restauration extrait vos données de l'emplacement de sauvegarde et les restaure dans un nouveau cluster Cassandra présentant le même nombre de nœuds. Aucune donnée de cluster n'est extraite de l'ancien cluster Cassandra. L'objectif du processus de restauration est de rétablir un état d'origine opérationnel de l'installation d'Apigee hybrid à l'aide des données de sauvegarde d'un instantané.

L'utilisation de sauvegardes pour restaurer n'est pas recommandée dans les scénarios suivants :

Défaillances de nœuds Cassandra.
Suppression accidentelle de données telles que apps, developers et api_credentials.
Panne d'une ou plusieurs régions dans un déploiement hybride multirégional.

Les déploiements et l'architecture opérationnelle d'Apigee Cassandra prennent en charge la redondance et la tolérance aux pannes d'une seule région. Dans la plupart des cas, la mise en œuvre multirégionale de production recommandée pour l'environnement hybride signifie qu'une défaillance régionale peut être récupérée à partir d'une autre région à l'aide de procédures de mise hors service et d'expansion des régions au lieu d'une restauration à partir d'une sauvegarde.

Avant de commencer la mise en œuvre d'une restauration à partir d'une sauvegarde Cassandra, tenez compte des points suivants :

Temps d'arrêt : un temps d'arrêt survient pendant toute la durée de la restauration.
Perte de données : il y a une perte de données entre la dernière sauvegarde valide et la fin de la restauration.
Heure de restauration : la durée de la restauration dépend de la taille des données et du cluster.
Sélection de données :vous ne pouvez pas sélectionner uniquement certaines données spécifiques à restaurer. La restauration restaure l'intégralité de la sauvegarde que vous avez sélectionnée.

Prérequis

Vérifiez que toutes les conditions préalables suivantes sont bien remplies. Analysez tout manquement à ces conditions préalables avant de procéder à la restauration.

Vérifiez, à l'aide de la commande suivante, que tous les pods Cassandra fonctionnent correctement :

kubectl get pods -n apigee -l app=apigee-cassandra

La sortie doit se présenter sous la forme suivante :

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 %

Vérifiez, à l'aide de la commande suivante, que le StatefulSet Cassandra indique que tous les pods sont en cours d'exécution :
```
kubectl get sts -n apigee -l app=apigee-cassandra
```
La sortie doit se présenter sous la forme suivante :
```
NAME                       READY   AGE
apigee-cassandra-default   3/3     15m
    
```
Vérifiez, à l'aide de la commande suivante, que la ressource ApigeeDatastore est à l'état running :
```
kubectl get apigeeds -n apigee
```
La sortie doit se présenter sous la forme suivante :
```
NAME      STATE     AGE
default   running   16m
    
```

Vérifiez, à l'aide de la commande suivante, que tous les PVC Cassandra sont à l'état Bound :

kubectl get pvc -n apigee -l app=apigee-cassandra

La sortie doit se présenter sous la forme suivante :

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

Vérifiez, à l'aide de la commande suivante, que tous les PV Cassandra sont à l'état Bound :

kubectl get pv -n apigee

La sortie doit se présenter sous la forme suivante :

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

Vérifiez, à l'aide de la commande suivante, que la ressource de contrôleur Apigee est à l'état Running :

kubectl get pods -n apigee-system -l app=apigee-controller

La sortie doit se présenter sous la forme suivante :

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

Procédure de restauration

Les étapes de restauration de Cassandra diffèrent légèrement selon que votre Apigee hybrid est déployé dans une ou plusieurs régions. Pour obtenir la procédure de restauration détaillée, consultez la documentation suivante :