Rollback von Apigee Edge 4.53.01

Wenn bei einem Update auf Edge 4.53.01 ein Fehler auftritt, können Sie die Komponente, die den Fehler verursacht hat, zurücksetzen und das Update dann noch einmal versuchen.

Sie können Edge 4.53.01 auf eine der folgenden Hauptversionen zurücksetzen:

  • Version 4.53.00
  • Version 4.52.02

Beim Rollback einer Version wird jede Komponente zurückgesetzt, die Sie möglicherweise aktualisiert haben. Außerdem müssen Sie je nach Ausgangsversion möglicherweise spezielle Schritte ausführen, bevor Sie bestimmte Softwarekomponenten zurücksetzen. In der folgenden Tabelle sind die verschiedenen Softwarekomponenten aufgeführt, für die beim Rollback möglicherweise spezielle Schritte erforderlich sind:

Rollback zu Version Besondere Überlegungen für Software
4.53.00 Zookeeper, Postgres, LDAP
4.52.02 Zookeeper, Cassandra, Postgres, LDAP

Hier ist ein Szenario, in dem Sie möglicherweise ein Rollback durchführen möchten:

Rollback zu einem vorherigen Haupt- oder Nebenrelease durchführen Zum Beispiel von 4.53.01 auf 4.53.00.

Weitere Informationen finden Sie unter Apigee Edge-Releaseprozess.

Reihenfolge des Rollbacks

Das Rollback von Komponenten sollte in der umgekehrten Reihenfolge erfolgen, in der sie aktualisiert wurden. Eine Ausnahme bilden Verwaltungsserver, die nach Cassandra zurückgesetzt werden sollten. Eine typische allgemeine Reihenfolge für das Rollback für Private Cloud 4.53.01 sieht so aus:

  1. Machen Sie die Änderungen an Qpid, anderen Analysekomponenten und Postgres rückgängig.
  2. Router und Nachrichtenprozessoren zurücksetzen
  3. Cassandra und Zookeeper zurücksetzen
  4. Rollback des Verwaltungsservers durchführen
  5. LDAP-Rollback

Angenommen, Sie haben den gesamten Cassandra-Cluster, alle Verwaltungsserver und einige RMPs von Version 4.52.02 auf Version 4.53.01 aktualisiert und möchten ein Rollback durchführen. In diesem Fall gehen Sie so vor:

  • Alle RMPs einzeln zurücksetzen
  • Gesamten Cassandra-Cluster mithilfe von Back-ups zurücksetzen
  • Edge-Verwaltungsserverknoten einzeln zurücksetzen

Wer kann ein Rollback durchführen?

Der Nutzer, der ein Rollback durchführt, sollte derselbe Nutzer sein, der Edge ursprünglich aktualisiert hat, oder ein Nutzer, der als Root ausgeführt wird.

Standardmäßig werden Edge-Komponenten als Nutzer „apigee“ ausgeführt. In einigen Fällen werden Edge-Komponenten möglicherweise als verschiedene Nutzer ausgeführt. Wenn der Router beispielsweise auf privilegierte Ports wie Ports unter 1000 zugreifen muss, müssen Sie den Router als Root oder als Nutzer mit Zugriff auf diese Ports ausführen. Oder Sie führen eine Komponente als einen Nutzer und eine andere Komponente als einen anderen Nutzer aus.

Komponenten mit gemeinsamem Code

Die folgenden Edge-Komponenten verwenden denselben Code. Wenn Sie also eine dieser Komponenten auf einem Knoten zurücksetzen möchten, müssen Sie alle diese Komponenten auf diesem Knoten zurücksetzen.

  • edge-management-server (Verwaltungsserver)
  • edge-message-processor (Nachrichtenprozessor)
  • edge-router (Router)
  • edge-postgres-server (Postgres-Server)
  • edge-qpid-server (Qpid-Server)

Wenn Sie beispielsweise den Management Server, den Router und den Message Processor auf dem Knoten installiert haben, müssen Sie alle drei zurücksetzen, um einen von ihnen zurückzusetzen.

Cassandra-Rollback

Wenn auf einem bestimmten Knoten ein Haupt-Upgrade von Cassandra durchgeführt wird, ändert Cassandra das Schema der auf diesem Knoten gespeicherten Daten. Daher ist ein direkter In-Place-Rollback nicht möglich.

Rollback-Szenarien

Cassandra 4.0.X, das mit Edge for Private Cloud 4.53.01 verfügbar ist, ist mit anderen Komponenten von Private Cloud 4.52.02 kompatibel.

In der folgenden Tabelle finden Sie eine Zusammenfassung der verschiedenen Rollback-Strategien, die Sie verwenden können:

