Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Esegui il rollback di Apigee Edge 4.54.00

Se si verifica un errore durante un aggiornamento a Edge 4.54.00, puoi eseguire il rollback del componente che ha causato l'errore e riprovare l'aggiornamento.

Puoi eseguire il rollback di Edge 4.54.00 a una delle seguenti versioni di release principali:

Versione 4.53.00
Versione 4.53.01

Per ulteriori informazioni, consulta il processo di rilascio di Apigee Edge.

Ordine di rollback

Il rollback dei componenti deve essere eseguito nell'ordine inverso rispetto all'upgrade. Di seguito è riportato un ordine generale tipico di rollback per Private Cloud 4.54.00:

Esegui il rollback di Cassandra, Zookeeper.
Esegui il rollback di Qpid, di altri componenti correlati ad Analytics e di Postgres.
Esegui il rollback della UI
Esegui il rollback di LDAP.
Esegui il rollback del server di gestione.
Esegui il rollback dei router e dei processori di messaggi.

Ad esempio, supponiamo che tu abbia eseguito l'upgrade di tutti i router e i processori di messaggi, di tutti i server di gestione, di LDAP e di alcuni nodi UI alla versione 4.54.00 dalla versione 4.53.00 (o) 4.53.01 e voglia eseguire il rollback. In questo caso, dovresti:

Esegui il rollback dei nodi della UI aggiornata
Esegui il rollback dei nodi LDAP
Esegui il rollback dei nodi del server di gestione uno alla volta
Esegui il rollback di tutti gli RMP uno alla volta

Nota:l'SSO Apigee in Apigee Edge per Private Cloud 4.54.00 non supporta i rollback diretti o parziali. Per revertire Apigee SSO, devi eseguire il rollback di tutti i componenti aggiornati in precedenza e ripristinare apigee-sso utilizzando il file di configurazione silenziosa della versione precedente.

Riavvia o reinstalla apigee-sso:

Se hai arrestato solo apigee-sso durante l'upgrade, riavvia il servizio.
Se hai disinstallato apigee-sso durante l'upgrade, reinstallalo utilizzando il file di configurazione non interattivo della versione precedente:
- 4.53.01 Passaggi di installazione
- 4.53.00 Passaggi per l'installazione

Chi può eseguire un rollback

L'utente che esegue il rollback deve essere lo stesso che ha aggiornato originariamente Edge o un utente che esegue l'accesso come root.

Per impostazione predefinita, i componenti Edge vengono eseguiti come utente "apigee". In alcuni casi, potresti eseguire i componenti Edge come utenti diversi. Ad esempio, se il router deve accedere a porte con privilegi, come quelle inferiori a 1000, devi eseguire il router come utente root o come utente con accesso a queste porte. In alternativa, potresti eseguire un componente come un utente e un altro componente come un altro utente.

Esegui il rollback di Cassandra

Quando viene eseguito un upgrade principale di Cassandra su un nodo specifico, Cassandra modifica lo schema dei dati archiviati su quel nodo. Di conseguenza, un rollback diretto in loco non è fattibile.

Scenari di rollback

La tabella seguente riassume le strategie di rollback che puoi utilizzare:

Scenario	Strategia di rollback
DC singolo, upgrade di alcuni nodi Cassandra	Utilizza i backup
Più data center, upgrade di alcuni nodi in un data center	Ricostruire da un DC esistente
Più data center, tutti i nodi Cassandra in alcuni data center sono stati aggiornati	Ricostruire da un DC esistente
Più data center, nodi Cassandra dell'ultimo data center in fase di upgrade	Prova a completare l'upgrade. Se non è fattibile, esegui il rollback di 1 DC utilizzando il backup. Ricostruisci i DC rimanenti dal DC di cui è stato eseguito il rollback.

Considerazioni generali

Quando valuti un rollback, tieni presente quanto segue:

Rollback di Cassandra durante l'upgrade di Cassandra: se riscontri problemi durante l'upgrade di Cassandra, ti consigliamo di eseguire un rollback. Segui le strategie di rollback descritte in questo articolo in base allo stato in cui ti trovi durante il processo di upgrade.
Rollback utilizzando i backup: i backup eseguiti da Cassandra 5.0.X non sono compatibili con i backup di Cassandra 4.0.X. Per eseguire il rollback di Cassandra utilizzando il ripristino del backup, devi eseguire i backup di Cassandra 4.0.X prima di tentare l'upgrade.

Esegui il rollback di Cassandra utilizzando la ricostruzione

Prerequisiti

Stai utilizzando un cluster Edge for Private Cloud 4.53.00/4.53.01 in più data center.
Stai eseguendo l'upgrade di Cassandra dalla versione 4.0.X alla versione 5.0.X e hai riscontrato problemi durante l'upgrade.
Nel cluster è presente almeno un data center completamente funzionante che esegue ancora la versione precedente di Cassandra (Cassandra 4.0.X).

