Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Effectuer un rollback d'Apigee Edge 4.54.00

Si vous rencontrez une erreur lors d'une mise à jour vers Edge 4.54.00, vous pouvez effectuer un rollback du composant à l'origine de l'erreur, puis réessayer d'effectuer la mise à jour.

Vous pouvez rétablir Edge 4.54.00 sur l'une des versions majeures suivantes :

Version 4.53.00
Version 4.53.01

Pour en savoir plus, consultez 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'ordre général de rollback pour Private Cloud 4.54.00 se présente généralement comme suit :

Effectuer un rollback de Cassandra et Zookeeper.
Restaurez Qpid, les autres composants liés à l'analyse et Postgres.
Effectuer un rollback de l'UI
Effectuez un rollback de LDAP.
Effectuez un rollback du serveur de gestion.
Effectuez un rollback des routeurs et des processeurs de messages.

Par exemple, supposons que vous ayez mis à niveau tous vos routeurs et processeurs de messages, tous vos serveurs de gestion, LDAP et quelques nœuds d'interface utilisateur vers la version 4.54.00 à partir de la version 4.53.00 (ou 4.53.01) et que vous souhaitiez revenir à la version précédente. Dans ce cas, vous devez :

Effectuer un rollback des nœuds d'UI mis à niveau
Effectuer un rollback des nœuds LDAP
Effectuer un rollback des nœuds du serveur de gestion un par un
Effectuer un rollback de tous les RMP un par un

Remarque : Apigee SSO dans Apigee Edge pour Private Cloud 4.54.00 n'est pas compatible avec les rollbacks directs ou partiels. Pour revenir à Apigee SSO, vous devez rétablir tous les composants précédemment mis à niveau et restaurer apigee-sso à l'aide du fichier de configuration silencieux de votre version précédente.

Redémarrez ou réinstallez apigee-sso :

Si vous n'avez arrêté que apigee-sso pendant la mise à niveau, redémarrez le service.
Si vous avez désinstallé apigee-sso lors de la mise à niveau, réinstallez-le à l'aide du fichier de configuration silencieuse de votre version précédente :
- 4.53.01 Procédure d'installation
- 4.53.00 Étapes d'installation

Qui peut effectuer un rollback ?

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

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 racine ou en tant qu'utilisateur ayant accès à ces ports. Vous pouvez également exécuter un composant en tant qu'un utilisateur et un autre composant en tant qu'un autre utilisateur.

Effectuer un rollback 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

Le tableau suivant récapitule les 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
Plusieurs centres de données, certains nœuds d'un centre de données mis à niveau	Recompiler à partir d'un 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 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, effectuez un rollback d'un CD à l'aide d'une sauvegarde. Reconstruisez les DC restants à partir du DC restauré.

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

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

Rollback de Cassandra pendant 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. Suivez les stratégies de rétablissement décrites dans cet article en fonction de votre état pendant le processus de mise à niveau.
Effectuer un rollback à l'aide de sauvegardes : les sauvegardes effectuées à partir de Cassandra 5.0.X ne sont pas compatibles avec les sauvegardes de Cassandra 4.0.X. Pour effectuer un rollback de Cassandra à l'aide de la restauration de sauvegarde, vous devez effectuer des sauvegardes de Cassandra 4.0.X avant de tenter la mise à niveau.

Rétablir Cassandra à l'aide de la reconstruction

Prérequis

Vous exploitez un cluster Edge for Private Cloud 4.53.00/4.53.01 dans plusieurs centres de données.
Vous êtes en train de mettre à niveau Cassandra de la version 4.0.X vers la version 5.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 4.0.X).

Cette procédure repose sur la diffusion de données à partir d'un centre de données existant. Cela peut prendre un certain temps, en fonction de la quantité de données stockées dans Cassandra. Vous devez être prêt à rediriger votre trafic d'exécution hors de ce centre de données pendant la restauration.

Étapes majeures