Szenario Rollback-Strategie
Einzelnes Rechenzentrum, einige Cassandra-Knoten wurden aktualisiert Sicherungen verwenden
Einzelnes Rechenzentrum, alle Cassandra-Knoten aktualisiert Machen Sie Cassandra nicht rückgängig. Andere Komponenten können zurückgesetzt werden.
Einzelnes Rechenzentrum, alle Knoten (Cassandra und andere) aktualisiert Machen Sie Cassandra nicht rückgängig. Andere Komponenten können zurückgesetzt werden.
Mehrere Rechenzentren, einige Knoten in einem Rechenzentrum wurden aktualisiert Aus vorhandenem DC neu erstellen
Mehrere Rechenzentren, alle Cassandra-Knoten in einigen Rechenzentren aktualisiert Aus vorhandenem DC neu erstellen
Mehrere Rechenzentren, Cassandra-Knoten des letzten Rechenzentrums werden aktualisiert Versuchen Sie, das Upgrade abzuschließen. Wenn das nicht möglich ist, führen Sie für einen DC ein Rollback mit einer Sicherung durch. Verbleibende Gerätekonfigurationen neu erstellen aus der zurückgesetzten Gerätekonfiguration.
Mehrere Rechenzentren, alle Cassandra-Knoten aktualisiert Machen Sie Cassandra nicht rückgängig. Andere Komponenten können zurückgesetzt werden.
Mehrere Rechenzentren, alle Knoten (Cassandra und andere) aktualisiert Machen Sie Cassandra nicht rückgängig. Andere Komponenten können zurückgesetzt werden.

Allgemeines

Wenn Sie ein Rollback in Betracht ziehen, beachten Sie Folgendes:

  • Rollback von Laufzeit- oder Verwaltungskomponenten:Wenn Sie Komponenten wie edge-management-server, edge-message-processor oder eine Nicht-Cassandra-Komponente auf Private Cloud-Version 4.52.02 zurücksetzen möchten, wird empfohlen, Cassandra NICHT zurückzusetzen. Die mit Private Cloud 4.53.00 ausgelieferte Cassandra-Version ist mit allen Nicht-Cassandra-Komponenten von Edge for Private Cloud 4.52.02 kompatibel. Sie können Nicht-Cassandra-Komponenten mit der hier beschriebenen Methode zurücksetzen, während Cassandra auf Version 4.0.13 bleibt.
  • Rollback nach dem Upgrade des gesamten Cassandra-Clusters auf Version 4.0.X:Wenn Ihr gesamter Cassandra-Cluster im Rahmen des Upgrades auf Private Cloud-Version 4.53.00 auf Version 4.0.X aktualisiert wird, wird empfohlen, diese Clusterkonfiguration beizubehalten und KEIN Cassandra-Rollback durchzuführen. Komponenten wie „edge-management-server“, „edge-message-processor“ und „edge-router“ der Private Cloud-Version 4.52.02 sind mit Cassandra-Version 4.0.X kompatibel.
  • Rollback von Cassandra während des Cassandra-Upgrades:Wenn beim Cassandra-Upgrade Probleme auftreten, sollten Sie einen Rollback in Betracht ziehen. Die in diesem Artikel aufgeführten Rollback-Strategien können je nach Status während des Upgrade-Prozesses befolgt werden.
  • Rollback mit Back-ups:Back-ups von Cassandra 4.0.X sind nicht mit Back-ups von Cassandra 3.11.X kompatibel. Wenn Sie ein Cassandra-Rollback mithilfe der Wiederherstellung von Sicherungen durchführen möchten, müssen Sie Sicherungen von Cassandra 3.11.X erstellen, bevor Sie das Upgrade versuchen.

Cassandra mit „rebuild“ zurücksetzen

Vorbereitung

  • Sie betreiben einen Edge for Private Cloud-Cluster 4.52.02 in mehreren Rechenzentren.
  • Sie führen ein Upgrade von Cassandra von Version 3.11.X auf Version 4.0.X durch und sind dabei auf Probleme gestoßen.
  • Sie haben mindestens ein voll funktionsfähiges Rechenzentrum im Cluster, in dem noch die ältere Version von Cassandra (Cassandra 3.11.X) ausgeführt wird.

Bei diesem Verfahren werden Daten aus einem vorhandenen Rechenzentrum gestreamt. Je nachdem, wie viele Daten in Cassandra gespeichert sind, kann dies einige Zeit dauern. Sie sollten darauf vorbereitet sein, Ihren Laufzeittraffic während des Rollbacks von diesem Rechenzentrum wegzuleiten.

Allgemeine Schritte

  1. Wählen Sie ein Rechenzentrum aus, das Sie zurücksetzen möchten (entweder teilweise oder vollständig aktualisiert). Laufzeittraffic zu einem anderen funktionierenden Rechenzentrum umleiten.
  2. Identifizieren Sie den Seed-Knoten im Rechenzentrum und beginnen Sie mit einem der Seed-Knoten.
  3. Beenden Sie den Cassandra-Knoten, deinstallieren Sie ihn und bereinigen Sie ihn.
  4. Installieren Sie die ältere Version von Cassandra auf dem Knoten und konfigurieren Sie sie nach Bedarf.
  5. Entfernen Sie die zusätzlichen Konfigurationen, die Sie zuvor hinzugefügt haben.
  6. Wiederholen Sie die oben genannten Schritte für alle Seed-Knoten im Rechenzentrum.
  7. Wiederholen Sie die oben genannten Schritte für alle verbleibenden Cassandra-Knoten im Rechenzentrum.
  8. Bauen Sie die Knoten einzeln aus dem vorhandenen funktionsfähigen Rechenzentrum neu auf.
  9. Starten Sie alle edge-*-Komponenten im Rechenzentrum neu, die mit Cassandra verbunden sind.
  10. Testen Sie und leiten Sie den Traffic zurück zu diesem Rechenzentrum.
  11. Wiederholen Sie die Schritte für jedes Rechenzentrum.