Questa procedura si basa sullo streaming dei dati da un data center esistente. Potrebbe essere necessario molto tempo, a seconda della quantità di dati archiviati in Cassandra. Devi prepararti a deviare il traffico di runtime da questo data center mentre è in corso il rollback.

Passaggi di livello avanzato

Seleziona un data center (di cui è stato eseguito l'upgrade parziale o completo) di cui vuoi eseguire il rollback. Devia il traffico di runtime a un altro data center funzionante.
Identifica il nodo seed nel data center e inizia con uno dei nodi seed.
Arresta, disinstalla e pulisci il nodo Cassandra.
Installa la versione precedente di Cassandra sul nodo e configurala in base alle esigenze.
Rimuovi le configurazioni aggiuntive aggiunte in precedenza.
Ripeti i passaggi precedenti per tutti i nodi seed nel data center, uno alla volta.
Ripeti i passaggi precedenti per tutti i nodi Cassandra rimanenti nel data center, uno alla volta.
Ricostruisci i nodi dal data center funzionale esistente, uno alla volta.
Riavvia tutti i componenti edge-* nel data center connessi a Cassandra.
Testa e reindirizza il traffico a questo data center.
Ripeti i passaggi per ogni data center, uno alla volta.

Procedura dettagliata

Scegli un data center in cui viene eseguito l'upgrade di tutti o di alcuni nodi Cassandra. Devia tutto il traffico del proxy di runtime e il traffico di gestione da questo data center mentre viene eseguito il rollback dei nodi Cassandra in questo data center. Assicurati che tutti i nodi Cassandra siano nello stato UN (Up/Normal) quando il comando nodetool ring viene eseguito sui nodi. Se alcuni nodi non sono attivi, risolvi i problemi e riattivali prima di continuare.

Vedi il seguente esempio:

/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

Puoi eseguire nodetool describecluster sui nodi per comprendere lo stato attuale dell'intero cluster. Ad esempio, di seguito è riportata un'istanza di un cluster con due data center in cui tutti i nodi DC-1 sono su Cassandra versione 4, mentre tutti i nodi DC-2 sono su Cassandra versione 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:
    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]

Identifica i nodi seed nel data center: consulta la sezione Come identificare i nodi seed nell'Appendice. Esegui i passaggi riportati di seguito su uno dei nodi seed:

Arresta, disinstalla e pulisci i dati dal nodo di Cassandra. Scegli il primo nodo seed su Cassandra versione 5 in questo data center. Smettila.

# 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

Installa il software Cassandra precedente sul nodo e imposta alcune configurazioni. Esegui il file di bootstrap di Edge for Private Cloud 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

Crea o modifica il file /opt/apigee/customer/application/cassandra.properties.
Aggiungi i seguenti contenuti al file. ipOfNode è l'indirizzo IP del nodo che Cassandra utilizza per comunicare con gli altri nodi Cassandra:
```
conf_jvm_options_custom_settings=-Dcassandra.replace_address=ipOfNode -Dcassandra.allow_unsafe_replace=true
```
Assicurati che il file sia di proprietà dell'utente Apigee e che possa essere letto:
```
chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
```
Installa e configura 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

Verifica che il nodo sia stato avviato. Controlla il seguente comando su questo nodo e sugli altri nodi del cluster. Il nodo dovrebbe segnalare che si trova nello stato "UN" (Up/Normal):
```
/opt/apigee/apigee-cassandra/bin/nodetool status
```
Rimuovi dal file /opt/apigee/customer/application/cassandra.properties le configurazioni aggiuntive aggiunte in precedenza.
Ripeti i passaggi da 3 a 10 su tutti i nodi seed Cassandra nel data center, uno alla volta.
Ripeti i passaggi da 3 a 10 su tutti i nodi Cassandra rimanenti nel data center, uno alla volta.
Ricostruisci tutti i nodi nel data center da un data center che esegue la versione precedente di Cassandra. Esegui questo passaggio un nodo alla volta:
```
/opt/apigee/apigee-cassandra/bin/nodetool rebuild -dc <name of working DC>
```
Questa procedura potrebbe richiedere del tempo. Se necessario, puoi modificare streamingthroughput. Controlla nodetool netstats per lo stato del completamento dell'operazione.
(Facoltativo) Esegui il comando di riparazione nel nodo Cassandra se i dati non vengono ricreati.
```
/opt/apigee/apigee-cassandra/bin/nodetool -h node-IP repair -pr
```

Riavvia tutti i componenti edge-* nel data center, uno alla volta:

/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

Convalida e devia nuovamente il traffico verso questo data center. Esegui alcune convalide per il traffico di runtime e le API di gestione in questo data center e inizia a reindirizzare il traffico del proxy e dell'API di gestione verso questo data center.
Ripeti i passaggi precedenti per ogni data center di cui vuoi eseguire il rollback.

Eseguire il rollback di Cassandra utilizzando il backup

