Cette page a été traduite par l'API Cloud Translation.

Effectuer un rollback d'Apigee Edge 4.53.00

Si vous rencontrez une erreur lors d'une mise à jour vers Edge 4.53.00, vous pouvez rétablir le composant à l'origine de l'erreur, puis réessayer la mise à jour.

Vous pouvez revenir à la version mineure suivante d'Edge 4.53.00 :

Version 4.52.02

Pour revenir à une version antérieure, vous devez revenir à la version précédente de chaque composant que vous avez peut-être mis à niveau. De plus, vous devez tenir compte de certains éléments lorsque vous restaurez Cassandra vers la version 4.52.02.

Il existe deux scénarios dans lesquels vous pouvez souhaiter effectuer une restauration :

Effectuez un rollback vers une version majeure ou mineure précédente. Par exemple, de la version 4.53.00 à la version 4.52.02.
Effectuez un rollback vers une version corrective précédente de la même version. Par exemple, de 4.53.00.01 à 4.53.00.00.

Pour en savoir plus, consultez la page Processus de publication d'Apigee Edge.

Ordre de rollback

La restauration des composants doit être effectuée dans l'ordre inverse de leur mise à niveau, à l'exception des serveurs de gestion, qui doivent être restaurés après Cassandra.

Voici un ordre général type de rétablissement pour Private Cloud 4.53.00 :

Restaurez Postgres, Qpid et d'autres composants liés aux données analytiques.
Rétablir les routeurs et les processeurs de messages
Rétablir Cassandra et Zookeeper
Effectuer un rollback du serveur de gestion

Par exemple, supposons que vous ayez mis à niveau l'ensemble du cluster Cassandra, tous vos serveurs de gestion et quelques RMP vers la version 4.53.00 à partir de la version 4.52.02 et que vous souhaitiez effectuer un rollback. Dans ce cas, vous devez :

Annuler tous les RMP un par un
Rétablir l'ensemble du cluster Cassandra à l'aide de sauvegardes
Rétablir les nœuds du serveur Edge Management un par un

Qui peut effectuer une restauration ?

L'utilisateur qui effectue le rollback doit être le même que celui qui a initialement mis à jour Edge ou un utilisateur exécuté en tant que root.

Par défaut, les composants Edge s'exécutent en tant qu'utilisateur "apigee". Dans certains cas, vous pouvez exécuter des composants Edge en tant qu'utilisateurs différents. Par exemple, si le routeur doit accéder à des ports privilégiés, tels que ceux inférieurs à 1000, vous devez l'exécuter en tant que root ou en tant qu'utilisateur ayant accès à ces ports. Vous pouvez également exécuter un composant en tant qu'utilisateur et un autre composant en tant qu'autre utilisateur.

Composants avec code commun

Les composants Edge suivants partagent un code commun. Par conséquent, pour effectuer un rollback de l'un de ces composants sur un nœud, vous devez effectuer un rollback de tous les composants présents sur ce nœud.

edge-management-server (serveur de gestion)
edge-message-processor (processeur de messages)
edge-router (routeur)
edge-postgres-server (serveur Postgres)
edge-qpid-server (serveur Qpid)

Par exemple, si le serveur de gestion, le routeur et le processeur de messages sont installés sur le nœud, vous devez effectuer un rollback des trois pour en annuler un.

Restauration de Cassandra

Lorsqu'une mise à niveau majeure de Cassandra est effectuée sur un nœud spécifique, Cassandra modifie le schéma des données stockées sur ce nœud. Par conséquent, une restauration directe sur place n'est pas possible.

Scénarios de rollback

Cassandra 4.0.X, disponible avec Edge pour le cloud privé 4.53.00, est compatible avec les autres composants du cloud privé 4.52.02.

Veuillez consulter le tableau ci-dessous pour obtenir un récapitulatif des différentes stratégies de restauration que vous pouvez utiliser :

