Ripristino della versione precedente di Apigee Edge 4.53.00

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

Puoi eseguire il rollback di Edge 4.53.00 alla seguente versione secondaria:

  • Versione 4.52.02

Il rollback di una versione comporta il rollback di ogni componente che potresti aver aggiornato. Inoltre, devi tenere in considerazione alcune considerazioni speciali quando esegui il rollback di Cassandra alla versione 4.52.02.

Esistono due scenari in cui potresti voler eseguire un rollback:

  1. Esegui il rollback a una release principale o secondaria precedente. Ad esempio, da 4.53.00 a 4.52.02.
  2. Esegui il rollback a una release di patch precedente nella stessa release. Ad esempio, da 4.53.00.01 a 4.53.00.00.

Per maggiori informazioni, consulta la sezione Procedura di rilascio di Apigee Edge.

Ordine di rollback

Il rollback dei componenti deve essere eseguito nell'ordine inverso rispetto all'upgrade, ad eccezione dei server di gestione, per i quali il rollback deve essere eseguito dopo Cassandra.

Un tipico ordine generale di rollback per Private Cloud 4.53.00 sarà simile al seguente:

  1. Eseguire il rollback di Postgres, Qpid e altri componenti correlati all'analisi
  2. Eseguire il rollback di router e processori di messaggi
  3. Rollback di Cassandra, Zookeeper
  4. Esegui il rollback del server di gestione

Ad esempio, supponiamo di aver eseguito l'upgrade dell'intero cluster Cassandra, di tutti i server di gestione e di alcuni RMP alla versione 4.53.00 dalla versione 4.52.02 e di voler eseguire il rollback. In questo caso, dovresti:

  1. Esegui il rollback di tutti gli RMP uno alla volta
  2. Eseguire il rollback dell'intero cluster Cassandra utilizzando i backup
  3. Esegui il rollback dei nodi del server Edge Management uno alla volta

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 privilegiate, come quelle inferiori a 1000, devi eseguirlo come 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.

Componenti con codice comune

I seguenti componenti di 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 i 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 (Qpid Server)

Ad esempio, se hai installato Management Server, Router e Message Processor sul nodo, per eseguire il rollback di uno di questi tre componenti devi eseguire il rollback di tutti e tre.

Rollback di Cassandra

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 sul posto non è fattibile.

Scenari di rollback

Cassandra 4.0.X, disponibile con Edge for Private Cloud 4.53.00, è compatibile con altri componenti di Private Cloud 4.52.02.

Consulta la tabella seguente per un riepilogo delle varie strategie di rollback che puoi utilizzare:

Scenario Strategia di rollback
Singolo DC, alcuni nodi Cassandra di cui è stato eseguito l'upgrade Utilizzare i backup
Singolo DC, tutti i nodi Cassandra aggiornati Non eseguire il rollback di Cassandra. È possibile eseguire il rollback di altri componenti.
Singolo DC, tutti i nodi (Cassandra e altri) aggiornati Non eseguire il rollback di Cassandra. È possibile eseguire il rollback di altri componenti.
Più DC, alcuni nodi in una DC di cui è stato eseguito l'upgrade Ricostruire a partire da una CD esistente
Più data center, tutti i nodi Cassandra in alcuni data center sono stati aggiornati Ricostruire a partire da una CD esistente
Più nodi Cassandra DC, DC di cui è in corso l'upgrade Prova a completare l'upgrade. Se non è fattibile, esegui il rollback di un controller di dominio utilizzando il backup. Ricostruisci le CD rimanenti dalla CD di cui è stato eseguito il rollback.
Più data center, tutti i nodi Cassandra aggiornati Non eseguire il rollback di Cassandra. È possibile eseguire il rollback di altri componenti.
Più data center, tutti i nodi (Cassandra e altri) sono stati aggiornati Non eseguire il rollback di Cassandra. È possibile eseguire il rollback di altri componenti.

Considerazioni generali