Detaillierte Schritte

  1. Wählen Sie ein Rechenzentrum aus, in dem alle oder einige Cassandra-Knoten aktualisiert werden. Leiten Sie den gesamten Laufzeit-Proxy-Traffic und Management-Traffic von diesem Rechenzentrum um, während die Cassandra-Knoten in diesem Rechenzentrum zurückgesetzt werden. Achten Sie darauf, dass sich alle Cassandra-Knoten im Status „UN“ (Up/Normal) befinden, wenn der Befehl nodetool ring auf den Knoten ausgeführt wird. Wenn bestimmte Knoten nicht verfügbar sind, beheben Sie das Problem und stellen Sie die Knoten wieder her, bevor Sie fortfahren.

    Hier ein entsprechendes Beispiel:

    /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

    Sie können nodetool describecluster auf den Knoten ausführen, um den aktuellen Status des gesamten Clusters zu ermitteln. Im folgenden Beispiel sehen Sie eine Instanz eines Clusters mit zwei Rechenzentren, in dem alle DC-1-Knoten die Cassandra-Version 4 und alle DC-2-Knoten die Cassandra-Version 3 haben:

    # 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. Seed-Knoten im Rechenzentrum identifizieren:Weitere Informationen finden Sie im Abschnitt Seed-Knoten identifizieren im Anhang. Führen Sie die folgenden Schritte auf einem der Seed-Knoten aus:
  3. Beenden Sie den Cassandra-Knoten, deinstallieren Sie ihn und bereinigen Sie die Daten. Wählen Sie den ersten Seed-Knoten in Cassandra-Version 4 in diesem Rechenzentrum aus. Hör auf. 
    # 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. Installieren Sie die ältere Cassandra-Software auf dem Knoten und legen Sie einige Konfigurationen fest. Führen Sie die Bootstrap-Datei von Edge for Private Cloud 4.52.02 aus. 
    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. Erstellen oder bearbeiten Sie die Datei /opt/apigee/customer/application/cassandra.properties.
  6. Fügen Sie der Datei den folgenden Inhalt hinzu. ipOfNode ist die IP-Adresse des Knotens, den Cassandra für die Kommunikation mit anderen Cassandra-Knoten verwendet: 
    conf_jvm_options_custom_settings=-Dcassandra.replace_address=ipOfNode -Dcassandra.allow_unsafe_replace=true
  7. Prüfen Sie, ob die Datei dem Apigee-Nutzer gehört und von ihm gelesen werden kann: 
    chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
  8. Cassandra installieren und einrichten:
    9. # 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. Prüfen Sie, ob der Knoten gestartet wurde. Führen Sie den folgenden Befehl auf diesem und anderen Knoten im Cluster aus. Der Knoten sollte den Status „UN“ (Up/Normal) haben: 
    /opt/apigee/apigee-cassandra/bin/nodetool status
  10. Entfernen Sie die zuvor hinzugefügten zusätzlichen Konfigurationen aus der Datei /opt/apigee/customer/application/cassandra.properties.
  11. Wiederholen Sie die Schritte 3 bis 10 für alle Cassandra-Seedknoten im Rechenzentrum, jeweils einzeln.
  12. Wiederholen Sie die Schritte 3 bis 10 für alle verbleibenden Cassandra-Knoten im Rechenzentrum, jeweils einzeln.
  13. Erstellen Sie alle Knoten im Rechenzentrum neu aus einem Rechenzentrum, in dem die ältere Cassandra-Version ausgeführt wird. Führen Sie diesen Schritt für jeweils einen Knoten aus: 
    /opt/apigee/apigee-cassandra/bin/nodetool rebuild -dc <name of working DC>

    Dieser Vorgang kann einige Zeit in Anspruch nehmen. Bei Bedarf können Sie streamingthroughput anpassen. Prüfen Sie nodetool netstats, um den Status des Vorgangsabschlusses zu sehen.

  14. Optional: Führen Sie den Reparatur-Befehl auf dem Cassandra-Knoten aus, wenn die Daten nicht neu erstellt werden. 
    /opt/apigee/apigee-cassandra/bin/nodetool -h node-IP repair -pr
  15. Starten Sie alle edge-*-Komponenten im Rechenzentrum nacheinander neu: 
    /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. Validieren Sie das Rechenzentrum und leiten Sie den Traffic wieder dorthin um. Führen Sie einige Validierungen für Laufzeittraffic und Management-APIs in diesem Rechenzentrum aus und leiten Sie den Proxy- und Management-API-Traffic wieder dorthin um.
  17. Wiederholen Sie die oben genannten Schritte für jedes Rechenzentrum, das Sie zurücksetzen möchten.

Cassandra mithilfe eines Back-ups zurücksetzen