Scénario	Stratégie de rollback
Un seul centre de données, certains nœuds Cassandra mis à niveau	Utiliser les sauvegardes
DC unique, tous les nœuds Cassandra mis à niveau	N'effectuez pas de rollback de Cassandra. Il est possible d'effectuer un rollback d'autres composants.
Centre de données unique, tous les nœuds (Cassandra et autres) mis à niveau	N'effectuez pas de rollback de Cassandra. Il est possible d'effectuer un rollback d'autres composants.
Plusieurs centres de données, certains nœuds d'un centre de données mis à niveau	Recompiler à partir d'un fichier DC existant
Plusieurs centres de données, tous les nœuds Cassandra de certains centres de données ont été mis à niveau	Recompiler à partir d'un fichier DC existant
Plusieurs centres de données, nœuds Cassandra du dernier centre de données en cours de mise à niveau	Essayez de terminer la mise à niveau. Si ce n'est pas possible, rétrogradez un contrôleur de domaine à l'aide d'une sauvegarde. Recompilez les autres DC à partir du DC rétabli.
Plusieurs centres de données, tous les nœuds Cassandra mis à niveau	N'effectuez pas de rollback de Cassandra. Il est possible d'effectuer un rollback d'autres composants.
Plusieurs centres de données, tous les nœuds (Cassandra et autres) mis à niveau	N'effectuez pas de rollback de Cassandra. Il est possible d'effectuer un rollback d'autres composants.

Éléments généraux à prendre en compte

Lorsque vous envisagez d'effectuer un rollback, tenez compte des points suivants :

Rollback des composants d'exécution ou de gestion : si vous souhaitez effectuer un rollback de composants tels que edge-management-server, edge-message-processor ou tout composant non Cassandra vers la version 4.52.02 de Private Cloud, il est recommandé de NE PAS effectuer de rollback de Cassandra. La version de Cassandra fournie avec Private Cloud 4.53.00 est compatible avec tous les composants non Cassandra d'Edge pour le cloud privé 4.52.02. Vous pouvez effectuer un rollback des composants non Cassandra à l'aide de la méthodologie listée ici, tandis que Cassandra reste sur la version 4.0.13.
Effectuer un rollback après la mise à niveau de l'ensemble du cluster Cassandra vers la version 4.0.X : si l'ensemble de votre cluster Cassandra est mis à niveau vers la version 4.0.X lors de la mise à niveau vers Private Cloud version 4.53.00, il est recommandé de continuer avec cette configuration de cluster et de NE PAS effectuer de rollback de Cassandra. Les composants tels que edge-management-server, edge-message-processor, edge-router, etc., de la version 4.52.02 du cloud privé sont compatibles avec la version 4.0.X de Cassandra.
Effectuer un rollback de Cassandra lors de la mise à niveau de Cassandra : si vous rencontrez des problèmes lors de la mise à niveau de Cassandra, vous pouvez envisager d'effectuer un rollback. Vous pouvez suivre les stratégies de restauration listées dans cet article en fonction de l'état dans lequel vous vous trouvez pendant le processus de mise à niveau.
Effectuer un rollback à l'aide de sauvegardes : les sauvegardes effectuées à partir de Cassandra 4.0.X ne sont pas compatibles avec les sauvegardes de Cassandra 3.11.X. Pour effectuer un rollback de Cassandra à l'aide de la restauration de sauvegarde, vous devez effectuer des sauvegardes de Cassandra 3.11.X avant de tenter la mise à niveau.

Rétablir Cassandra à l'aide de la reconstruction

Prérequis

Vous exploitez un cluster Edge pour Private Cloud 4.52.02 dans plusieurs centres de données.
Vous êtes en train de mettre à niveau Cassandra de la version 3.11.X vers la version 4.0.X et vous avez rencontré des problèmes lors de la mise à niveau.
Vous disposez d'au moins un centre de données entièrement fonctionnel dans le cluster qui exécute toujours l'ancienne version de Cassandra (Cassandra 3.11.X).

Cette procédure repose sur le streaming de données depuis un centre de données existant. Cela peut prendre un certain temps, selon la quantité de données stockées dans Cassandra. Vous devez être prêt à détourner le trafic d'exécution de ce centre de données pendant le rollback.

Étapes majeures

Sélectionnez un centre de données (partiellement ou entièrement mis à niveau) que vous souhaitez rétablir. Redirigez le trafic d'exécution vers un autre centre de données opérationnel.
Identifiez le nœud de départ dans le centre de données et commencez par l'un des nœuds de départ.
Arrêtez, désinstallez et nettoyez le nœud Cassandra.
Installez l'ancienne version de Cassandra sur le nœud et configurez-la selon vos besoins.
Supprimez les configurations supplémentaires ajoutées précédemment.
Répétez les étapes ci-dessus pour tous les nœuds de seed du centre de données, un par un.
Répétez les étapes ci-dessus pour tous les nœuds Cassandra restants dans le centre de données, un par un.
Reconstruisez les nœuds à partir du centre de données fonctionnel existant, un par un.
Redémarrez tous les composants edge-* du centre de données connectés à Cassandra.
Testez le trafic et redirigez-le vers ce centre de données.
Répétez les étapes pour chaque centre de données, un par un.