Prerequisiti

Stai eseguendo l'upgrade di Cassandra dalla versione 4.0.X alla 5.0.X e hai riscontrato problemi durante l'upgrade.
Disponi di backup per il nodo di cui stai eseguendo il rollback. Il backup è stato eseguito prima del tentativo di upgrade dalla versione 4.0.X alla versione 5.0.X.

Passaggi

Seleziona un nodo di cui vuoi eseguire il rollback. Se esegui il rollback di tutti i nodi in un data center utilizzando i backup, inizia prima con i nodi seed. Consulta la sezione Come identificare i nodi seed nell'appendice.

Arresta, disinstalla e pulisci il nodo 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

Installa il software Cassandra precedente sul nodo e configuralo:

Esegui il file di bootstrap per 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

Crea o modifica il file /opt/apigee/customer/application/cassandra.properties:

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

Assicurati che il file sia di proprietà dell'utente apigee e che sia leggibile:

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

Installa e configura 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

Verifica che il nodo sia stato avviato. Controlla il seguente comando su questo nodo e sugli altri nodi del cluster. I nodi devono segnalare che questo nodo si trova nello stato "UN":

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

Arresta il servizio Cassandra e ripristina il backup. Per ulteriori dettagli, consulta la documentazione relativa a backup e ripristino:

# 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

Una volta ripristinato il backup, rimuovi le configurazioni aggiuntive:

Rimuovi la configurazione aggiunta in precedenza dal file /opt/apigee/customer/application/cassandra.properties.

Avvia il servizio Cassandra sul nodo:

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

Ripeti i passaggi su ogni nodo Cassandra di cui vuoi eseguire il rollback utilizzando i backup, uno alla volta.

Una volta ripristinati tutti i nodi Cassandra, riavvia tutti i componenti edge-* uno alla volta:

/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

Ottimizzazioni dei backup (opzione avanzata)

Se hai a disposizione repliche che contengono i dati più recenti, puoi potenzialmente ridurre al minimo (o eliminare) la perdita di dati durante il ripristino dei backup. Se sono disponibili repliche, dopo aver ripristinato il backup, esegui una riparazione sul nodo ripristinato.

Appendice

Come identificare i nodi seed

Su qualsiasi nodo Cassandra in un data center, esegui questo comando:

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

Il comando restituirà più righe. Cerca l'ultima riga dell'output. Gli indirizzi IP elencati nell'ultima riga sono i nodi seed. Nell'esempio seguente, DC-1-IP1, DC-1-IP2, DC-2-IP1 e DC-2-IP2 sono gli IP dei nodi 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

Esegui il rollback di ZooKeeper

Esegui il rollback

Se è necessario un rollback:

Esegui i passaggi di rollback prima su osservatori e follower. Per selezionare osservatori e follower, consulta Identifica leader, follower e osservatori.
Scarica ed esegui il bootstrap della versione di cui stai eseguendo il rollback, ovvero 4.53.00/4.53.01. La procedura probabilmente varia a seconda che il nodo abbia una connessione a internet esterna o che tu stia seguendo l'installazione offline.

Arresta ZooKeeper se è in esecuzione sul nodo:

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

Disinstalla ZooKeeper esistente:

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

Installa Zookeeper come di consueto:

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

Una volta eseguito il rollback di tutti i follower e gli osservatori, esegui il rollback del nodo leader seguendo i passaggi da 2 a 5 sul nodo leader.
Dopo aver eseguito il rollback di tutti i nodi, verifica l'integrità del cluster e assicurati che nel cluster sia presente un nodo leader.

Ripristina backup

Consulta Ripristino da un backup.

Esegui il rollback di Qpid

Nota:esegui il rollback di apigee-qpidd prima di tentare di eseguire il rollback di altri componenti di Edge (edge-qpid-server, edge-message-processor, edge-management-server).

Per eseguire il rollback a una release di funzionalità precedente, assicurati di scaricare il file bootstrap.sh per la versione di cui vuoi eseguire il rollback. Per eseguire il rollback alla versione 4.53.00/4.53.01, scarica bootstrap_4.53.00.sh.

Per eseguire il rollback di Qpid, segui questi passaggi su tutti gli host Qpid:

Arresta il broker Qpid esistente:
```
apigee-service apigee-qpidd stop
```
Blocca il traffico in entrata sulla porta del broker 5672 da tutti i processori di messaggi applicando un firewall. Puoi applicare questo firewall a livello dell'istanza del nodo Qpid o di un altro componente di rete/firewall esterno.
Ti consigliamo di eseguire lo stesso passaggio per tutti gli indirizzi IP del processore di messaggi. Ad esempio, per eliminare le richieste provenienti dagli indirizzi IP del processore di messaggi al nodo Qpid sulla porta 5672 utilizzando IPTables, puoi utilizzare un comando come questo:
```
iptables -A INPUT -p tcp --dport 5672 -s MESSAGE_PROCESSOR_IP -j DROP
```
Avvia di nuovo il broker Qpid per svuotare i messaggi esistenti, se presenti:
```
apigee-service apigee-qpidd start
```
Assicurati che le code esistenti siano vuote. Per verificare, accedi al portale di gestione Qpid:
```
http://QPID_NODE_IP:8090
```
Nota: se questa porta 8090 sul nodo QPID non è accessibile, puoi utilizzare meccanismi alternativi come il port forwarding SSH per accedere a questo URL.