Vorbereitung

  1. Sie führen ein Upgrade von Cassandra von Version 3.11.X auf Version 4.0.X durch und sind dabei auf Probleme gestoßen.
  2. Sie haben Sicherungen für den Knoten, für den Sie ein Rollback durchführen. Das Backup wurde vor dem Upgrade von 3.11.X auf 4.0.X erstellt.

Schritte

  1. Wählen Sie einen Knoten aus, den Sie zurücksetzen möchten. Wenn Sie alle Knoten in einem Rechenzentrum mithilfe von Sicherungen zurücksetzen, beginnen Sie mit den Seed-Knoten. Weitere Informationen finden Sie im Anhang im Abschnitt „Seed-Knoten identifizieren“.

  2. Beenden Sie den Cassandra-Knoten, deinstallieren Sie ihn und bereinigen Sie ihn:

    # 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. Installieren Sie die ältere Cassandra-Software auf dem Knoten und konfigurieren Sie sie:

    • Führen Sie die Bootstrap-Datei für Edge for Private Cloud 4.52.02 aus:
      • # 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
    • Erstellen oder bearbeiten Sie die Datei /opt/apigee/customer/application/cassandra.properties:
      • conf_jvm_options_custom_settings=-Dcassandra.replace_address=ipOfNode -Dcassandra.allow_unsafe_replace=true
    • Prüfen Sie, ob die Datei dem Apigee-Nutzer gehört und lesbar ist:
      • chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
    • Cassandra installieren und einrichten:
      • # 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

    Prüfen Sie, ob der Knoten gestartet wurde. Führen Sie den folgenden Befehl auf diesem und anderen Knoten im Cluster aus. Knoten sollten melden, dass sich dieser Knoten im Status „UN“ befindet:

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

  4. Beenden Sie den Cassandra-Dienst und stellen Sie das Backup wieder her. Weitere Informationen finden Sie in der Dokumentation zum Sichern und Wiederherstellen:

    # 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. Entfernen Sie nach der Wiederherstellung der Sicherung die zusätzlichen Konfigurationen:

    Entfernen Sie die zuvor hinzugefügte Konfiguration aus der Datei /opt/apigee/customer/application/cassandra.properties.

  6. Starten Sie den Cassandra-Dienst auf dem Knoten:

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

  7. Wiederholen Sie die Schritte für jeden Cassandra-Knoten, den Sie mit Sicherungen zurücksetzen möchten, jeweils einzeln.

  8. Sobald alle Cassandra-Knoten wiederhergestellt sind, starten Sie alle edge-* Komponenten einzeln neu:

    /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

Sicherungsoptimierungen (erweiterte Option)

Sie können den Datenverlust beim Wiederherstellen von Sicherungen möglicherweise minimieren oder ganz vermeiden, wenn Replikate mit den neuesten Daten verfügbar sind. Wenn Replikate verfügbar sind, führen Sie nach dem Wiederherstellen der Sicherung eine Reparatur auf dem wiederhergestellten Knoten aus.

Anhang

Seed-Knoten identifizieren

Führen Sie den folgenden Befehl auf einem beliebigen Cassandra-Knoten in einem Rechenzentrum aus:

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

Der Befehl gibt mehrere Zeilen aus. Suchen Sie nach der letzten Zeile der Ausgabe. Die in der letzten Zeile aufgeführten IP-Adressen sind die Seed-Knoten. Im folgenden Beispiel sind DC-1-IP1, DC-1-IP2, DC-2-IP1 und DC-2-IP2 die IP-Adressen der Seed-Knoten:

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

Rollback für das Zookeeper-Update auf Version 3.8.4 ausführen

Rollback

Falls ein Rollback erforderlich ist:

  1. Führen Sie zuerst die Rollback-Schritte für Beobachter und Follower aus.
  2. Laden Sie den Bootstrap der Version herunter, auf die Sie ein Rollback durchführen – entweder 4.52.02 oder 4.53.00 – und führen Sie ihn aus. Der Vorgang hängt davon ab, ob der Knoten eine externe Internetverbindung hat oder ob Sie die Offline-Installation durchführen.
  3. Beenden Sie Zookeeper, falls es auf dem Knoten ausgeführt wird: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper stop
  4. Deinstallieren Sie den vorhandenen Zookeeper: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper uninstall
  5. Installieren Sie Zookeeper wie gewohnt: 
      /opt/apigee/apigee-setup/bin/setup.sh -p zk -f <silent-config-file>
  6. Nachdem alle Follower und Beobachter zurückgesetzt wurden, setzen Sie den Leader-Knoten zurück, indem Sie die Schritte 2 bis 5 auf dem Leader-Knoten ausführen.
  7. Nachdem alle Knoten zurückgesetzt wurden, prüfen Sie den Clusterstatus und stellen Sie sicher, dass es einen Leader-Knoten im Cluster gibt.

Sicherung wiederherstellen

Weitere Informationen finden Sie unter Aus einer Sicherung wiederherstellen. Backups von Zookeeper aus früheren Versionen von Edge for Private Cloud wie 4.52.02 oder 4.53.00 sollten mit der Version von Zookeeper in Edge for Private Cloud 4.53.01 kompatibel sein.