Procédure détaillée

Choisissez un centre de données dans lequel tous les nœuds Cassandra ou certains d'entre eux sont mis à niveau. Détournez tout le trafic du proxy d'exécution et le trafic de gestion de ce centre de données pendant que les nœuds Cassandra de ce centre de données sont restaurés. Assurez-vous que tous les nœuds Cassandra sont à l'état UN (Up/Normal) lorsque la commande nodetool ring est exécutée sur les nœuds. Si certains nœuds sont hors service, résolvez le problème et remettez-les en service avant de continuer.

Référez-vous à l'exemple ci-dessous :

/opt/apigee/apigee-cassandra/bin/nodetool status
Datacenter: dc-1
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load       Tokens       Owns (effective)  Host ID                               Rack
UN  DC1-1IP1  456.41 KiB  1            100.0%            78fc4ddd-2ed9-4a8c-98a2-63a38c2f1920  ra-1
UN  DC1-1IP2  870.93 KiB  1            100.0%            160db01a-64ab-43a7-b9ea-3b7f8f66d52b  ra-1
UN  DC1-1IP3  824.08 KiB  1            100.0%            21d61543-d59e-403a-bf5d-bfe7f664baa6  ra-1
Datacenter: dc-2
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load       Tokens       Owns (effective)  Host ID                               Rack
UN  DC2-1IP1   802.08 KiB  1            100.0%            583e0576-336d-4ce7-9729-2ae74e0abde2  ra-1
UN  DC2-1IP2   844.4 KiB   1            100.0%            fef794d5-f4c2-4a4e-bb05-9adaeb4aea4b  ra-1
UN  DC2-1IP3   878.12 KiB  1            100.0%            3894b3d9-1f5a-444d-83db-7b1e338bbfc9  ra-1

Vous pouvez exécuter nodetool describecluster sur les nœuds pour comprendre l'état actuel de l'ensemble du cluster. Par exemple, l'illustration suivante montre une instance d'un cluster à deux centres de données où tous les nœuds DC-1 sont sur la version 4 de Cassandra, tandis que tous les nœuds DC-2 sont sur la version 3 de Cassandra :

# On nodes where Cassandra is upgraded
/opt/apigee/apigee-cassandra/bin/nodetool describecluster
Cluster Information:
    Name: Apigee
    Snitch: org.apache.cassandra.locator.PropertyFileSnitch
    DynamicEndPointSnitch: enabled
    Partitioner: org.apache.cassandra.dht.RandomPartitioner
    Schema versions:
        2eadcd74-0245-309a-9992-3625afa70038: [DC-1-IP1, DC-1-IP2, DC-1-IP3]
        129dc15e-198e-3c11-b64c-701044a3a1ad: [DC-2-IP1, DC-2-IP2, DC-2-IP3]

Stats for all nodes:
    Live: 6
    Joining: 0
    Moving: 0
    Leaving: 0
    Unreachable: 0

Data Centers:
    dc-1 #Nodes: 3 #Down: 0
    dc-2 #Nodes: 3 #Down: 0

Database versions:
    4.0.13: [DC-1-IP1:7000, DC-1-IP2:7000, DC-1-IP3:7000]
    3.11.16: [DC-2-IP1:7000, DC-2-IP2:7000, DC-2-IP3:7000]

Keyspaces:
    system_schema -> Replication class: LocalStrategy {}
    system -> Replication class: LocalStrategy {}
    auth -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    cache -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    devconnect -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    dek -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    user_settings -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    apprepo -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    kms -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    identityzone -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    audit -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    analytics -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    keyvaluemap -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    counter -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    apimodel_v2 -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    system_distributed -> Replication class: SimpleStrategy {replication_factor=3}
    system_traces -> Replication class: SimpleStrategy {replication_factor=2}
    system_auth -> Replication class: SimpleStrategy {replication_factor=1}