Dopo aver verificato che le code sono state svuotate, arresta e disinstalla Qpid:

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

Elimina la directory dei dati Qpid:
```
rm -r APIGEE_ROOT/data/apigee-qpidd
```

Reinstalla il broker Qpid:

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

Una volta reinstallato il broker Qpid, rimuovi le impostazioni del firewall ed elenca le impostazioni esistenti utilizzando i seguenti comandi:
```
iptables -F
iptables -L
```

Esegui il rollback di Postgres

Per eseguire il downgrade dalla versione 4.54.00 alla versione 4.53.00/4.53.01, devi eseguire il rollback dell'aggiornamento di Postgres oltre ai componenti Edge.

Per eseguire il rollback dell'aggiornamento di Postgres durante l'aggiornamento di Postgres in una configurazione master-standby:

Promuovi il nuovo nodo di standby affinché diventi il master Postgres. Il nuovo master Postgres sarà della stessa versione della precedente installazione di Edge.
Configura il vecchio nodo in standby in modo che sia un nodo in standby del nuovo master. Il vecchio nodo di standby avrà la stessa versione dell'installazione precedente di Edge.
Registra i nuovi nodi master e di standby con i gruppi di analisi e di consumatori.

Al termine del rollback, il vecchio nodo master non sarà più necessario. A questo punto puoi dismettere il nodo master precedente.

Prima di iniziare

Prima di eseguire il rollback di Postgres 18 alla versione 17/14, esegui i seguenti passaggi sia sul nuovo host di standby sia sul vecchio host di standby per aggiornare la proprietà max_locks_per_transaction su apigee-postgresql:

Se non è presente, crea il file /opt/apigee/customer/application/postgresql.properties.

Modifica la proprietà di questo file in apigee:

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

Aggiungi la seguente proprietà al file:

conf/postgresql.conf+max_locks_per_transaction=30000

Configura apigee-postgresql:

apigee-service apigee-postgresql configure

Riavvia apigee-postgresql:

apigee-service apigee-postgresql restart

Procedura di rollback dettagliata

Assicurati che il nuovo nodo Postgres in standby sia in esecuzione:
```
/opt/apigee/apigee-service/bin/apigee-all status
```
Se Postgres non è in esecuzione, avvialo:
```
/opt/apigee/apigee-service/bin/apigee-all start
```

Assicurati che Postgres sia arrestato sul vecchio nodo master e sul vecchio nodo di standby:

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

Se Postgres è in esecuzione, arrestalo:

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

Se è installato, avvia Qpid sul vecchio nodo di standby:
```
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server start
```
Nota: in molte configurazioni, il vecchio nodo in standby ospiterà solo Postgres, ma non Qpid.
Promuovi il nuovo nodo in standby come master Postgres:
1. Promuovi il nuovo nodo standby in modo che diventi il nuovo master:
```
apigee-service apigee-postgresql promote-standby-to-master old_master_IP
```
  Se richiesto, inserisci la password Postgres per l'utente "apigee", che per impostazione predefinita è "postgres".