Sélectionnez un centre de données (partiellement ou entièrement mis à niveau) que vous souhaitez restaurer. Rediriger le trafic d'exécution vers un autre centre de données opérationnel.
Identifiez le nœud d'amorçage dans le centre de données et commencez par l'un des nœuds d'amorçage.
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 du 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 qui sont 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 dans lequel tous les nœuds Cassandra ou certains d'entre eux sont mis à niveau. Détournez tout le trafic de proxy d'exécution et de gestion de ce centre de données pendant que les nœuds Cassandra de ce centre de données sont en cours de restauration. 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:
    5.0.8: [DC-1-IP1:7000, DC-1-IP2:7000, DC-1-IP3:7000]
    4.0.13: [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 d'amorçage :

Arrêtez, désinstallez et nettoyez les données du nœud Cassandra. Choisissez le premier nœud d'amorçage sur Cassandra version 5 dans ce centre de données. Arrêtez.

# 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.53.00/4.53.01.

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

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

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 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 4.0.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 au fichier /opt/apigee/customer/application/cassandra.properties.
Répétez les étapes 3 à 10 sur tous les nœuds d'amorçage 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 pour chaque nœud, un par un :
```
/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 nodetool netstats pour connaître l'état d'avancement de l'opération.
(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 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 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 restaurer.

Effectuer un rollback de Cassandra à l'aide de la sauvegarde

Prérequis

Vous êtes en train de mettre à niveau Cassandra de la version 4.0.X vers la version 5.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 4.0.X vers la version 5.0.X.

Étapes

Sélectionnez un nœud pour lequel vous souhaitez effectuer un rollback. 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 d'amorçage 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'ancienne version du logiciel Cassandra sur le nœud et configurez-la :

Exécutez le fichier d'amorçage pour Edge for Private Cloud 4.53.00/4.53.01 :

# Download bootstrap for 4.53.00
curl https://software.apigee.com/bootstrap_4.53.00.sh -o /tmp/bootstrap_4.53.00.sh -u uName:pWord

# Execute bootstrap for 4.53.00
sudo bash /tmp/bootstrap_4.53.00.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 4.0.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 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 la sauvegarde (option avancée)

Vous pouvez potentiellement minimiser (ou éliminer) la perte de données lors de la restauration des sauvegardes si vous disposez d'instances répliquées 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 d'amorçage

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 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 de ZooKeeper

Rollback

Si un rollback est nécessaire :

Effectuez d'abord les étapes de rétablissement sur les observateurs et les abonnés. Veuillez consulter Identifier le leader, les followers et les observateurs pour sélectionner les observateurs et les followers.
Téléchargez et exécutez le bootstrap de la version vers laquelle vous effectuez le rollback (4.53.00 ou 4.53.01). Le processus varie probablement selon que le nœud dispose d'une connexion Internet externe ou que vous suivez une installation hors connexion.

Arrêtez ZooKeeper s'il est en cours d'exécution sur le nœud :

  /opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper stop

Désinstallez le ZooKeeper existant :

  /opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper uninstall

Installez Zookeeper comme d'habitude :

  /opt/apigee/apigee-setup/bin/setup.sh -p zk -f <silent-config-file>

Une fois que tous les nœuds suiveurs et observateurs ont été restaurés, restaurez le nœud leader en suivant les étapes 2 à 5 sur le nœud leader.
Une fois tous les nœuds restaurés, vérifiez l'état du cluster et assurez-vous qu'il contient un nœud leader.

Restaurer une sauvegarde

Consultez Restaurer à partir d'une sauvegarde.

Effectuer un rollback de Qpid

Remarque : Effectuez d'abord un rollback de apigee-qpidd avant d'essayer d'effectuer un rollback d'autres composants Edge (edge-qpid-server, edge-message-processor, edge-management-server).

Pour revenir à une version Feature Release précédente, veillez à télécharger le fichier bootstrap.sh de la version à laquelle vous souhaitez revenir. Pour revenir à la version 4.53.00/4.53.01, téléchargez bootstrap_4.53.00.sh.

Pour effectuer un rollback de Qpid, procédez comme suit sur tous les hôtes Qpid :

Arrêtez le broker Qpid existant :
```
apigee-service apigee-qpidd stop
```
Bloquez le trafic entrant sur le port de l'agent 5672 de tous les processeurs de messages en appliquant un pare-feu. Vous pouvez appliquer ce pare-feu au niveau de l'instance de nœud Qpid ou d'un autre composant de pare-feu/réseau externe.
Nous vous recommandons d'effectuer la même étape pour toutes les adresses IP des processeurs de messages. Par exemple, pour supprimer les requêtes provenant des adresses IP du processeur de messages vers le nœud Qpid sur le port 5672 à l'aide d'IPTables, vous pouvez utiliser une commande de ce type :
```
iptables -A INPUT -p tcp --dport 5672 -s MESSAGE_PROCESSOR_IP -j DROP
```
Redémarrez l'agent Qpid pour drainer les messages existants, le cas échéant :
```
apigee-service apigee-qpidd start
```
Assurez-vous que les files d'attente existantes sont vides. Pour le vérifier, connectez-vous au portail de gestion Qpid :
```
http://QPID_NODE_IP:8090
```
Remarque : Si ce port 8090 sur le nœud QPID n'est pas accessible, vous pouvez utiliser d'autres mécanismes, tels que le transfert de port SSH, pour accéder à cette URL.

Après avoir vérifié que les files d'attente ont été vidées, arrêtez et désinstallez Qpid :

/opt/apigee/apigee-service/bin/apigee-service apigee-qpidd stop
/opt/apigee/apigee-service/bin/apigee-service apigee-qpidd uninstall

Supprimez le répertoire de données Qpid :
```
rm -r APIGEE_ROOT/data/apigee-qpidd
```

Réinstallez l'agent Qpid :

/opt/apigee/apigee-setup/bin/setup.sh -p qs -f configFile

Une fois le courtier Qpid réinstallé, supprimez les paramètres du pare-feu et listez les paramètres existants à l'aide des commandes suivantes :
```
iptables -F
iptables -L
```

Effectuer un rollback de Postgres

Pour passer de la version 4.54.00 à la version 4.53.00/4.53.01, vous devez annuler la mise à jour de Postgres en plus des composants Edge.

Pour annuler la mise à jour de Postgres lorsque vous mettez à jour Postgres dans une configuration maître-veille :

Promouvez le nouveau nœud de secours pour qu'il devienne le maître Postgres. Le nouveau maître Postgres sera de la même version que votre installation Edge précédente.
Configurez l'ancien nœud de secours pour qu'il devienne un nœud de secours du nouveau nœud maître. L'ancien nœud de secours sera de la même version que votre installation Edge précédente.
Enregistrez les nouveaux nœuds maître et de secours auprès des groupes "analytics" et "consumer".

Une fois le rollback terminé, l'ancien nœud maître ne sera plus nécessaire. Vous pouvez ensuite mettre hors service l'ancien nœud maître.

Avant de commencer

Avant d'effectuer un rollback de Postgres 18 vers 17/14, procédez comme suit sur l'ancien et le nouvel hôte de secours pour mettre à jour la propriété max_locks_per_transaction sur apigee-postgresql :

S'il n'est pas présent, créez le fichier /opt/apigee/customer/application/postgresql.properties.

Remplacez la propriété de ce fichier par apigee :

sudo chown apigee:apigee /opt/apigee/customer/application/postgresql.properties

Ajoutez la propriété suivante au fichier :

conf/postgresql.conf+max_locks_per_transaction=30000

Configurez apigee-postgresql :

apigee-service apigee-postgresql configure

Redémarrez apigee-postgresql :

apigee-service apigee-postgresql restart

Procédure de rollback détaillée

Assurez-vous que le nouveau nœud Postgres de secours est en cours d'exécution :
```
/opt/apigee/apigee-service/bin/apigee-all status
```
Si Postgres n'est pas en cours d'exécution, démarrez-le :
```
/opt/apigee/apigee-service/bin/apigee-all start
```

Assurez-vous que Postgres est arrêté sur l'ancien nœud maître et l'ancien nœud de secours :

/opt/apigee/apigee-service/bin/apigee-all status

Si Postgres est en cours d'exécution, arrêtez-le :

/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server stop  
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql stop

Si Qpid est installé, démarrez-le sur l'ancien nœud de secours :
```
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server start
```
Remarque : Dans de nombreuses configurations, l'ancien nœud de secours n'héberge que Postgres, mais pas Qpid.
Promouvez le nouveau nœud de secours en tant que maître Postgres :
1. Promouvez le nouveau nœud de secours en tant que nouveau nœud maître :
```
apigee-service apigee-postgresql promote-standby-to-master old_master_IP
```
  Si vous y êtes invité, saisissez le mot de passe Postgres de l'utilisateur "apigee", qui est défini par défaut sur "postgres".
2. Modifiez le fichier de configuration que vous avez utilisé pour installer votre version actuelle d'Edge afin de spécifier les éléments suivants :
```
# IP address of the new master:
PG_MASTER=new_standby_IP
# IP address of the old standby node
PG_STANDBY=old_standby_IP
```
3. Configurez le nouveau maître :
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-master -f configFile
```
Si vous avez déjà mis à niveau l'ancien nœud de secours vers la version la plus récente, vous devez d'abord rétrograder le logiciel Apigee sur l'ancien nœud de secours. Si l'ancienne version est toujours présente sur l'ancien nœud de secours, vous pouvez ignorer cette étape et passer à l'étape 6.
1. Arrêtez Postgres sur l'ancien nœud de secours :
```
apigee-service apigee-postgresql stop
apigee-service edge-postgres-server stop
```
2. Désinstallez Postgres de l'ancien nœud de secours :
```
apigee-service apigee-postgresql uninstall
apigee-service edge-postgres-server uninstall
apigee-service edge-analytics uninstall
```
3. Supprimez le répertoire de données Postgres de l'ancien nœud de secours :
```
cd /opt/apigee/data/apigee-postgresql/pgdata
rm -rf *
```
4. Téléchargez et exécutez l'ancien bootstrap de version (pour la version Apigee vers laquelle vous effectuez le rollback) sur l'ancien nœud de secours. La procédure exacte peut varier selon que vous utilisez une installation en ligne ou hors connexion. L'exécution de l'ancienne version d'Apigee Bootstrap configure les dépôts yum avec les données de l'ancienne version d'Apigee.
5. Configurez les composants Postgres sur l'ancien nœud standby :
```
/opt/apigee/apigee-setup/bin/setup.sh -p ps -f configFile
```
6. Vérifiez que les composants Postgres de l'ancien nœud de secours ont été rétablis à l'ancienne version :
```
apigee-service apigee-postgresql version
apigee-service edge-postgres-server version
```

Remarque : Assurez-vous de supprimer le RPM postgresql18-libs-18.3-1PGDG s'il existe encore.

Recréez l'ancien nœud de secours :
1. Modifiez le fichier de configuration que vous avez utilisé pour installer votre version actuelle d'Edge afin de spécifier les éléments suivants :
```
# IP address of the new master:
PG_MASTER=new_standby_IP
# IP address of the old standby node
PG_STANDBY=old_standby_IP
```
2. Supprimez le répertoire de données de l'ancien nœud de secours :
```
cd /opt/apigee/data/apigee-postgresql/pgdata
rm -rf *
```
3. Reconfigurez l'ancien nœud de secours pour qu'il devienne un nœud de secours du nouveau maître :
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-standby -f configFile
```
4. Assurez-vous que Postgres est en cours d'exécution sur l'ancien nœud de secours :
```
/opt/apigee/apigee-service/bin/apigee-all status
```
  Si Postgres n'est pas en cours d'exécution, démarrez-le :
```
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server start
```
Vérifiez que le nouveau nœud de secours a été ajouté en consultant le fichier /opt/apigee/apigee-postgresql/conf/pg_hba.conf sur le nouveau maître.

Affichez les informations actuelles sur les groupes "analytics" et "consumer" en exécutant la commande suivante sur le serveur de gestion :

curl -u sysAdminEmail:password http://ms_IP:8080/v1/analytics/groups/ax

Cette commande renvoie le nom du groupe Analytics dans le champ name et le nom du groupe de consommateurs dans le champ name sous consumer-groups. Il renvoie également les UUID des anciens nœuds maître et de secours Postgres dans le champ postgres-server et dans le champ datastores. Le résultat doit se présenter comme suit :

{
  "name" : "axgroup-001",
  "properties" : {
  },
  "scopes" : [ "VALIDATE~test", "sgilson~prod" ],
  "uuids" : {
    "qpid-server" : [ "8381a053-433f-4382-bd2a-100fd37a1592", "4b6856ec-ef05-498f-bac6-ef5f0d5f6521" ],
    "postgres-server" : [
      "ab1158bd-1d59-4e2a-9c95-24cc2cfa6edc:27f90844-efab-4b32-8a23-8f85cdc9a256"
    ]
  },
  "consumer-groups" : [ {
    "name" : "consumer-group-001",
    "consumers" : [ "8381a053-433f-4382-bd2a-100fd37a1592", "4b6856ec-ef05-498f-bac6-ef5f0d5f6521" ],
    "datastores" :
      [ "ab1158bd-1d59-4e2a-9c95-24cc2cfa6edc:27f90844-efab-4b32-8a23-8f85cdc9a256" ],
      "properties" : {     }
    }
  ],
  "data-processors" : {
  }
}

Obtenez l'adresse UUID de l'ancien maître en exécutant la commande curl suivante sur l'ancien nœud maître :
```
curl -u sysAdminEmail:password http://node_IP:8084/v1/servers/self
```
L'UUID du nœud doit s'afficher à la fin du résultat, sous la forme suivante :
```
"type" : [ "postgres-server" ],
"uUID" : "599e8ebf-5d69-4ae4-aa71-154970a8ec75"
```
Remarque : Le service edge-postgres-server doit être en cours d'exécution. Si le serveur Postgres n'est pas en cours d'exécution, vous pouvez exécuter la commande suivante sur le serveur de gestion pour déterminer l'UUID :
```
curl -u sysAdminEmail:password http://ms_IP:8080/v1/servers?pod=analytics
```
Le résultat de cette commande liste l'UUID de l'adresse IP de chaque nœud Postgres.
Répétez l'étape précédente pour obtenir les adresses IP de l'ancien nœud de secours et du nouveau nœud maître.
Supprimez les anciens nœuds maître et de secours du groupe de consommateurs :
```
curl -u sysAdminEmail:password -X DELETE \
  "http://ms_IP:8080/v1/analytics/groups/ax/axgroup-001/consumer-groups/consumer-group-001/datastores/masterUUID,standbyUUID" -v
```
Où axgroup-001 et consumer-group-001 sont les noms par défaut des groupes "analytics" et "consumer". masterUUID,standbyUUID sont dans le même ordre que celui dans lequel ils sont apparus ci-dessus lorsque vous avez consulté les informations actuelles sur les groupes d'analyse et de consommateurs. Vous devrez peut-être les spécifier en tant que standbyUUID,masterUUID.

La propriété datastores pour consumer-groups doit maintenant être vide.

Supprimez les anciens nœuds maître et de secours du groupe "analytics" :

curl -u sysAdminEmail:password -X DELETE \
  "http://ms_IP:8080/v1/analytics/groups/ax/axgroup-001/servers?uuid=masterUUID,standbyUUID&type=postgres-server" -v

La propriété postgres-server sous uuids doit maintenant être vide.

Enregistrez les nouveaux nœuds PG principal et de secours auprès des groupes "analytics" et "consumer" :

curl -u sysAdminEmail:password -X POST -H "Content-Type: application/json" -d ''
  "http://ms_IP:8080/v1/analytics/groups/ax/axgroup-001/servers?uuid=masterUUID,standbyUUID&type=postgres-server" -v
curl -u sysAdminEmail:password -X POST -H "Content-Type:application/json" -d ''
  "http://ms_IP:8080/v1/analytics/groups/ax/axgroup-001/consumer-groups/consumer-group-001/datastores?uuid=masterUUID,standbyUUID" -v

Validez le groupe "analytics" :
```
curl -u sysAdminEmail:password http://ms_IP:8080/v1/analytics/groups/ax
```
Les UUID des nouveaux nœuds maître et de secours doivent figurer dans le groupe d'analyse et le groupe de consommateurs.

Redémarrez le serveur Edge Management :

/opt/apigee/apigee-service/bin/apigee-service edge-management-server restart

Redémarrez tous les serveurs Qpid :

/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart

Redémarrez tous les serveurs Postgres :

/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart

Vérifiez l'état de la réplication en exécutant les scripts suivants sur les deux serveurs. Le système doit afficher des résultats identiques sur les deux serveurs pour garantir une réplication réussie :
Sur le nouveau maître, exécutez la commande suivante :
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-master
```
Vérifiez qu'il s'agit du maître. Sur l'ancien nœud de secours, exécutez la commande suivante :
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-standby
```
Vérifiez qu'il s'agit bien du nœud de secours.
Répétez l'étape précédente après avoir effectué plusieurs requêtes API pour vous assurer que les nœuds sont synchronisés.
Mettez hors service l'ancien maître Postgres :
Remarque : Si l'ancien nœud maître exécutait Qpid, vous pouvez laisser ce serveur en place pour exécuter Qpid. Assurez-vous qu'il est en cours d'exécution. Si ce n'est pas le cas, démarrez-le :
```
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server start
/opt/apigee/apigee-service/bin/apigee-service apigee-qpidd start
```
Vous pouvez également désinstaller Qpid de l'ancien nœud maître et l'installer sur le nouveau nœud maître. Après avoir désinstallé Qpid, vous pouvez mettre hors service l'ancien nœud maître.

Revenir à l'ancienne interface utilisateur Edge

Apigee Edge for Private Cloud 4.54.00 remplace l'UI classique (edge-ui) par la nouvelle UI Edge (edge-management-ui). Étant donné que le composant d'UI change dans la version 4.54.00, le rollback vers la version 4.53.00 ou 4.53.01 nécessite de désinstaller edge-management-ui et de réinstaller votre profil d'UI précédent :

UI classique (edge-ui) : réinstallez le profil ui.
Nouvelle interface utilisateur Edge (edge-ui et edge-management-ui) : réinstallez les profils ui et ue dans leurs nœuds respectifs.

Pour effectuer un rollback de l'UI sur un nœud :

Arrêtez et désinstallez la nouvelle interface utilisateur Edge 4.54.00, puis installez la version précédente pour effectuer un rollback :

Arrêtez et désinstallez la nouvelle UI Edge 4.54.00 (edge-management-ui) :

/opt/apigee/apigee-service/bin/apigee-service edge-management-ui stop
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui uninstall
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui-static uninstall

Exécutez le fichier bootstrap pour Apigee Edge pour le cloud privé 4.53.00/4.53.01 :

# Download bootstrap for 4.53.00
curl https://software.apigee.com/bootstrap_4.53.00.sh -o /tmp/bootstrap_4.53.00.sh -u uName:pWord

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

Effectuez un rollback de apigee-setup de la version 4.54.00 vers la version précédente :

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

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

Restaurez vos configurations d'interface utilisateur 4.53.00/4.53.01 :
- Si vous avez sauvegardé le fichier de configuration silencieuse de votre installation 4.53.00 ou 4.53.01, utilisez ce fichier de sauvegarde pour la procédure de rollback. Sinon, dans votre fichier de configuration silencieux 4.54.00, restaurez ou décommentez les propriétés d'interface utilisateur 4.53.00 ou 4.53.01 qui ont été supprimées ou commentées lors de la mise à niveau. Pour en savoir plus, consultez la section Mise à niveau de l'interface utilisateur.
- Si /opt/apigee/customer/application/ui.properties a été supprimé lors de la mise à niveau, restaurez-le à partir du répertoire de sauvegarde :
```
cp -rf /opt/apigee/backup/ui/customer/application/ui.properties /opt/apigee/customer/application/
chown apigee:apigee /opt/apigee/customer/application/ui.properties
```
Réinstallez et configurez la version précédente de l'UI :
- Revenir à l'UI classique (edge-ui) :
  1. Installez et configurez l'UI classique (pour l'authentification de base, aucune étape supplémentaire n'est requise) :
```
/opt/apigee/apigee-setup/bin/setup.sh -p ui -f configFile
```
  2. Si l'authentification unique est activée, configurez-la dans l'UI classique (assurez-vous d'abord que apigee-sso est en cours d'exécution) :
```
/opt/apigee/apigee-service/bin/apigee-service edge-ui configure-sso -f configFile
```
- Rétrograder vers la version 4.53.00 ou 4.53.01 de la nouvelle interface utilisateur Edge (edge-management-ui et Shoehorn edge-ui) :
  1. Assurez-vous que EDGEUI_ENABLE_UNIFIED_UI=y est défini dans le fichier de configuration silencieuse, puis installez et configurez les profils ui et ue :
```
/opt/apigee/apigee-setup/bin/setup.sh -p ui -f configFile
/opt/apigee/apigee-setup/bin/setup.sh -p ue -f configFile
```
  2. Si le SSO est activé, configurez-le sur les deux composants de l'UI (assurez-vous que apigee-sso est en cours d'exécution en premier) :
```
/opt/apigee/apigee-service/bin/apigee-service edge-ui configure-sso -f configFile
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui configure-sso -f configFile
```
Remarque : Dans une topologie multinœud où l'UI classique et la nouvelle UI Edge 4.53.01 étaient hébergées sur des nœuds distincts, exécutez les commandes de rollback sur leurs hôtes respectifs. La commande configure-sso ne doit être exécutée que si l'authentification unique a été configurée dans la version précédente.
- Nœud 1 (nœud de l'UI classique) : exécutez les commandes de l'UI classique :
```
/opt/apigee/apigee-setup/bin/setup.sh -p ui -f configFile
/opt/apigee/apigee-service/bin/apigee-service edge-ui configure-sso -f configFile
```
- Nœud 2 (nouveau nœud d'UI Edge) : exécutez les commandes de la nouvelle UI Edge (setup.sh -p ue et edge-management-ui configure-sso) :
```
/opt/apigee/apigee-setup/bin/setup.sh -p ue -f configFile
/opt/apigee/apigee-service/bin/apigee-service edge-ui configure-sso -f configFile
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui configure-sso -f configFile
```

Vérifiez l'état et la version de l'UI après le rollback :

Pour l'UI classique (edge-ui) :

/opt/apigee/apigee-service/bin/apigee-service edge-ui status
/opt/apigee/apigee-service/bin/apigee-service edge-ui version

Pour la nouvelle UI Edge (edge-management-ui) :

/opt/apigee/apigee-service/bin/apigee-service edge-management-ui status
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui version

Remarque : Dans les versions d'Apigee Edge pour le cloud privé antérieures à la version 4.54.00, l'ancienne interface utilisateur Edge (edge-ui) et la nouvelle interface utilisateur Edge (edge-management-ui) ne pouvaient pas coexister sur le même nœud. Les administrateurs devaient provisionner des nœuds dédiés distincts pour chaque composant d'UI lorsqu'ils exécutaient ces versions antérieures.

Effectuer un rollback d'OpenLDAP

Cette section fournit un guide par étapes pour effectuer un rollback de Symas OpenLDAP 2.6.10 dans Edge for Private Cloud 4.54.00 vers OpenLDAP 2.4.46 (Edge for Private Cloud 4.53.00) ou Symas OpenLDAP 2.6.7 (Edge for Private Cloud 4.53.01). Vous devez effectuer le rollback sur l'ensemble du cluster LDAP à l'aide d'une sauvegarde LDAP valide effectuée avant la mise à niveau.

L'objectif principal est de rétablir l'ensemble du cluster LDAP dans un état cohérent à partir d'une sauvegarde fiable connue. Cette procédure est identique pour tous les scénarios : serveur unique, actif-actif et actif-passif.

Avant de commencer

Incompatibilité de la sauvegarde : utilisez une sauvegarde préalable à la mise à niveau d'OpenLDAP 2.4.46 (Edge pour le cloud privé 4.53.00) ou de Symas OpenLDAP 2.6.7 (Edge pour le cloud privé 4.53.01) effectuée à l'aide de apigee-service apigee-openldap backup avant la tentative de mise à niveau. Les sauvegardes effectuées après la mise à niveau sont incompatibles et ne peuvent pas être utilisées.
Indisponibilité de l'API Management : lors de la restauration LDAP, les API Management seront indisponibles, ce qui peut avoir un impact sur les tâches d'administration. Arrêtez toutes les instances edge-management-server et edge-ui avant de procéder au rollback LDAP.
Remarque : Si vous utilisez la nouvelle UI Edge (edge-management-ui), veillez à arrêter l'UI classique (edge-ui) et la nouvelle UI Edge (edge-management-ui).
Risque de perte de données : si vous continuez sans sauvegarde valide et compatible, vous risquez de perdre des données de manière irréversible.
Sauvegarde valide : une sauvegarde LDAP valide avant la mise à niveau est requise.
Sauvegarde des fichiers silent.conf : conservez des sauvegardes de vos fichiers silent.conf des versions précédente et actuelle pour éviter les erreurs de configuration lors des procédures de mise à niveau et de rétablissement.
Séquence de rollback : effectuez les procédures de rollback pour Cassandra, ZooKeeper, Qpid, PostgreSQL, apigee-sso et l'interface utilisateur Edge avant d'effectuer le rollback d'OpenLDAP.

Procédure de rollback

Arrêtez le serveur de gestion et l'UI : arrêtez toutes les instances edge-management-server et edge-ui avant de procéder au rollback LDAP :
```
apigee-service edge-management-server stop
apigee-service edge-ui stop
```
Enregistrez le nombre actuel d'entrées LDAP (avant d'arrêter LDAP) : obtenez le nombre total d'enregistrements pour référence à partir de tous les serveurs LDAP, en remplaçant YOUR_PASSWORD par le mot de passe actuel de votre gestionnaire LDAP. (Le nombre d'enregistrements doit être identique sur tous les serveurs LDAP.)
```
# Note: Replace 'YOUR_PASSWORD' with your current LDAP manager password.
ldapsearch -o ldif-wrap=no -b "dc=apigee,dc=com" -D "cn=manager,dc=apigee,dc=com" -H ldap://:10389 -LLL -x -w 'YOUR_PASSWORD' | wc -l
```
Arrêtez et désinstallez le nouveau LDAP 2.6 : arrêtez le service apigee-openldap, puis supprimez sa configuration et ses répertoires de données. Effectuez cette étape sur tous les serveurs LDAP, un nœud à la fois dans le cluster, pour garantir la cohérence :
```
apigee-service apigee-openldap stop
apigee-service apigee-openldap uninstall
rm -rf /opt/apigee/data/apigee-openldap/*
```

Installez la version précédente de LDAP 2.4.46 ou 2.6.7 :

Installer l'ancienne version de LDAP :

/opt/apigee/apigee-setup/bin/setup.sh -p ld -f /opt/silent.conf

Valider la version LDAP :

source ~/.bash_profile
ldapsearch -VV

# Expected output if rolled back to 4.53.00:
ldapsearch: @(#) $OpenLDAP: ldapsearch 2.4.46

# Expected output if rolled back to 4.53.01:
ldapsearch: @(#) $OpenLDAP: ldapsearch 2.6.7

Répétez les sous-étapes précédentes de l'étape 4 sur chaque nœud LDAP, un par un.

Nettoyez les données résiduelles : sur tous les serveurs LDAP, un par un, arrêtez le service nouvellement installé et nettoyez son répertoire de données pour préparer la restauration à partir de la sauvegarde :
```
apigee-service apigee-openldap stop
rm -rf /opt/apigee/data/apigee-openldap/*
```
Restaurer les données LDAP : pour une configuration à serveur unique, passez directement à l'étape 6b. Pour une configuration multiserveur, passez à l'étape 6a.
1. Identifier le serveur LDAP actif : avant de restaurer les données LDAP, identifiez le serveur actif (fournisseur) en exécutant la commande suivante :
```
grep -i '^olcSyncrepl:' /opt/apigee/data/apigee-openldap/slapd.d/cn=config/olcDatabase*.ldif
```
  Remarque :
  1. Si cette commande renvoie un résultat, le serveur est un serveur passif.
  2. Si cette commande ne renvoie aucun résultat, le serveur est le serveur actif.
2. Restaurez les données LDAP (assurez-vous que l'étape 5 est terminée sur tous les serveurs avant de procéder à la restauration) :
  - Sur le serveur LDAP unique ou actif (déterminé à l'étape 6a), accédez au répertoire de sauvegarde et restaurez la sauvegarde effectuée avant la mise à niveau (par exemple, 2025.07.28,13.59.00, ou omettez le code temporel si la sauvegarde effectuée avant la mise à niveau est la dernière sauvegarde du répertoire) :
```
cd /opt/apigee/backup/openldap

# To restore a specific backup, provide the timestamp as shown below:
apigee-service apigee-openldap restore 2025.07.28,13.59.00

# Note: If no timestamp is provided, the latest available backup will be restored by default:
apigee-service apigee-openldap restore

# It is recommended to specify the backup explicitly to avoid restoring an unintended version.
```
  - Démarrez le service apigee-openldap :
```
apigee-service apigee-openldap start
```
Démarrez les serveurs LDAP restants : si vous avez une configuration multiserveur, démarrez le service sur chacun des serveurs LDAP restants :
```
apigee-service apigee-openldap start
```
Remarque : Vous n'avez pas besoin de restaurer manuellement les données sur ces serveurs pairs. Au démarrage, ils se connecteront au premier serveur (qui contient désormais les données restaurées) et synchroniseront automatiquement l'ensemble du répertoire par réplication.
Validation finale :
- Vérifiez que le rollback a bien fonctionné et que les données sont cohérentes dans l'ensemble du cluster LDAP.
- Exécutez la commande de validation sur tous les serveurs LDAP, en remplaçant YOUR_PASSWORD par votre mot de passe de gestionnaire LDAP actuel. Le nombre d'enregistrements doit être identique sur tous les serveurs et doit correspondre au nombre que vous avez relevé à l'étape 2 :
```
# Note: Replace 'YOUR_PASSWORD' with your current LDAP manager password.
ldapsearch -o ldif-wrap=no -b "dc=apigee,dc=com" -D "cn=manager,dc=apigee,dc=com" -H ldap://:10389 -LLL -x -w 'YOUR_PASSWORD' | wc -l
```
- Une fois que vous avez confirmé que les données sont correctes et cohérentes, démarrez edge-management-server, edge-ui et tous les autres composants dépendants selon la procédure standard de votre organisation.

Effectuer un rollback des composants Edge

Composants avec du 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 revenir à la version précédente des trois pour revenir à la version précédente de l'un d'eux.

Pour revenir à une version majeure ou mineure précédente, procédez comme suit sur chaque nœud hébergeant le composant :

Téléchargez le fichier bootstrap.sh pour la version vers laquelle vous souhaitez effectuer un rollback :
- Pour effectuer un rollback vers la version 4.53.00/4.53.01, téléchargez bootstrap_4.53.00.sh/bootstrap_4.53.01.sh.

Arrêtez le composant pour effectuer un rollback :

Pour effectuer un rollback de l'un des composants avec du 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 effectuer un rollback d'un autre composant sur le nœud, arrêtez uniquement ce composant :
```
/opt/apigee/apigee-service/bin/apigee-service component stop
```

Si vous effectuez un rollback de la monétisation, désinstallez-la de tous les nœuds Management Server et Processeur de messages :
```
/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 effectuer un rollback de l'un des composants avec du code commun sur le nœud, vous devez tous les désinstaller en désinstallant le groupe de composants edge-gateway et apigee-cassandra-client, comme illustré dans l'exemple suivant :
```
/opt/apigee/apigee-service/bin/apigee-service edge-gateway uninstall
```
```
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra-client uninstall
```
2. Pour effectuer un rollback de Nginx :
```
### Find the apigee-nginx RPM
rpm -qa | grep -i "apigee-nginx"

### Remove the apigee-nginx RPM
dnf remove apigee-nginx-1.30.x
```
3. Pour effectuer un rollback de tout autre composant sur le nœud, désinstallez uniquement ce composant, comme illustré dans l'exemple suivant :
```
/opt/apigee/apigee-service/bin/apigee-service component uninstall
```
  où component est le nom du composant.
  Remarque : Si edge-analytics ne se désinstalle pas automatiquement en même temps que edge-qpid-server et edge-postgres-server, désinstallez-le manuellement à l'aide de la commande suivante :
```
/opt/apigee/apigee-service/bin/apigee-service edge-analytics uninstall
```
4. Pour rétablir la version précédente d'Edge Router, 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.54.00 de apigee-setup :

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

Installez la version 4.53.00 de l'utilitaire apigee-service et ses dépendances. L'exemple suivant installe la version 4.53.00 de apigee-service :
```
sudo bash /tmp/bootstrap_4.53.00.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 êtes 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 iptables :
```
sudo iptables -F
```
Répétez cette procédure pour chaque nœud qui héberge le composant que vous annulez.

Remarque : Lorsque vous désinstallez apigee-cassandra-client, apigee-provision et apigee-validate sont automatiquement supprimés en raison de leur dépendance. Si vous en avez besoin par la suite, vous devrez les réinstaller.

Effectuer un rollback de mTLS

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

Arrêtez 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