# On nodes where Cassandra is not upgraded
/opt/apigee/apigee-cassandra/bin/nodetool describecluster
Cluster Information:
    Name: Apigee
    Snitch: org.apache.cassandra.locator.PropertyFileSnitch
    DynamicEndPointSnitch: enabled
    Partitioner: org.apache.cassandra.dht.RandomPartitioner
    Schema versions:
        2eadcd74-0245-309a-9992-3625afa70038: [DC-1-IP1, DC-1-IP2, DC-1-IP3]
        129dc15e-198e-3c11-b64c-701044a3a1ad: [DC-2-IP1, DC-2-IP2, DC-2-IP3]

Identifiez les nœuds de seed dans le centre de données : consultez la section Identifier les nœuds de seed dans l'annexe. Exécutez les étapes ci-dessous sur l'un des nœuds de seed :

Arrêtez, désinstallez et nettoyez les données du nœud Cassandra. Sélectionnez le premier nœud "seed" (nœud racine) sur Cassandra version 4 dans ce centre de données. Arrête.

# Stop Cassandra service on the node
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop

# Uninstall Cassandra software
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra uninstall

# Wipe out Cassandra data
rm -rf /opt/apigee/data/apigee-cassandra

Installez l'ancienne version du logiciel Cassandra sur le nœud et définissez certaines configurations. Exécutez le fichier bootstrap d'Edge pour le cloud privé 4.52.02.

# Download bootstrap of 4.52.02
curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh -u uName:pWord

# Execute bootstrap of 4.52.02
sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord

Créez ou modifiez le fichier /opt/apigee/customer/application/cassandra.properties.
Ajoutez le contenu suivant au fichier. ipOfNode correspond à l'adresse IP du nœud que Cassandra utilise pour communiquer avec d'autres nœuds Cassandra :
```
conf_jvm_options_custom_settings=-Dcassandra.replace_address=ipOfNode -Dcassandra.allow_unsafe_replace=true
```
Assurez-vous que le fichier appartient à l'utilisateur Apigee et qu'il peut le lire :
```
chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
```

Installez et configurez Cassandra :

# Install cassandra version 3.11.X
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra install

# Setup cassandra while passing standard configuration file
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra setup -f configFile
# Ensure Cassandra version is correct and service is running
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra version
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra status

Vérifiez que le nœud a démarré. Vérifiez la commande suivante sur ce nœud et sur les autres nœuds du cluster. Le nœud doit indiquer qu'il est à l'état "UN" (Up/Normal) :
```
/opt/apigee/apigee-cassandra/bin/nodetool status
```
Supprimez les configurations supplémentaires ajoutées précédemment du fichier /opt/apigee/customer/application/cassandra.properties.
Répétez les étapes 3 à 10 sur tous les nœuds de seed Cassandra du centre de données, un par un.
Répétez les étapes 3 à 10 sur tous les nœuds Cassandra restants du centre de données, un par un.
Reconstruisez tous les nœuds du centre de données à partir d'un centre de données exécutant l'ancienne version de Cassandra. Effectuez cette étape sur un nœud à la fois :
```
/opt/apigee/apigee-cassandra/bin/nodetool rebuild -dc <name of working DC>
```
Cette procédure peut prendre du temps. Vous pouvez ajuster streamingthroughput si nécessaire. Vérifiez l'état d'avancement de l'opération dans nodetool netstats.
(Facultatif) Exécutez la commande de réparation dans le nœud Cassandra si les données ne sont pas reconstruites.
```
/opt/apigee/apigee-cassandra/bin/nodetool -h node-IP repair -pr
```

Redémarrez tous les composants edge-* du centre de données, un par un :

/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
/opt/apigee/apigee-service/bin/apigee-service edge-router restart
/opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart

Validez le trafic et redirigez-le vers ce centre de données. Exécutez des validations pour le trafic d'exécution et les API de gestion dans ce centre de données, puis commencez à rediriger le trafic du proxy et des API de gestion vers celui-ci.
Répétez les étapes ci-dessus pour chaque centre de données que vous souhaitez rétablir.

Restaurer Cassandra à l'aide d'une sauvegarde

Prérequis

Vous êtes en train de mettre à niveau Cassandra de la version 3.11.X vers la version 4.0.X et vous avez rencontré des problèmes lors de la mise à niveau.
Vous disposez de sauvegardes pour le nœud vers lequel vous effectuez le rollback. La sauvegarde a été effectuée avant la tentative de mise à niveau de la version 3.11.X vers la version 4.0.X.

Étapes