2. Modifica il file di configurazione che hai utilizzato per installare la versione attuale di Edge per specificare quanto segue:
```
# IP address of the new master:
PG_MASTER=new_standby_IP
# IP address of the old standby node
PG_STANDBY=old_standby_IP
```
3. Configura il nuovo master:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-master -f configFile
```
Se hai già eseguito l'upgrade del vecchio nodo in standby alla versione più recente, devi prima eseguire il downgrade del software Apigee sul vecchio nodo in standby. Se hai ancora la versione precedente sul vecchio nodo di standby, puoi saltare questo passaggio e continuare con il passaggio 6.
1. Arresta Postgres sul nodo standby precedente:
```
apigee-service apigee-postgresql stop
apigee-service edge-postgres-server stop
```
2. Disinstalla Postgres dal vecchio nodo di standby:
```
apigee-service apigee-postgresql uninstall
apigee-service edge-postgres-server uninstall
apigee-service edge-analytics uninstall
```
3. Elimina la directory dei dati Postgres dal vecchio nodo di standby:
```
cd /opt/apigee/data/apigee-postgresql/pgdata
rm -rf *
```
4. Scarica ed esegui il bootstrap della versione precedente (per la versione di Apigee a cui stai eseguendo il rollback) sul vecchio nodo di standby. I passaggi esatti possono variare a seconda che tu stia utilizzando l'installazione basata su internet o offline. L'esecuzione del bootstrap di Apigee della versione precedente configurerà i repository yum con i dati di Apigee della versione precedente.
5. Configura i componenti Postgres sul vecchio nodo di standby:
```
/opt/apigee/apigee-setup/bin/setup.sh -p ps -f configFile
```
6. Controlla e verifica che sia stato eseguito il rollback dei componenti Postgres sul vecchio nodo in standby alla versione precedente:
```
apigee-service apigee-postgresql version
apigee-service edge-postgres-server version
```

Nota: assicurati di rimuovere l'RPM postgresql18-libs-18.3-1PGDG se esiste ancora.

Ricostruisci il vecchio nodo di standby:
1. Modifica il file di configurazione che hai utilizzato per installare la versione attuale di Edge per specificare quanto segue:
```
# IP address of the new master:
PG_MASTER=new_standby_IP
# IP address of the old standby node
PG_STANDBY=old_standby_IP
```
2. Rimuovi la directory dei dati sul vecchio nodo di standby:
```
cd /opt/apigee/data/apigee-postgresql/pgdata
rm -rf *
```
3. Riconfigura il vecchio nodo di standby in modo che diventi un nodo di standby del nuovo master:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-standby -f configFile
```
4. Assicurati che Postgres sia in esecuzione sul vecchio nodo di standby:
```
/opt/apigee/apigee-service/bin/apigee-all status
```
  Se Postgres non è in esecuzione, avvialo:
```
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server start
```
Verifica che il nuovo nodo di standby sia stato aggiunto visualizzando il file /opt/apigee/apigee-postgresql/conf/pg_hba.conf sul nuovo master.

Visualizza le informazioni correnti su Analytics e sul gruppo di consumatori eseguendo questo comando sul server di gestione:

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

Questo comando restituisce il nome del gruppo di analisi nel campo name e il nome del gruppo di consumer nel campo name in consumer-groups. Restituisce anche gli UUID dei vecchi nodi master e standby di Postgres nel campo postgres-server e nel campo datastores. Dovresti vedere un output nel formato:

{
  "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" : {
  }
}

Recupera l'indirizzo UUID del vecchio master eseguendo il seguente comando curl sul vecchio nodo master:
```
curl -u sysAdminEmail:password http://node_IP:8084/v1/servers/self
```
Dovresti vedere l'UUID del nodo alla fine dell'output, nel formato:
```
"type" : [ "postgres-server" ],
"uUID" : "599e8ebf-5d69-4ae4-aa71-154970a8ec75"
```
Nota: il servizio edge-postgres-server deve essere in esecuzione. Se il server Postgres non è in esecuzione, puoi eseguire questo comando sul server di gestione per determinare l'UUID:
```
curl -u sysAdminEmail:password http://ms_IP:8080/v1/servers?pod=analytics
```
L'output di questo comando elenca l'UUID per l'indirizzo IP di ogni nodo PostgreSQL.
Ripeti il passaggio precedente per ottenere gli indirizzi IP del vecchio nodo di standby e del nuovo master.
Rimuovi i vecchi nodi master e standby dal gruppo di consumer:
```
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
```
Dove axgroup-001 e consumer-group-001 sono i nomi predefiniti dei gruppi di analisi e consumer. masterUUID,standbyUUID sono nello stesso ordine in cui sono apparsi sopra quando hai visualizzato le informazioni attuali su analisi e gruppi di consumatori. Potresti doverli specificare come standbyUUID,masterUUID.

La proprietà datastores per consumer-groups ora dovrebbe essere vuota.

Rimuovi i vecchi nodi master e standby dal gruppo di analisi:

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 proprietà postgres-server in uuids ora dovrebbe essere vuota.

Registra i nuovi nodi master e standby di PG con i gruppi di analisi e 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

Convalida il gruppo di analisi:
```
curl -u sysAdminEmail:password http://ms_IP:8080/v1/analytics/groups/ax
```
Dovresti vedere gli UUID dei nuovi nodi master e standby elencati nel gruppo di analisi e nel gruppo di consumer.

Riavvia l'Edge Management Server:

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

Riavvia tutti i server Qpid:

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

Riavvia tutti i server Postgres:

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

Verifica lo stato della replica eseguendo i seguenti script su entrambi i server. Il sistema deve mostrare risultati identici su entrambi i server per garantire una replica riuscita:
Sul nuovo master, esegui:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-master
```
Verifica che sia il master. Sul vecchio nodo standby, esegui:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-standby
```
Verifica che sia in standby.
Ripeti il passaggio precedente dopo aver effettuato diverse richieste API per assicurarti che i nodi siano sincronizzati.
Dismettere il vecchio master Postgres:
Nota: se il vecchio nodo master eseguiva Qpid, puoi lasciare il server attivo per eseguire Qpid. Assicurati che sia in esecuzione. In caso contrario, avvialo:
```
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server start
/opt/apigee/apigee-service/bin/apigee-service apigee-qpidd start
```
In alternativa, puoi disinstallare Qpid dal vecchio master e installare Qpid sul nuovo nodo master. Dopo aver disinstallato Qpid, puoi dismettere il vecchio nodo master.