Postgres 17-Update rückgängig machen

Wenn Sie ein Upgrade auf Version 4.53.01 von Version 4.52.02 oder 4.53.00 durchgeführt haben, müssen Sie zusätzlich zu den Edge-Komponenten auch das Postgres-Update zurücksetzen.

So machen Sie das Postgres-Update rückgängig, wenn Sie Postgres in einer Master-Standby-Konfiguration aktualisieren:

  • Stufen Sie den neuen Stand-by-Knoten zum Postgres-Master hoch. Der neue Postgres-Master hat dieselbe Version wie Ihre vorherige Edge-Installation.
  • Konfigurieren Sie den alten Standby-Knoten als Standby-Knoten des neuen Masters. Der alte Standby-Knoten hat dieselbe Version wie Ihre vorherige Edge-Installation.
  • Registrieren Sie die neuen Master- und Standby-Knoten in den Analyse- und Verbrauchergruppen.

Wenn Sie das Rollback abgeschlossen haben, ist der alte Masterknoten nicht mehr erforderlich. Anschließend können Sie den alten Masterknoten außer Betrieb nehmen.

Hinweis

Bevor Sie ein Rollback von Postgres 17 auf 14 durchführen, führen Sie die folgenden Schritte sowohl auf dem neuen als auch auf dem alten Standby-Host aus, um die max_locks_per_transaction-Eigenschaft für apigee-postgresql zu aktualisieren:

  1. Erstellen Sie die Datei /opt/apigee/customer/application/postgresql.properties, falls sie nicht vorhanden ist.
  2. Ändern Sie die Eigentümerschaft dieser Datei in „apigee“: 
    sudo chown apigee:apigee /opt/apigee/customer/application/postgresql.properties
  3. Fügen Sie der Datei das folgende Attribut hinzu: 
    conf/postgresql.conf+max_locks_per_transaction=30000
  4. Konfigurieren Sie apigee-postgresql: 
    apigee-service apigee-postgresql configure
  5. Starten Sie apigee-postgresql neu: 
    apigee-service apigee-postgresql restart
  1. Prüfen Sie, ob der neue Standby-Postgres-Knoten ausgeführt wird: 
    /opt/apigee/apigee-service/bin/apigee-all status

    Wenn Postgres nicht ausgeführt wird, starten Sie es:

    /opt/apigee/apigee-service/bin/apigee-all start
  2. Prüfen Sie, ob Postgres auf dem alten Master-Knoten und dem alten Standby-Knoten beendet wurde: 
    /opt/apigee/apigee-service/bin/apigee-all status

    Wenn Postgres ausgeführt wird, beenden Sie es: 

    /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server stop  
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql stop
  3. Wenn Qpid installiert ist, starten Sie es auf dem alten Standby-Knoten: 
    /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server start
  4. Stufen Sie den neuen Standby-Knoten zum Postgres-Master hoch:
    1. Stufen Sie den neuen Standby-Knoten zum neuen Master hoch: 
      apigee-service apigee-postgresql promote-standby-to-master old_master_IP

      Geben Sie bei Aufforderung das Postgres-Passwort für den Nutzer „apigee“ ein. Das Standardpasswort ist „postgres“.

    2. Bearbeiten Sie die Konfigurationsdatei, die Sie zum Installieren Ihrer aktuellen Version von Edge verwendet haben, um Folgendes anzugeben: 
      # IP address of the new master:
PG_MASTER=new_standby_IP
# IP address of the old standby node
PG_STANDBY=old_standby_IP
    3. Konfigurieren Sie den neuen Master:
      /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-master -f configFile
  5. Wenn Sie den alten Standby-Knoten bereits auf die neuere Version aktualisiert haben, müssen Sie zuerst ein Downgrade der Apigee-Software auf dem alten Standby-Knoten durchführen. Wenn Sie die ältere Version noch auf dem alten Standby-Knoten haben, können Sie diesen Schritt überspringen und mit Schritt 6 fortfahren.
    1. Beenden Sie Postgres auf dem alten Standby-Knoten: 
      apigee-service apigee-postgresql stop
apigee-service edge-postgres-server stop
    2. Deinstallieren Sie Postgres vom alten Standby-Knoten: 
      apigee-service apigee-postgresql uninstall
apigee-service edge-postgres-server uninstall
    3. Löschen Sie das Postgres-Datenverzeichnis vom alten Standby-Knoten: 
      cd /opt/apigee/data/apigee-postgresql/pgdata
rm -rf *
    4. Laden Sie das Bootstrap der älteren Version (für die Apigee-Version, zu der Sie ein Rollback durchführen) auf den alten Standby-Knoten herunter und führen Sie es aus. Die genauen Schritte können je nach Art der Installation variieren (internetbasiert oder offline). Wenn Sie die ältere Version von Apigee-Bootstrap ausführen, werden die Yum-Repositories mit älteren Apigee-Daten eingerichtet.
    5. Postgres-Komponenten auf dem alten Standby-Knoten einrichten: 
      /opt/apigee/apigee-setup/bin/setup.sh -p ps -f configFile
    6. Prüfen Sie, ob für die Postgres-Komponenten auf dem alten Standby-Knoten ein Rollback auf die ältere Version ausgeführt wurde: 
      apigee-service apigee-postgresql version