Sélectionnez le nœud que vous souhaitez annuler. Si vous restaurez tous les nœuds d'un centre de données à l'aide de sauvegardes, commencez par les nœuds de seed. Consultez la section "Identifier les nœuds de départ" dans l'annexe.

Arrêtez, désinstallez et nettoyez le nœud Cassandra :

# Stop Cassandra service on the node
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop

# Uninstall Cassandra software
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra uninstall

# Wipe Cassandra data
rm -rf /opt/apigee/data/apigee-cassandra

Installez l'ancienne version du logiciel Cassandra sur le nœud et configurez-la :

Exécutez le fichier bootstrap pour Edge pour le cloud privé 4.52.02 :

# Download bootstrap for 4.52.02
curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh -u ‘uName:pWord’

# Execute bootstrap for 4.52.02
sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord

Créez ou modifiez le fichier /opt/apigee/customer/application/cassandra.properties :

conf_jvm_options_custom_settings=-Dcassandra.replace_address=ipOfNode -Dcassandra.allow_unsafe_replace=true

Assurez-vous que le fichier appartient à l'utilisateur Apigee et qu'il est lisible :

chown apigee:apigee /opt/apigee/customer/application/cassandra.properties

Installez et configurez Cassandra :

# Install Cassandra version 3.11.X
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra install

# Set up Cassandra with the standard configuration file
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra setup -f configFile

# Verify Cassandra version and check service status
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra version
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra status

Vérifiez que le nœud a démarré. Vérifiez la commande suivante sur ce nœud et sur les autres nœuds du cluster. Les nœuds doivent indiquer que ce nœud est à l'état "UN" :

/opt/apigee/apigee-cassandra/bin/nodetool status

Arrêtez le service Cassandra et restaurez la sauvegarde. Pour en savoir plus, consultez la documentation sur la sauvegarde et la restauration :

# Stop Cassandra service on the node
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop

# Wipe the data directory in preparation for restore
rm -rf /opt/apigee/data/apigee-cassandra/data

# Restore the backup taken before the upgrade attempt
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restore backupFile

Une fois la sauvegarde restaurée, supprimez les configurations supplémentaires :

Supprimez la configuration ajoutée précédemment du fichier /opt/apigee/customer/application/cassandra.properties.

Démarrez le service Cassandra sur le nœud :

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra start

Répétez les étapes sur chaque nœud Cassandra que vous souhaitez restaurer à l'aide de sauvegardes, un à la fois.

Une fois tous les nœuds Cassandra restaurés, redémarrez tous les composants edge-* un par un :

/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
/opt/apigee/apigee-service/bin/apigee-service edge-router restart
/opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart

Optimisations de la sauvegarde (option avancée)

Vous pouvez potentiellement minimiser (ou éliminer) la perte de données lors de la restauration de sauvegardes si vous disposez de répliques contenant les données les plus récentes. Si des répliques sont disponibles, exécutez une réparation sur le nœud restauré après la restauration de la sauvegarde.

Annexe

Identifier les nœuds seed

Sur n'importe quel nœud Cassandra d'un centre de données, exécutez la commande suivante :

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra configure -search conf_cassandra_seeds

La commande génère plusieurs lignes. Recherchez la dernière ligne du résultat. Les adresses IP listées sur la dernière ligne sont les nœuds de départ. Dans l'exemple ci-dessous, DC-1-IP1, DC-1-IP2, DC-2-IP1 et DC-2-IP2 sont les adresses IP des nœuds de seed :

Found key conf_cassandra_seeds, with value, "127.0.0.1", in /opt/apigee/apigee-cassandra/token/default.properties

Found key conf_cassandra_seeds, with value, 127.0.0.1, in /opt/apigee/apigee-cassandra/token/application/cassandra.properties

Found key conf_cassandra_seeds, with value, "DC-1-IP1, DC-1-IP2, DC-2-IP1, DC-2-IP2", in /opt/apigee/token/application/cassandra.properties
apigee-configutil: apigee-cassandra: # OK

Effectuer un rollback vers une version majeure ou mineure précédente

Pour effectuer un rollback vers une version majeure ou mineure précédente, procédez comme suit sur chaque nœud qui héberge le composant :

Téléchargez le fichier bootstrap.sh pour la version vers laquelle vous souhaitez effectuer un rollback :
- Pour revenir à la version 4.52.02, téléchargez bootstrap_4.52.02.sh :
```
curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh 
```

Arrêtez le composant pour effectuer le rollback :