Esegui il rollback della nuova UI di Edge

Apigee Edge for Private Cloud 4.54.00 sostituisce la UI classica (edge-ui) con la nuova UI Edge (edge-management-ui). Poiché il componente UI cambia nella versione 4.54.00, il rollback alla versione 4.53.00 o 4.53.01 richiede la disinstallazione di edge-management-ui e la reinstallazione del profilo UI precedente:

UI classica (edge-ui): reinstalla il profilo ui.
Nuova UI Edge (edge-ui e edge-management-ui): reinstalla i profili ui e ue nei rispettivi nodi.

Per eseguire il rollback della UI su un nodo:

Interrompi e disinstalla la nuova UI di Edge 4.54.00 e installa la versione precedente per eseguire il rollback:

Arresta e disinstalla la nuova 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

Esegui il file di bootstrap per Apigee 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

Esegui il rollback di apigee-setup dalla versione 4.54.00 alla versione precedente:

# 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

Ripristina le configurazioni dell'interfaccia utente 4.53.00/4.53.01:
- Se hai eseguito il backup del file di configurazione silenziosa dall'installazione 4.53.00 o 4.53.01, utilizza il file di backup per la procedura di rollback. In caso contrario, nel file di configurazione automatica 4.54.00, ripristina o rimuovi il commento dalle proprietà dell'interfaccia utente 4.53.00 o 4.53.01 che sono state rimosse o commentate durante l'upgrade. Per riferimento, consulta la sezione Aggiornamento della UI.
- Se /opt/apigee/customer/application/ui.properties è stato eliminato durante l'upgrade, ripristinalo dalla directory di backup:
```
cp -rf /opt/apigee/backup/ui/customer/application/ui.properties /opt/apigee/customer/application/
chown apigee:apigee /opt/apigee/customer/application/ui.properties
```
Reinstalla e configura la versione precedente della UI:
- Esegui il rollback alla UI classica (edge-ui):
  1. Installa e configura l'interfaccia utente classica (per l'autenticazione di base non sono necessari ulteriori passaggi):
```
/opt/apigee/apigee-setup/bin/setup.sh -p ui -f configFile
```
  2. Se il servizio SSO è abilitato, configuralo nell'interfaccia utente classica (assicurati che apigee-sso sia in esecuzione):
```
/opt/apigee/apigee-service/bin/apigee-service edge-ui configure-sso -f configFile
```
- Esegui il rollback alla nuova UI Edge 4.53.00 o 4.53.01 (edge-management-ui e Shoehorn edge-ui):
  1. Assicurati che EDGEUI_ENABLE_UNIFIED_UI=y sia impostato nel file di configurazione silenziosa, quindi installa e configura i profili ui e ue:
```
/opt/apigee/apigee-setup/bin/setup.sh -p ui -f configFile
/opt/apigee/apigee-setup/bin/setup.sh -p ue -f configFile
```
  2. Se l'SSO è abilitato, configura l'SSO su entrambi i componenti della UI (assicurati che apigee-sso sia in esecuzione):