apigee-service edge-postgres-server version
  6. Alten Standby-Knoten neu erstellen:
    1. Bearbeiten Sie die Konfigurationsdatei, die Sie zum Installieren Ihrer aktuellen Version von Edge verwendet haben, um Folgendes anzugeben: 
      # IP address of the new master:
PG_MASTER=new_standby_IP
# IP address of the old standby node
PG_STANDBY=old_standby_IP
    2. Entfernen Sie das Datenverzeichnis auf dem alten Standby-Knoten: 
      cd /opt/apigee/data/apigee-postgresql/pgdata
rm -rf *
    3. Konfigurieren Sie den alten Standby-Knoten als Standby-Knoten des neuen Masters neu: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-standby -f configFile
    4. Prüfen Sie, ob Postgres auf dem alten Standby-Knoten ausgeführt wird: 
      /opt/apigee/apigee-service/bin/apigee-all status

      Wenn Postgres nicht ausgeführt wird, starten Sie es:

      /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server start
  7. Prüfen Sie, ob der neue Standby-Knoten hinzugefügt wurde, indem Sie die Datei /opt/apigee/apigee-postgresql/conf/pg_hba.conf auf dem neuen Master ansehen.
  8. Rufen Sie die aktuellen Analysen und Informationen zur Verbrauchergruppe ab, indem Sie den folgenden Befehl auf dem Verwaltungsserver ausführen: 
    curl -u sysAdminEmail:password http://ms_IP:8080/v1/analytics/groups/ax

    Dieser Befehl gibt den Namen der Analytics-Gruppe im Feld name und den Namen der Verbrauchergruppe im Feld name unter consumer-groups zurück. Außerdem werden die UUIDs der alten Postgres-Master- und Standby-Knoten im Feld postgres-server und im Feld datastores zurückgegeben. Die Ausgabe sollte im folgenden Format angezeigt werden: 

    {
  "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" : {
  }
}
  9. Rufen Sie die UUID-Adresse des alten Masters ab, indem Sie den folgenden curl-Befehl auf dem alten Masterknoten ausführen: 
    curl -u sysAdminEmail:password http://node_IP:8084/v1/servers/self

    Am Ende der Ausgabe sollte die UUID des Knotens im folgenden Format angezeigt werden:

    "type" : [ "postgres-server" ],
"uUID" : "599e8ebf-5d69-4ae4-aa71-154970a8ec75"
  10. Wiederholen Sie den vorherigen Schritt, um die IP-Adressen des alten Standby-Knotens und des neuen Masters abzurufen.
  11. Entfernen Sie alte Master- und Standby-Knoten aus der Consumer-Gruppe: 
    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

    Dabei sind axgroup-001 und consumer-group-001 die Standardnamen der Analyse- und Verbrauchergruppen. masterUUID,standbyUUID sind in derselben Reihenfolge wie oben, als Sie sich die aktuellen Analyse- und Verbrauchergruppeninformationen angesehen haben. Möglicherweise müssen Sie sie als standbyUUID,masterUUID angeben.

    Die Property datastores für consumer-groups sollte jetzt leer sein.

  12. Entfernen Sie die alten Master- und Standby-Knoten aus der Analytics-Gruppe: 
    curl -u sysAdminEmail:password -X DELETE \
  "http://ms_IP:8080/v1/analytics/groups/ax/axgroup-001/servers?uuid=masterUUID,standbyUUID&type=postgres-server" -v

    Die Property postgres-server unter uuids sollte jetzt leer sein.

  13. Registrieren Sie neue Master- und Standby-Knoten für die PG bei den Analyse- und Verbrauchergruppen:
    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
  14. Analytics-Gruppe validieren: 
    curl -u sysAdminEmail:password http://ms_IP:8080/v1/analytics/groups/ax

    Die UUIDs der neuen Master- und Standby-Knoten sollten in der Analysegruppe und der Verbrauchergruppe aufgeführt sein.

  15. Starten Sie den Edge Management Server neu: 
    /opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
  16. Starten Sie alle Qpid-Server neu: 
    /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart
  17. Starten Sie alle Postgres-Server neu: 
    /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart
  18. Prüfen Sie den Replikationsstatus, indem Sie die folgenden Skripts auf beiden Servern ausführen. Das System sollte auf beiden Servern identische Ergebnisse anzeigen, um eine erfolgreiche Replikation zu gewährleisten:

    Führen Sie auf dem neuen Master Folgendes aus:

    /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-master

    Prüfen Sie, ob es sich um den Master handelt. Auf dem alten Stand-by-Knoten: 

    /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-standby

    Prüfen Sie, ob es sich um den Standby-Modus handelt.

  19. Wiederholen Sie den vorherigen Schritt nach mehreren API-Anfragen, um sicherzustellen, dass die Knoten synchronisiert sind.
  20. Nehmen Sie den alten Postgres-Master mithilfe des Verfahrens unter Postgres-Knoten außer Betrieb nehmen außer Betrieb.

    Alternativ können Sie Qpid vom alten Masterknoten deinstallieren und Qpid auf dem neuen Masterknoten installieren. Nach der Deinstallation von Qpid können Sie den alten Masterknoten außer Betrieb nehmen.