Quando valuti un rollback, tieni presente quanto segue:

  • Rollback dei componenti di runtime o di gestione:se vuoi eseguire il rollback di componenti come edge-management-server, edge-message-processor o qualsiasi componente non Cassandra alla versione 4.52.02 di Private Cloud, ti consigliamo di NON eseguire il rollback di Cassandra. Cassandra fornito con Private Cloud 4.53.00 è compatibile con tutti i componenti non Cassandra di Edge per Private Cloud 4.52.02. Puoi eseguire il rollback dei componenti non Cassandra utilizzando la metodologia elencata qui, mentre Cassandra rimane alla versione 4.0.13.
  • Rollback dopo l'upgrade dell'intero cluster Cassandra alla versione 4.0.X: se l'intero cluster Cassandra viene aggiornato alla versione 4.0.X nell'ambito dell'upgrade a Private Cloud versione 4.53.00, ti consigliamo di continuare con la configurazione del cluster e di NON eseguire il rollback di Cassandra. Componenti come edge-management-server, edge-message-processor, edge-router e così via della versione 4.52.02 di Private Cloud sono compatibili con Cassandra versione 4.0.X.
  • Rollback di Cassandra durante l'upgrade di Cassandra:se riscontri problemi durante l'upgrade di Cassandra, potresti prendere in considerazione un rollback. Le strategie di rollback elencate in questo articolo possono essere seguite in base allo stato in cui ti trovi durante la procedura di upgrade.
  • Rollback utilizzando i backup:i backup eseguiti da Cassandra 4.0.X non sono compatibili con i backup di Cassandra 3.11.X. Per eseguire il rollback di Cassandra utilizzando il ripristino del backup, devi eseguire i backup di Cassandra 3.11.X prima di tentare l'upgrade.

Eseguire il rollback di Cassandra utilizzando la ricompilazione

Prerequisiti

  • Stai gestendo un cluster Edge for Private Cloud 4.52.02 in più data center.
  • Stai eseguendo l'upgrade di Cassandra dalla versione 3.11.X alla 4.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 3.11.X).

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

Passaggi di alto livello

  1. Seleziona un data center (aggiornato parzialmente o completamente) di cui vuoi eseguire il rollback. Devia il traffico di runtime verso un altro data center funzionante.
  2. Identifica il nodo seed nel data center e inizia con uno dei nodi seed.
  3. Arresta, disinstalla e pulisci il nodo Cassandra.
  4. Installa la versione precedente di Cassandra sul nodo e configurala in base alle esigenze.
  5. Rimuovi le configurazioni aggiuntive aggiunte in precedenza.
  6. Ripeti i passaggi precedenti per tutti i nodi seed nel data center, uno alla volta.
  7. Ripeti i passaggi precedenti per tutti i nodi Cassandra rimanenti nel data center, uno alla volta.
  8. Ricostruisci i nodi dal data center funzionale esistente, uno alla volta.
  9. Riavvia tutti i componenti edge-* nel data center connessi a Cassandra.
  10. Testa e reindirizza il traffico a questo data center.
  11. Ripeti i passaggi per ogni data center, uno alla volta.

Procedura dettagliata

  1. Scegli un data center in cui vengono eseguiti l'upgrade di tutti o di alcuni nodi Cassandra. Devia tutto il traffico 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 il problema 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 a due data center in cui tutti i nodi DC-1 utilizzano Cassandra versione 4, mentre tutti i nodi DC-2 utilizzano 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:
    4.0.13: [DC-1-IP1:7000, DC-1-IP2:7000, DC-1-IP3:7000]
    3.11.16: [DC-2-IP1:7000, DC-2-IP2:7000, DC-2-IP3:7000]

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

# On nodes where Cassandra is not upgraded
/opt/apigee/apigee-cassandra/bin/nodetool describecluster
Cluster Information:
    Name: Apigee
    Snitch: org.apache.cassandra.locator.PropertyFileSnitch
    DynamicEndPointSnitch: enabled
    Partitioner: org.apache.cassandra.dht.RandomPartitioner
    Schema versions:
        2eadcd74-0245-309a-9992-3625afa70038: [DC-1-IP1, DC-1-IP2, DC-1-IP3]
        129dc15e-198e-3c11-b64c-701044a3a1ad: [DC-2-IP1, DC-2-IP2, DC-2-IP3]
  2. 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:
  3. Interrompi, disinstalla e pulisci i dati dal nodo di Cassandra. Scegli il primo nodo seed nella versione 4 di Cassandra 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
  4. Installa il software Cassandra precedente sul nodo e imposta alcune configurazioni. Esegui il file di bootstrap di Edge for Private Cloud 4.52.02. 
    5. # Download bootstrap of 4.52.02
curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh -u uName:pWord

# Execute bootstrap of 4.52.02
sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord
  5. Crea o modifica il file /opt/apigee/customer/application/cassandra.properties.
  6. 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
  7. Assicurati che il file sia di proprietà dell'utente Apigee e che possa essere letto: 
    chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
  8. Installa e configura Cassandra: 
    # Install cassandra version 3.11.X
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra install

