Effectuer une restauration dans plusieurs régions

Cette page explique comment restaurer Cassandra dans plusieurs régions.

Dans un déploiement multirégional, Apigee hybrid est déployé dans plusieurs emplacements géographiques situés dans différents centres de données. Il est important de noter que, si vous avez plusieurs organisations Apigee dans votre déploiement, le processus de restauration restaure les données pour toutes les organisations. Dans une configuration comportant plusieurs organisations, la restauration d'une organisation spécifique n'est pas acceptée.

Restaurer Cassandra

Dans un déploiement multirégional, il existe deux façons de récupérer une région ayant échoué. Cet article décrit les approches suivantes :

Récupérer des régions ayant échoué : décrit la procédure de récupération des régions ayant échoué en fonction d'une région opérationnelle.
Restaurer la ou les régions ayant échoué : décrit la procédure à suivre pour restaurer la ou les régions ayant échoué à partir d'une sauvegarde. Cette approche n'est requise que si toutes les régions hybrides sont affectées.

Récupérer des régions ayant échoué

Pour récupérer une ou plusieurs régions ayant échoué à partir d'une région opérationnelle, procédez comme suit :

Redirigez le trafic de l'API des régions concernées vers la région opérationnelle. Planifiez la capacité en conséquence pour gérer le trafic détourné des régions défaillantes.
Mettez hors service la région concernée. Pour chaque région affectée, suivez les étapes décrites dans la section Mettre hors service une région hybride. Attendez la fin de la mise hors service avant de passer à l'étape suivante.
Restaurez la région affectée. Pour effectuer une restauration, créez une région comme décrit dans la section Déploiement multirégional sur GKE, GKE On-Prem et AKS.

Effectuer une restauration à partir d'une sauvegarde

Remarque : Si vous souhaitez conserver une configuration existante pour le dépannage et l'analyse des causes fondamentales, vous devez supprimer tous les composants org et env du Cluster Kubernetes à l'exception du contrôleur Apigee, et conserver le cluster Le cluster inclut le datastore Apigee existant (Cassandra) qui peut vous permettre de résoudre des problèmes. Créez un cluster Kubernetes, puis restaurez Cassandra dans le nouveau cluster.

En fonction de votre configuration, la sauvegarde Cassandra peut se trouver sur Cloud Storage ou sur un serveur distant. Pour restaurer Cassandra à partir d'une sauvegarde, procédez comme suit :

Supprimez le déploiement hybride Apigee de toutes les régions :
```
apigeectl delete -f overrides.yaml
```
Restaurez la région souhaitée à partir d'une sauvegarde. Pour en savoir plus, consultez la section Restaurer une région à partir d'une sauvegarde.
Supprimez les références des régions supprimées et ajoutez les références des régions restaurées dans les métadonnées KeySpaces.

Récupérez le nom de la région à l'aide de l'option 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

Mettez à jour la réplication KeySpaces.
1. Créez un conteneur client et connectez-vous au cluster Cassandra via l'interface CQL.
2. Obtenez la liste des espaces de clés utilisateur à partir de l'interface CQL :
```
cqlsh ${CASSANDRA_SEEDS} -u ${CASS_USERNAME} -p ${CASS_PASSWORD}
            --ssl -e "select keyspace_name from system_schema.keyspaces;"|grep -v system
```
3. Pour chaque espace de clés, exécutez la commande suivante à partir de l'interface CQL pour mettre à jour les paramètres de réplication :
```
ALTER KEYSPACE KEYSPACE_NAME WITH replication = {'class': 'NetworkTopologyStrategy', 'REGION_NAME':3};
```
  où :
  - KEYSPACE_NAME correspond au nom de l'espace de clés répertorié dans la sortie de l'étape précédente.
  - REGION_NAME correspond au nom de la région obtenu à l'étape 4.