Rollback für das LDAP 2.6-Update ausführen

In diesem Abschnitt finden Sie eine umfassende Schritt-für-Schritt-Anleitung für das Rollback einer LDAP-Installation auf eine vorherige LDAP-Version. Der Rollback muss für den gesamten LDAP-Cluster durchgeführt werden und ist nur mit einer gültigen LDAP-Sicherung vor dem Upgrade möglich.

Das primäre Ziel ist, den gesamten LDAP-Cluster aus einer bekannten fehlerfreien Sicherung in einen konsistenten Zustand zurückzuversetzen. Dieses Verfahren ist für alle Szenarien gleich – Einzelserver, Aktiv/Aktiv und Aktiv/Passiv.

Voraussetzungen und wichtige Aspekte

  • Inkompatibilität von Sicherungen:Verwenden Sie eine Sicherung der älteren LDAP-Version 2.4, die Sie mit Edge for Private Cloud 4.52.02 oder 4.53.00 verwendet haben. Dieses Backup muss vor dem Upgrade erstellt worden sein. Sicherungen, die nach dem Upgrade erstellt wurden, sind nicht kompatibel und können nicht verwendet werden.
  • Ausfallzeiten der Management API:Während des LDAP-Rollbacks sind Management APIs nicht verfügbar, was sich auf Verwaltungsaufgaben auswirken kann. Schalten Sie alle Edge-Verwaltungsserver und die Edge-UI aus, bevor Sie mit dem LDAP-Rollback fortfahren.
  • Risiko von Datenverlust: Wenn Sie ohne ein gültiges, kompatibles Backup fortfahren, besteht das Risiko eines irreversiblen Datenverlusts.
  • Gültige Sicherung:Eine gültige LDAP-Sicherung vor dem Upgrade ist erforderlich.

Rollback-Verfahren

  1. Fahren Sie alle Edge-Verwaltungsserver und die Edge-UI herunter, bevor Sie mit dem LDAP-Upgrade fortfahren. 
    apigee-service edge-management-server stop
apigee-service edge-ui stop
  2. Vorhandene LDAP-Daten sichern (bevor LDAP beendet wird)

    Rufen Sie die Gesamtzahl der Datensätze als Referenz von allen LDAP-Servern ab. Die Anzahl der Datensätze sollte auf allen LDAP-Servern übereinstimmen.

          # 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
  3. Neues LDAP 2.6 beenden und deinstallieren

    Beenden Sie den apigee-openldap-Dienst und löschen Sie die Konfigurations- und Datenverzeichnisse. Dies muss auf allen LDAP-Servern erfolgen, jeweils ein Knoten im Cluster, um die Konsistenz zu gewährleisten.

    apigee-service apigee-openldap stop
