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 annuler 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

La réversion d'une version implique la réversion de tous les composants que vous avez peut-être mis à niveau. De plus, vous devez prendre en compte des considérations particulières lorsque vous effectuez une régression de Cassandra vers la version 4.52.02.

Vous pouvez effectuer un rollback dans deux cas:

Effectuer 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 de correctif précédente de la même version. Par exemple, de 4.53.00.01 à 4.53.00.00.

Pour en savoir plus, consultez le processus de publication d'Apigee Edge.

Ordre de rollback

Le rollback des composants doit être effectué dans l'ordre inverse de leur mise à niveau, à l'exception des serveurs de gestion, qui doivent être rétablis après Cassandra.

L'ordre général de rollback typique pour Private Cloud 4.53.00 se présente comme suit:

Rétablir Postgres, Qpid et d'autres composants liés aux analyses
Rétablir les routeurs et les processeurs de messages
Rollback Cassandra, Zookeeper
Serveur de gestion de rollback

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, procédez comme suit:

Rétablir toutes les RMP une par une
Rétablir l'intégralité du cluster Cassandra à l'aide de sauvegardes
Rétablir les nœuds du serveur de gestion Edge un par un

Qui peut effectuer un rollback ?

L'utilisateur effectuant un 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 à 1 000, vous devez exécuter le routeur en tant qu'utilisateur racine ou en tant qu'utilisateur disposant d'un accès à ces ports. Vous pouvez également exécuter un composant en tant qu'utilisateur et un autre en tant qu'utilisateur différent.

Composants avec code commun

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

edge-management-server (serveur de gestion)
edge-message-processor (processeur de messages)
edge-router (routeur)
edge-postgres-server (Postgres Server)
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 les désinstaller tous les trois pour annuler l'un d'entre eux.

Retour en arrière 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, un rollback direct 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.

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

Scénario	Stratégie de rollback
Un seul centre de données, certains nœuds Cassandra mis à niveau	Utiliser des sauvegardes
Un seul centre de données, tous les nœuds Cassandra mis à niveau	N'effectuez pas de rollback de Cassandra. Les autres composants peuvent être annulés.
Un seul centre de données, tous les nœuds (Cassandra et autres) mis à niveau	N'effectuez pas de rollback de Cassandra. Les autres composants peuvent être annulés.
Plusieurs DC, certains nœuds d'un DC mis à niveau	Recompiler à partir d'un DC existant
Plusieurs centres de données, tous les nœuds Cassandra de certains centres de données mis à niveau	Recompiler à partir d'un DC existant
Plusieurs DC, mise à niveau des nœuds Cassandra du dernier DC	Essayez de terminer la mise à niveau. Si ce n'est pas possible, annulez la modification d'un contrôleur de domaine à l'aide d'une sauvegarde. Recompilez les autres DC à partir du DC annulé.
Plusieurs centres de données, tous les nœuds Cassandra mis à niveau	N'effectuez pas de rollback de Cassandra. Les autres composants peuvent être annulés.
Plusieurs centres de données, tous les nœuds (Cassandra et autres) mis à niveau	N'effectuez pas de rollback de Cassandra. Les autres composants peuvent être annulés.

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

Lorsque vous envisagez 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 autre composant autre que Cassandra vers la version 4.52.02 du cloud privé, nous vous recommandons de NE PAS effectuer de rollback de Cassandra. Cassandra fourni avec Private Cloud 4.53.00 est compatible avec tous les composants autres que Cassandra d'Edge pour Private Cloud 4.52.02. Vous pouvez effectuer un rollback des composants autres que Cassandra à l'aide de la méthodologie indiquée ici, tandis que Cassandra reste sur la version 4.0.13.
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 dans le cadre de la mise à niveau vers la version 4.53.00 du cloud privé, nous vous recommandons de poursuivre la configuration de ce 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.
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 de faire un rollback. Vous pouvez suivre les stratégies de rollback listées dans cet article en fonction de l'état dans lequel vous vous trouvez pendant le processus de mise à niveau.
Rollback à l'aide de sauvegardes:les sauvegardes effectuées à partir de Cassandra 4.0.X ne sont pas compatibles avec celles 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 d'une recompilation

Prérequis

Vous exploitez un cluster Edge for Private Cloud 4.52.02 sur 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 à partir d'un centre de données existant. Ce processus peut prendre un certain temps, en fonction de la quantité de données stockées dans Cassandra. Vous devez être prêt à détourner votre trafic d'exécution de ce centre de données pendant le rollback.

Étapes majeures

Sélectionnez un centre de données (mis à niveau partiellement ou entièrement) que vous souhaitez annuler. Détourner 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 départ du centre de données, un par un.
Répétez les étapes ci-dessus pour tous les nœuds Cassandra restants du centre de données, un par un.
Recréez les nœuds 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 et redirigez le trafic vers ce centre de données.
Répétez la procédure pour chaque centre de données, un par un.

Procédure détaillée