Pour rétablir l'un des composants avec code commun sur le nœud, vous devez tous les arrêter, comme le montre l'exemple suivant :

/opt/apigee/apigee-service/bin/apigee-service edge-management-server stop
/opt/apigee/apigee-service/bin/apigee-service edge-router stop
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor stop
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server stop
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server stop

Pour effectuer un rollback d'un autre composant du nœud, arrêtez-le :
```
/opt/apigee/apigee-service/bin/apigee-service component stop
```

Si vous restaurez la version précédente de la monétisation, désinstallez-la de tous les nœuds Management Server et Message Processor :
```
/opt/apigee/apigee-service/bin/apigee-service edge-mint-gateway uninstall
```
Désinstallez le composant pour effectuer un rollback sur le nœud :
1. Pour rétablir l'un des composants avec code commun sur le nœud, vous devez tous les désinstaller en désinstallant le groupe de composants edge-gateway, comme le montre l'exemple suivant :
```
/opt/apigee/apigee-service/bin/apigee-service edge-gateway uninstall
```
2. Pour revenir à la version précédente de Nginx, procédez comme suit :
```
###Find the apigee-nginx RPM 
rpm -qa | grep -i "apigee-nginx"

###Remove the apigee-nginx RPM
dnf remove apigee-nginx-1.26.x
```
3. Pour effectuer un rollback d'un autre composant sur le nœud, désinstallez uniquement ce composant, comme le montre l'exemple suivant :
```
/opt/apigee/apigee-service/bin/apigee-service component uninstall
```
  où component est le nom du composant.
4. Pour rétablir le routeur Edge, vous devez supprimer le contenu du fichier /opt/nginx/conf.d en plus de désinstaller le groupe de composants edge-gateway :
```
cd /opt/nginx/conf.d
rm -rf *
```

Désinstallez la version 4.53.00 de apigee-setup :

/opt/apigee/apigee-service/bin/apigee-service apigee-setup uninstall

Installez la version 4.52.02 de l'utilitaire apigee-service et ses dépendances. L'exemple suivant installe la version 4.52.02 de apigee-service :
```
sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord
```
Où uName et pWord sont le nom d'utilisateur et le mot de passe que vous avez reçus d'Apigee. Si vous omettez pWord, vous serez invité à le saisir.

Si vous obtenez une erreur, assurez-vous d'avoir téléchargé le fichier bootstrap.sh à l'étape 1.

Installez apigee-setup :

/opt/apigee/apigee-service/bin/apigee-service apigee-setup install

Installez l'ancienne version du composant :
```
/opt/apigee/apigee-setup/bin/setup.sh -p component -f configFile
```
où component est le composant à installer et configFile est votre fichier de configuration pour l'ancienne version.
Si vous restaurez Qpid, videz les iptables :
```
sudo iptables -F
```
Répétez cette procédure pour chaque nœud qui héberge le composant que vous restaurez.

Effectuer un rollback vers un correctif précédent

Pour rétablir un composant à une version de correctif spécifique, procédez comme suit sur chaque nœud qui héberge le composant :

Téléchargez la version spécifique du composant :
```
/opt/apigee/apigee-service/bin/apigee-service component_version install
```
Où component_version correspond au composant et à la version du correctif à installer. Exemple :
```
/opt/apigee/apigee-service/bin/apigee-service edge-ui-4.53.00-0.0.20254 install
```
Si vous utilisez le dépôt en ligne Apigee, vous pouvez déterminer les versions de composants disponibles à l'aide de la commande suivante :
```
yum --showduplicates list comp
```
Exemple :
```
yum --showduplicates list edge-ui
```
Installez le composant à l'aide de apigee-setup :
```
/opt/apigee/apigee-setup/bin/setup.sh -p comp -f configFile
```
Exemple :
```
/opt/apigee/apigee-setup/bin/setup.sh -p ui -f configFile
```
Notez que vous ne spécifiez que le nom du composant lors de son installation, et non sa version.
Répétez cette procédure pour chaque nœud qui héberge le composant que vous restaurez.

Effectuer un rollback de mTLS

Pour annuler la mise à jour mTLS, procédez comme suit sur tous les hôtes :

Arrêter Apigee :
```
apigee-all stop
```
Arrêter mTLS :
```
apigee-service apigee-mtls uninstall
```

Réinstallez mTLS :

apigee-service apigee-mtls install
apigee-service apigee-mtls setup -f /opt/silent.conf