```
/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
```
Nota: in una topologia multi-nodo in cui la UI classica e la nuova UI Edge 4.53.01 erano ospitate su nodi separati, esegui i comandi di rollback sui rispettivi host. Il comando configure-sso deve essere eseguito solo se il servizio SSO è stato configurato nella versione precedente.
- Nodo 1 (nodo UI classica): esegui i comandi della UI classica:
```
/opt/apigee/apigee-setup/bin/setup.sh -p ui -f configFile
/opt/apigee/apigee-service/bin/apigee-service edge-ui configure-sso -f configFile
```
- Nodo 2 (nuovo nodo UI Edge): esegui i comandi della nuova UI Edge (setup.sh -p ue e 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
```

Verifica lo stato e la versione della UI di cui è stato eseguito il rollback:

Per la UI classica (edge-ui):

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

Per la nuova 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

Nota:nelle versioni di Apigee Edge for Private Cloud precedenti alla 4.54.00, la UI di gestione di Edge classica (edge-ui) e la nuova UI di gestione di Edge (edge-management-ui) non potevano coesistere sullo stesso nodo. Gli amministratori dovevano eseguire il provisioning di nodi separati e dedicati per ogni componente dell'interfaccia utente durante l'esecuzione di queste versioni precedenti.

Esegui il rollback di OpenLDAP

Questa sezione fornisce una guida passo passo per eseguire il rollback di Symas OpenLDAP 2.6.10 in Edge for Private Cloud 4.54.00 a OpenLDAP 2.4.46 (Edge for Private Cloud 4.53.00) o Symas OpenLDAP 2.6.7 (Edge for Private Cloud 4.53.01). Devi eseguire il rollback sull'intero cluster LDAP utilizzando un backup LDAP pre-upgrade valido.

L'obiettivo principale è ripristinare l'intero cluster LDAP a uno stato coerente da un backup valido noto. Questa procedura è uguale per tutti gli scenari: server singolo, attivo/attivo e attivo/passivo.

Prima di iniziare

Incompatibilità del backup: utilizza un backup pre-upgrade di OpenLDAP 2.4.46 (Edge for Private Cloud 4.53.00) o Symas OpenLDAP 2.6.7 (Edge for Private Cloud 4.53.01) eseguito utilizzando apigee-service apigee-openldap backup prima del tentativo di upgrade. I backup eseguiti dopo l'upgrade non sono compatibili e non possono essere utilizzati.
Tempo di inattività dell'API di gestione: durante il rollback di LDAP, le API di gestione non saranno disponibili, il che potrebbe influire sulle attività amministrative. Arresta tutte le istanze edge-management-server e edge-ui prima di procedere con il rollback LDAP.
Nota:se utilizzi la nuova UI di Edge (edge-management-ui), assicurati di arrestare sia la UI classica (edge-ui) sia la nuova UI di Edge (edge-management-ui).
Rischio di perdita di dati: se procedi senza un backup valido e compatibile, rischi di perdere i dati in modo irreversibile.
Backup valido:è necessario un backup LDAP valido precedente all'upgrade.
Backup dei file silent.conf:conserva i backup dei file silent.conf delle versioni precedente e corrente per evitare confusione nella configurazione durante le procedure di upgrade e rollback.
Sequenza di rollback: completa le procedure di rollback per Cassandra, ZooKeeper, Qpid, PostgreSQL, apigee-sso e l'interfaccia utente Edge prima di eseguire il rollback di OpenLDAP.

Procedura di rollback

Arresta il server di gestione e la UI:arresta tutte le istanze edge-management-server e edge-ui prima di procedere con il rollback LDAP:
```
apigee-service edge-management-server stop
apigee-service edge-ui stop
```
Registra il numero attuale di entry LDAP (prima di arrestare LDAP): ottieni il numero totale di record di riferimento da tutti i server LDAP, sostituendo YOUR_PASSWORD con la password attuale del gestore LDAP. Il numero di record deve corrispondere su tutti i server 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
```
Arresta e disinstalla il nuovo LDAP 2.6: arresta il servizio apigee-openldap ed elimina le directory di configurazione e dati. Esegui questo passaggio su tutti i server LDAP, un nodo alla volta nel cluster, per garantire la coerenza:
```
apigee-service apigee-openldap stop
apigee-service apigee-openldap uninstall
rm -rf /opt/apigee/data/apigee-openldap/*
```

Installa la versione LDAP precedente 2.4.46 o 2.6.7:

Installa la versione precedente di LDAP:

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

Convalida la versione 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

Ripeti i passaggi secondari precedenti nel passaggio 4 su ogni nodo LDAP, uno alla volta.

Pulisci i dati residui: su tutti i server LDAP, uno alla volta, interrompi il servizio appena installato e pulisci la relativa directory di dati per prepararti al ripristino dal backup:
```
apigee-service apigee-openldap stop
rm -rf /opt/apigee/data/apigee-openldap/*
```
Ripristina i dati LDAP:per una configurazione a server singolo, vai direttamente al passaggio 6b. Per una configurazione multi-server, procedi con il passaggio 6a.
1. Identifica il server LDAP attivo:prima di ripristinare i dati LDAP, identifica il server attivo (provider) eseguendo questo comando:
```
grep -i '^olcSyncrepl:' /opt/apigee/data/apigee-openldap/slapd.d/cn=config/olcDatabase*.ldif
```
  Nota:
  1. Se questo comando restituisce un output, il server è un server passivo.
  2. Se questo comando non restituisce alcun output, il server è il server attivo.
2. Ripristina i dati LDAP (assicurati che il passaggio 5 sia completato su tutti i server prima del ripristino):
  - Sul server LDAP singolo o attivo (determinato nel passaggio 6a), vai alla directory di backup e ripristina il backup precedente all'upgrade (ad esempio, 2025.07.28,13.59.00 o ometti il timestamp se il backup precedente all'upgrade è il backup più recente nella directory):
```
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.
```
  - Avvia il servizio apigee-openldap:
```
apigee-service apigee-openldap start
```
Avvia i server LDAP rimanenti:se hai una configurazione con più server, avvia il servizio su ciascuno dei server LDAP rimanenti:
```
apigee-service apigee-openldap start
```
Nota: non è necessario ripristinare manualmente i dati su questi server peer. All'avvio, si connetteranno al primo server (che ora contiene i dati ripristinati) e sincronizzeranno automaticamente l'intera directory tramite la replica.
Convalida finale:
- Verifica che il rollback sia riuscito e che i dati siano coerenti in tutto il cluster LDAP.
- Esegui il comando di convalida su tutti i server LDAP, sostituendo YOUR_PASSWORD con la password attuale del gestore LDAP. Il conteggio dei record deve essere identico su tutti i server e deve corrispondere al conteggio acquisito nel passaggio 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
```
- Dopo aver verificato che i dati siano corretti e coerenti, avvia edge-management-server, edge-ui e tutti gli altri componenti dipendenti in base alla procedura standard della tua organizzazione.

Esegui il rollback dei componenti Edge

Componenti con codice comune

I seguenti componenti Edge condividono un codice comune. Pertanto, per eseguire il rollback di uno qualsiasi di questi componenti su un nodo, devi eseguire il rollback di tutti questi componenti presenti sul nodo:

edge-management-server (server di gestione)
edge-message-processor (Processore di messaggi)
edge-router (Router)
edge-postgres-server (server Postgres)
edge-qpid-server (server Qpid)

Ad esempio, se sul nodo sono installati il server di gestione, il router e il processore di messaggi, per eseguire il rollback di uno di questi devi eseguire il rollback di tutti e tre.

Per eseguire il rollback a una release principale o secondaria precedente, segui questi passaggi su ogni nodo che ospita il componente:

Scarica il file bootstrap.sh per la versione a cui vuoi eseguire il rollback:
- Per eseguire il rollback alla versione 4.53.00/4.53.01, scarica bootstrap_4.53.00.sh/bootstrap_4.53.01.sh

Arresta il componente di cui eseguire il rollback:

Per eseguire il rollback di uno dei componenti con codice comune sul nodo, devi arrestarli tutti, come mostrato nell'esempio seguente:

/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

Per eseguire il rollback di qualsiasi altro componente sul nodo, arresta solo quel componente:
```
/opt/apigee/apigee-service/bin/apigee-service component stop
```

Se esegui il rollback della monetizzazione, disinstallala da tutti i nodi del server di gestione e del processore di messaggi:
```
/opt/apigee/apigee-service/bin/apigee-service edge-mint-gateway uninstall
```
Disinstalla il componente per eseguire il rollback sul nodo:
1. Per eseguire il rollback di uno dei componenti con codice comune sul nodo, devi disinstallarli tutti disinstallando il gruppo di componenti edge-gateway e apigee-cassandra-client, come mostrato nell'esempio seguente:
```
/opt/apigee/apigee-service/bin/apigee-service edge-gateway uninstall
```
```
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra-client uninstall
```
2. Per eseguire il rollback di 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. Per eseguire il rollback di qualsiasi altro componente sul nodo, disinstalla solo quel componente, come mostrato nell'esempio seguente:
```
/opt/apigee/apigee-service/bin/apigee-service component uninstall
```
  Dove component è il nome del componente.
  Nota: se edge-analytics non viene disinstallato automaticamente insieme a edge-qpid-server e edge-postgres-server, disinstallalo manualmente utilizzando il seguente comando:
```
/opt/apigee/apigee-service/bin/apigee-service edge-analytics uninstall
```
4. Per eseguire il rollback del router perimetrale, devi eliminare i contenuti del file /opt/nginx/conf.d, oltre a disinstallare il gruppo di componenti edge-gateway:
```
cd /opt/nginx/conf.d
rm -rf *
```

Disinstalla la versione 4.54.00 di apigee-setup:

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

Installa la versione 4.53.00 dell'utilità apigee-service e delle relative dipendenze. Nell'esempio riportato di seguito viene installata la versione 4.53.00 di apigee-service:
```
sudo bash /tmp/bootstrap_4.53.00.sh apigeeuser=uName apigeepassword=pWord
```
Dove uName e pWord sono il nome utente e la password che hai ricevuto da Apigee. Se ometti pWord, ti verrà chiesto di inserirlo.

Se ricevi un errore, assicurati di aver scaricato il file bootstrap.sh nel passaggio 1.

Installa apigee-setup:

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

Installa la versione precedente del componente:
```
/opt/apigee/apigee-setup/bin/setup.sh -p component -f configFile
```
Dove component è il componente da installare e configFile è il file di configurazione per la versione precedente.
Se esegui il rollback di Qpid, svuota iptables:
```
sudo iptables -F
```
Ripeti questa procedura per ogni nodo che ospita il componente di cui esegui il rollback.

Nota:dopo la disinstallazione di apigee-cassandra-client, apigee-provision e apigee-validate vengono rimossi automaticamente a causa della loro dipendenza. Se sono necessari in un secondo momento, devono essere reinstallati.

Esegui il rollback di mTLS

Per eseguire il rollback dell'aggiornamento mTLS, segui questi passaggi su tutti gli host:

Arresta Apigee:
```
apigee-all stop
```
Interrompi mTLS:
```
apigee-service apigee-mtls uninstall
```

Reinstalla mTLS:

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