Choisissez un centre de données où tous ou certains des nœuds Cassandra sont mis à niveau. Détournez tout le trafic de proxy d'exécution et de gestion de ce centre de données pendant le rollback des nœuds Cassandra de ce centre de données. 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 en panne, corrigez le problème et réactivez-les 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'exemple suivant montre une instance de cluster à deux centres de données où tous les nœuds DC-1 exécutent Cassandra 4, tandis que tous les nœuds DC-2 exécutent Cassandra 3:

# 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 référence dans le centre de données:consultez la section Identifier les nœuds de référence de l'annexe. Exécutez les étapes ci-dessous sur l'un des nœuds de référence:

Arrêtez, désinstallez et nettoyez les données du nœud Cassandra. Sélectionnez le premier nœud de référence sur Cassandra 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'ancien logiciel Cassandra sur le nœud et définissez certaines configurations. Exécutez le fichier de démarrage d'Edge pour Private Cloud 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

Définir des configurations Cassandra

Créez ou modifiez le fichier /opt/apigee/customer/application/cassandra.properties.
Ajoutez le contenu suivant au fichier. ipOfNode est 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 l'utilisateur apigee est le propriétaire du fichier et qu'il peut le lire:
```
chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
```

Installez et configurez Cassandra :

Installez Cassandra version 3.11.X:

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra install

Configurez Cassandra en transmettant le fichier de configuration standard:

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra setup -f configFile

Assurez-vous que Cassandra 3.11.X est installé et que le service est en cours d'exécution:

/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 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 à 6 sur tous les nœuds de semences Cassandra du centre de données, un par un.
Répétez les étapes 3 à 6 sur tous les nœuds Cassandra restants du centre de données, un par un.
Recréez 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 un nœud à la fois:
```
/opt/apigee/apigee-cassandra/bin/nodetool rebuild -dc <name of working DC>
```
Cette procédure peut prendre un certain temps. Vous pouvez ajuster streamingthroughput si nécessaire. Vérifiez l'état à l'aide de la commande suivante:
```
/opt/apigee/apigee-cassandra/bin/nodetool netstats
```

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 et redirigez le trafic 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 redirigez-y le trafic du proxy et des API de gestion.
Répétez les étapes ci-dessus pour chaque centre de données que vous souhaitez annuler.

Rétablir 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 du nœud que vous souhaitez annuler. 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 un nœud que vous souhaitez annuler. Si vous annulez la modification de tous les nœuds d'un centre de données à l'aide de sauvegardes, commencez par les nœuds de référence. Consultez la section "Identifier les nœuds de départ" de 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'ancien logiciel Cassandra sur le nœud et configurez-le:

Exécutez le fichier de démarrage pour Edge pour Private Cloud 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 les autres nœuds du cluster. Les nœuds doivent indiquer que ce nœud est dans 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 annuler à l'aide de sauvegardes, un par un.

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 sauvegarde (option avancée)

Vous pouvez potentiellement minimiser (ou éliminer) les pertes de données lors de la restauration des sauvegardes si des réplicas contenant les dernières données sont disponibles. Si des réplicas sont disponibles, exécutez une réparation sur le nœud restauré après avoir restauré 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 de la sortie. 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 départ:

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 de la version à laquelle vous souhaitez effectuer un rollback:
- Pour effectuer un rollback vers 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 un rollback :

Pour annuler l'un des composants avec code commun sur le nœud, vous devez tous les arrêter, comme illustré dans 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 annuler le rollback de tout autre composant du nœud, arrêtez uniquement ce composant:
```
/opt/apigee/apigee-service/bin/apigee-service component stop
```

Si vous annulez la monétisation, désinstallez-la de tous les nœuds du serveur de gestion et du processeur de messages:
```
/opt/apigee/apigee-service/bin/apigee-service edge-mint-gateway uninstall
```
Désinstallez le composant à annuler sur le nœud :
1. Pour annuler 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 illustré dans l'exemple suivant:
```
/opt/apigee/apigee-service/bin/apigee-service edge-gateway uninstall
```
2. Pour annuler tout autre composant du nœud, désinstallez uniquement ce composant, comme indiqué dans l'exemple suivant:
```
/opt/apigee/apigee-service/bin/apigee-service component uninstall
```
  où component est le nom du composant.
3. Pour annuler la mise à niveau du 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 un message d'erreur s'affiche, 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 annulez Qpid, videz iptables:
```
sudo iptables -F
```
Répétez cette procédure pour chaque nœud qui héberge le composant que vous annulez.

Effectuer un rollback vers une version de correctif précédente

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 d'Apigee, vous pouvez déterminer les versions de composant disponibles à l'aide de la commande suivante:
```
yum --showduplicates list comp
```
Exemple :
```
yum --showduplicates list edge-ui
```
Utilisez apigee-setup pour installer le composant:
```
/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 devez spécifier 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 annulez.

Rétablir mTLS

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

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

Réinstallez mTLS:

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