apigee-service apigee-openldap uninstall
rm -rf /opt/apigee/data/apigee-openldap/*
  4. Alte LDAP-Version 2.4 installieren
    • Alte LDAP-Version installieren: 
      /opt/apigee/apigee-setup/bin/setup.sh -p ld -f /opt/silent.conf
    • LDAP-Version validieren: 
      source ~/.bash_profile
ldapsearch -VV

#Expected output:
ldapsearch: @(#) $OpenLDAP: ldapsearch 2.4.46
    • Wiederholen Sie die oben genannten Schritte für jeden LDAP-Knoten einzeln.
  5. Restdaten bereinigen

    Beenden Sie auf allen LDAP-Servern nacheinander den neu installierten Dienst und bereinigen Sie das zugehörige Datenverzeichnis, um die Wiederherstellung aus der Sicherung vorzubereiten.

    apigee-service apigee-openldap stop
rm -rf /opt/apigee/data/apigee-openldap/*
  6. LDAP-Daten wiederherstellen

    Bei der Einrichtung auf einem einzelnen Server können Sie direkt mit Schritt 5b fortfahren. Fahren Sie bei der Einrichtung mehrerer Server mit Schritt 5a fort.

    1. Aktiven LDAP-Server ermitteln

      Bevor Sie LDAP-Daten wiederherstellen, ermitteln Sie den aktiven Server (Anbieter), indem Sie diesen Befehl ausführen.

      grep -i '^olcSyncrepl:' /opt/apigee/data/apigee-openldap/slapd.d/cn=config/olcDatabase*\ldif

* **Note**:
* If this command returns output, the server is a passive server. 
* If it returns no output, the server is the active server.
    2. LDAP-Daten wiederherstellen (Schritt 4 muss auf allen Servern abgeschlossen sein, bevor die Wiederherstellung erfolgt.)
      • Stellen Sie das Backup auf dem einzelnen aktiven LDAP-Server wieder her, der in Schritt 5a ermittelt wurde. 
        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.
      • Starten Sie den apigee-openldap-Dienst. 
        apigee-service apigee-openldap start
  7. Verbleibende LDAP-Server starten

    Wenn Sie mehrere Server haben, starten Sie den Dienst auf jedem der LDAP-Server:

    apigee-service apigee-openldap start
  8. Endgültige Validierung
    • Im letzten Schritt prüfen Sie, ob der Rollback erfolgreich war und die Daten im gesamten LDAP-Cluster konsistent sind.
    • Führen Sie den Validierungsbefehl auf allen LDAP-Servern aus. Die Anzahl der Datensätze sollte auf allen Servern identisch sein und mit der Anzahl übereinstimmen, die Sie in Schritt 1 erfasst haben. 
      # 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
    • Sobald Sie bestätigt haben, dass die Daten korrekt und konsistent sind, ist das LDAP-Rollback abgeschlossen. Sie können jetzt mit dem Starten des edge-management-server, der edge-ui und aller anderen abhängigen Komponenten gemäß dem Standard-Upgradeverfahren Ihrer Organisation fortfahren.

Rollback zu einem vorherigen Haupt- oder Nebenrelease durchführen

So führen Sie ein Rollback zu einem früheren Haupt- oder Nebenrelease auf jedem Knoten durch, auf dem die Komponente gehostet wird:

  1. Laden Sie die Datei bootstrap.sh für die Version herunter, zu der Sie ein Rollback durchführen möchten:

    • Wenn du ein Rollback auf Version 4.52.02 durchführen möchtest, lade bootstrap_4.52.02.sh herunter.
  2. Stoppen Sie die Komponente, für die Sie ein Rollback durchführen möchten:
    1. Wenn Sie eine der Komponenten mit gemeinsamem Code auf dem Knoten zurücksetzen möchten, müssen Sie sie alle beenden, wie im folgenden Beispiel gezeigt: 
      /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. Wenn Sie eine andere Komponente auf dem Knoten zurücksetzen möchten, stoppen Sie nur diese Komponente: 
      /opt/apigee/apigee-service/bin/apigee-service component stop
  3. Wenn Sie die Monetarisierung zurücksetzen, deinstallieren Sie sie von allen Management Server- und Message Processor-Knoten: 
    /opt/apigee/apigee-service/bin/apigee-service edge-mint-gateway uninstall
  4. Deinstallieren Sie die Komponente, um ein Rollback auf dem Knoten durchzuführen:
    1. Wenn Sie eine der Komponenten mit gemeinsamem Code auf dem Knoten zurücksetzen möchten, müssen Sie alle deinstallieren, indem Sie die Komponentengruppe edge-gateway und apigee-cassandra-client deinstallieren, wie im folgenden Beispiel gezeigt: 
      /opt/apigee/apigee-service/bin/apigee-service edge-gateway uninstall
       
      /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra-client uninstall
    2. So machen Sie die Nginx-Aktualisierung rückgängig: 
      ###Find the apigee-nginx RPM 
rpm -qa | grep -i "apigee-nginx"

###Remove the apigee-nginx RPM
dnf remove apigee-nginx-1.26.x
    3. Wenn Sie eine andere Komponente auf dem Knoten zurücksetzen möchten, deinstallieren Sie nur diese Komponente, wie im folgenden Beispiel gezeigt: 
      /opt/apigee/apigee-service/bin/apigee-service component uninstall

      Dabei ist component der Name der Komponente.

    4. Wenn Sie den Edge-Router zurücksetzen möchten, müssen Sie zusätzlich zur Deinstallation der Komponentengruppe edge-gateway den Inhalt der Datei /opt/nginx/conf.d löschen: 
      cd /opt/nginx/conf.d
rm -rf *
  5. Deinstallieren Sie die Version 4.53.01 von apigee-setup: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-setup uninstall
  6. Installieren Sie die Version 4.52.02 des Dienstprogramms apigee-service und seine Abhängigkeiten. Im folgenden Beispiel wird die Version 4.52.02 von apigee-service installiert: 
    sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord

    Dabei sind uName und pWord der Nutzername und das Passwort, die Sie von Apigee erhalten haben. Wenn Sie pWord weglassen, werden Sie aufgefordert, sie einzugeben.

    Wenn ein Fehler auftritt, prüfen Sie, ob Sie die Datei bootstrap.sh in Schritt 1 heruntergeladen haben.

  7. Installieren Sie apigee-setup: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-setup install
  8. Installieren Sie die ältere Version der Komponente: 
    /opt/apigee/apigee-setup/bin/setup.sh -p component -f configFile

    Dabei ist component die zu installierende Komponente und configFile Ihre Konfigurationsdatei für die ältere Version.

  9. Wenn Sie ein Rollback von Qpid durchführen, leeren Sie die iptables: 
    sudo iptables -F
  10. Wiederholen Sie diesen Vorgang für jeden Knoten, auf dem die Komponente gehostet wird, die Sie zurücksetzen.

mTLS zurücksetzen

So machen Sie das mTLS-Update rückgängig:

  1. Apigee beenden: 
    apigee-all stop
  2. mTLS beenden: 
    apigee-service apigee-mtls uninstall
  3. mTLS neu installieren: 
    apigee-service apigee-mtls install
apigee-service apigee-mtls setup -f /opt/silent.conf