# Setup cassandra while passing standard configuration file
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra setup -f configFile
# Ensure Cassandra version is correct and service is running
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra version
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra status
  9. Verifica che il nodo sia stato avviato. Controlla il seguente comando su questo nodo e sugli altri nodi del cluster. Il nodo deve segnalare lo stato "UN" (Up/Normal): 
    /opt/apigee/apigee-cassandra/bin/nodetool status
  10. Rimuovi le configurazioni aggiuntive aggiunte in precedenza dal file /opt/apigee/customer/application/cassandra.properties.
  11. Ripeti i passaggi da 3 a 10 su tutti i nodi seed Cassandra nel data center, uno alla volta.
  12. Ripeti i passaggi da 3 a 10 su tutti i nodi Cassandra rimanenti nel data center, uno alla volta.
  13. 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.

  14. (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
  15. 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
  16. Convalida e reindirizza il traffico a 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 delle API di gestione.
  17. Ripeti i passaggi precedenti per ogni data center di cui vuoi eseguire il rollback.

Eseguire il rollback di Cassandra utilizzando il backup

Prerequisiti

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

Passaggi

  1. 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 con i nodi seed. Consulta la sezione "Come identificare i nodi seed" nell'appendice.

  2. 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

  3. Installa il software Cassandra precedente sul nodo e configuralo:

    • Esegui il file di bootstrap per Edge for Private Cloud 4.52.02:
      • # Download bootstrap for 4.52.02
curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh -u ‘uName:pWord’

# Execute bootstrap for 4.52.02
sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord
    • 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 sia leggibile:
      • chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
    • Installa e configura Cassandra:
      • # Install Cassandra version 3.11.X
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra install

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

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

    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

  4. Arresta il servizio Cassandra e ripristina il backup. Per ulteriori dettagli, consulta la documentazione su 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

  5. Una volta ripristinato il backup, rimuovi le configurazioni aggiuntive:

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

  6. Avvia il servizio Cassandra sul nodo:

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

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

  8. 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 del backup (opzione avanzata)

Puoi ridurre al minimo (o eliminare) la perdita di dati durante il ripristino dei backup se sono disponibili repliche che contengono i dati più recenti. 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

Eseguire il rollback a una release principale o secondaria precedente

Per eseguire il rollback a una release principale o secondaria precedente, esegui le seguenti operazioni su ogni nodo che ospita il componente:

  1. Scarica il file bootstrap.sh per la versione a cui vuoi eseguire il rollback:

    • Per eseguire il rollback alla versione 4.52.02, scarica bootstrap_4.52.02.sh: 
      curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh
  2. Arresta il componente per eseguire il rollback:
    1. 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
    2. Per eseguire il rollback di qualsiasi altro componente sul nodo, arresta solo quel componente: 
      /opt/apigee/apigee-service/bin/apigee-service component stop
  3. 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
  4. 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, come mostrato nell'esempio seguente: 
      /opt/apigee/apigee-service/bin/apigee-service edge-gateway uninstall
    2. Per eseguire il rollback di Nginx come indicato di seguito: 
      ###Find the apigee-nginx RPM 
rpm -qa | grep -i "apigee-nginx"

###Remove the apigee-nginx RPM
dnf remove apigee-nginx-1.26.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.

    4. Per eseguire il rollback dell'Edge Router, 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 *
  5. Disinstalla la versione 4.53.00 di apigee-setup: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-setup uninstall
  6. Installa la versione 4.52.02 dell'utilità apigee-service e le relative dipendenze. L'esempio seguente installa la versione 4.52.02 di apigee-service: 
    sudo bash /tmp/bootstrap_4.52.02.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.

  7. Installa apigee-setup: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-setup install
  8. 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 tuo file di configurazione per la versione precedente.

  9. Se esegui il rollback di Qpid, svuota iptables: 
    sudo iptables -F
  10. Ripeti questa procedura per ogni nodo che ospita il componente di cui stai eseguendo il rollback.

Eseguire il rollback a una release di patch precedente

Per eseguire il rollback di un componente a una specifica patch release, procedi nel seguente modo su ogni nodo che ospita il componente:

  1. Scarica la versione specifica del componente: 
    /opt/apigee/apigee-service/bin/apigee-service component_version install

    Dove component_version è il componente e la patch da installare. Ad esempio:

    /opt/apigee/apigee-service/bin/apigee-service edge-ui-4.53.00-0.0.20254 install

    Se utilizzi il repository online di Apigee, puoi determinare le versioni dei componenti disponibili utilizzando il seguente comando: 

    yum --showduplicates list comp

    Ad esempio:

    yum --showduplicates list edge-ui
  2. Utilizza apigee-setup per installare il componente: 
    /opt/apigee/apigee-setup/bin/setup.sh -p comp -f configFile

    Ad esempio:

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

    Tieni presente che quando installi un componente, devi specificare solo il nome, non la versione.

  3. Ripeti questa procedura per ogni nodo che ospita il componente di cui stai eseguendo il rollback.

Esegui il rollback di mTLS

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

  1. Arresta Apigee: 
    apigee-all stop
  2. Interrompi mTLS: 
    apigee-service apigee-mtls uninstall
  3. Reinstalla mTLS: 
    apigee-service apigee-mtls install
apigee-service apigee-mtls setup -f /opt/silent.conf