Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Rollback von Apigee Edge 4.54.00

Wenn während eines Updates auf Edge 4.54.00 ein Fehler auftritt, können Sie ein Rollback der Komponente durchführen, die den Fehler verursacht hat, und das Update dann noch einmal versuchen.

Sie können ein Rollback von Edge 4.54.00 auf eine der folgenden Hauptversionen durchführen:

Version 4.53.00
Version 4.53.01

Weitere Informationen finden Sie unter Apigee Edge-Release-Prozess.

Reihenfolge des Rollbacks

Das Rollback von Komponenten sollte in der umgekehrten Reihenfolge erfolgen, in der sie aktualisiert wurden. Eine typische allgemeine Rollback-Reihenfolge für Private Cloud 4.54.00 sieht so aus:

Machen Sie die Änderungen an Cassandra und Zookeeper rückgängig.
Führen Sie ein Rollback von Qpid, anderen analysebezogenen Komponenten und Postgres durch.
Rollback der Benutzeroberfläche durchführen
Rollback für LDAP durchführen.
Rollback für Verwaltungsserver durchführen.
Router und Message Processor zurücksetzen.

Angenommen, Sie haben alle Router und Message Processor, alle Verwaltungsserver, LDAP und einige UI-Knoten von Version 4.53.00 (oder) 4.53.01 auf Version 4.54.00 aktualisiert und möchten ein Rollback durchführen. In diesem Fall würden Sie so vorgehen:

Rollback für die aktualisierten UI-Knoten durchführen
Rollback für die LDAP-Knoten durchführen
Rollback der Verwaltungsserverknoten nacheinander durchführen
Alle RMPs nacheinander zurücksetzen

Hinweis: Apigee-SSO in Apigee Edge for Private Cloud 4.54.00 unterstützt keine direkten oder teilweisen Rollbacks. Wenn Sie Apigee-SSO zurücksetzen möchten, müssen Sie ein Rollback aller zuvor aktualisierten Komponenten durchführen und apigee-sso mithilfe der Konfigurationsdatei im Hintergrund aus Ihrer vorherigen Version wiederherstellen.

apigee-sso neu starten oder neu installieren:

Wenn Sie apigee-sso während des Upgrades nur beendet haben, starten Sie den Dienst neu.
Wenn Sie apigee-sso während des Upgrades deinstalliert haben, installieren Sie es mit der Konfigurationsdatei für die unbeaufsichtigte Installation aus Ihrer vorherigen Version neu:
- 4.53.01 Installationsschritte
- 4.53.00 Installationsschritte

Wer kann ein Rollback ausfü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 führen Sie Edge-Komponenten möglicherweise als unterschiedliche Nutzer aus. Wenn der Router beispielsweise auf privilegierte Ports wie die unter 1000 zugreifen muss, müssen Sie den Router als Root oder als Nutzer mit Zugriff auf diese Ports ausführen. Sie können eine Komponente als einen Nutzer und eine andere Komponente als einen anderen Nutzer ausführen.

Rollback von Cassandra durchführen

Wenn ein Hauptupgrade von Cassandra auf einem bestimmten Knoten durchgeführt wird, ändert Cassandra das Schema der auf diesem Knoten gespeicherten Daten. Daher ist ein direktes Rollback nicht möglich.

Rollback-Szenarien

In der folgenden Tabelle sind die Rollback-Strategien zusammengefasst, die Sie verwenden können:

Szenario	Rollback-Strategie
Einzelnes Rechenzentrum, einige Cassandra-Knoten aktualisiert	Sicherungen verwenden
Mehrere Rechenzentren, einige Knoten in einem Rechenzentrum 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 einem Back-up durch. Erstellen Sie die verbleibenden DCs aus dem zurückgesetzten DC neu.

Allgemeines

Beachten Sie bei einem Rollback Folgendes:

Rollback von Cassandra während des Cassandra-Upgrades: Wenn während des Cassandra-Upgrades Probleme auftreten, sollten Sie ein Rollback in Betracht ziehen. Folgen Sie den Rollback-Strategien in diesem Artikel, je nachdem, in welchem Zustand sich Ihr System während des Upgrades befindet.
Rollback mit Back-ups: Back-ups von Cassandra 5.0.X sind nicht mit Back-ups von Cassandra 4.0.X kompatibel. Wenn Sie Cassandra mithilfe der Wiederherstellung von Sicherungen zurücksetzen möchten, müssen Sie Sicherungen von Cassandra 4.0.X erstellen, bevor Sie das Upgrade versuchen.

Cassandra mit „rebuild“ zurücksetzen

Vorbereitung

Sie betreiben einen Edge for Private Cloud-Cluster der Version 4.53.00/4.53.01 in mehreren Rechenzentren.
Sie führen ein Upgrade von Cassandra von 4.0.X auf 5.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 4.0.X) ausgeführt wird.

Dieses Verfahren basiert auf dem Streamen von Daten aus einem vorhandenen Rechenzentrum. Je nachdem, wie viele Daten in Cassandra gespeichert sind, kann dies sehr lange dauern. Sie sollten darauf vorbereitet sein, den Laufzeittraffic während des Rollbacks von diesem Rechenzentrum wegzuleiten.

Allgemeine Schritte

Wählen Sie ein Rechenzentrum aus, das Sie zurücksetzen möchten (entweder teilweise oder vollständig aktualisiert). Laufzeittraffic an ein anderes funktionierendes Rechenzentrum umleiten.
Identifizieren Sie den Seed-Knoten im Rechenzentrum und beginnen Sie mit einem der Seed-Knoten.
Beenden Sie den Cassandra-Knoten, deinstallieren Sie ihn und bereinigen Sie ihn.
Installieren Sie die ältere Version von Cassandra auf dem Knoten und konfigurieren Sie sie nach Bedarf.
Entfernen Sie die zusätzlichen Konfigurationen, die Sie zuvor hinzugefügt haben.
Wiederholen Sie die obigen Schritte nacheinander für alle Seed-Knoten im Rechenzentrum.
Wiederholen Sie die obigen Schritte für alle verbleibenden Cassandra-Knoten im Rechenzentrum, einen nach dem anderen.
Erstellen Sie die Knoten aus dem vorhandenen funktionalen Rechenzentrum nacheinander neu.
Starten Sie alle edge-*-Komponenten im Rechenzentrum neu, die mit Cassandra verbunden sind.
Traffic testen und wieder zu diesem Rechenzentrum umleiten.
Wiederholen Sie die Schritte für jedes Rechenzentrum.

Detaillierte Schritte

Wählen Sie ein Rechenzentrum aus, in dem alle oder einige Cassandra-Knoten aktualisiert werden. Leiten Sie den gesamten Laufzeit-Proxy-Traffic und Verwaltungstraffic von diesem Rechenzentrum um, während die Cassandra-Knoten in diesem Rechenzentrum zurückgesetzt werden. Achten Sie darauf, dass alle Cassandra-Knoten den Status UN (Up/Normal) haben, 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 sehen Sie beispielsweise eine Instanz eines Clusters mit zwei Rechenzentren, bei dem alle DC-1-Knoten die Cassandra-Version 4 und alle DC-2-Knoten die Cassandra-Version 3 verwenden:

# 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]

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:

Beenden, deinstallieren und bereinigen Sie die Daten vom Cassandra-Knoten. Wählen Sie den ersten Seed-Knoten in Cassandra-Version 5 in diesem Rechenzentrum aus. Hör auf damit.

# 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

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

# 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

Erstellen oder bearbeiten Sie die Datei /opt/apigee/customer/application/cassandra.properties.
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
```
Achten Sie darauf, dass die Datei dem Apigee-Nutzer gehört und von ihm gelesen werden kann:
```
chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
```
Installieren und richten Sie Cassandra ein:

# 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

Prüfen Sie, ob der Knoten gestartet wurde. Prüfen Sie den folgenden Befehl auf diesem Knoten und anderen Knoten im Cluster. Der Knoten sollte den Status „UN“ (Up/Normal) melden:
```
/opt/apigee/apigee-cassandra/bin/nodetool status
```
Entfernen Sie die zuvor hinzugefügten zusätzlichen Konfigurationen aus der Datei /opt/apigee/customer/application/cassandra.properties.
Wiederholen Sie die Schritte 3 bis 10 nacheinander für alle Cassandra-Seed-Knoten im Rechenzentrum.
Wiederholen Sie die Schritte 3 bis 10 für alle verbleibenden Cassandra-Knoten im Rechenzentrum, einen nach dem anderen.
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 jeden Knoten einzeln aus:
```
/opt/apigee/apigee-cassandra/bin/nodetool rebuild -dc <name of working DC>
```
Dieser Vorgang kann einige Zeit dauern. Bei Bedarf können Sie streamingthroughput anpassen. Prüfen Sie nodetool netstats, um den Status des Vorgangs zu sehen.
(Optional) Führen Sie den Reparaturbefehl im Cassandra-Knoten aus, wenn die Daten nicht neu erstellt werden.
```
/opt/apigee/apigee-cassandra/bin/nodetool -h node-IP repair -pr
```

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

Validieren Sie den Traffic und leiten Sie ihn zurück zu diesem Rechenzentrum. Führen Sie einige Validierungen für Laufzeit-Traffic und Verwaltungs-APIs in diesem Rechenzentrum aus und leiten Sie den Proxy- und Verwaltungs-API-Traffic wieder dorthin um.
Wiederholen Sie die oben genannten Schritte für jedes Rechenzentrum, das Sie zurücksetzen möchten.

Cassandra mithilfe von Back-ups zurücksetzen

Vorbereitung

Sie führen ein Upgrade von Cassandra von 4.0.X auf 5.0.X durch und sind dabei auf Probleme gestoßen.
Sie haben Sicherungen für den Knoten, für den Sie ein Rollback durchführen. Die Sicherung wurde vor dem Upgrade von 4.0.X auf 5.0.X erstellt.

Schritte

Wählen Sie einen Knoten aus, für den Sie ein Rollback durchführen möchten. Wenn Sie für alle Knoten in einem Rechenzentrum ein Rollback mit Sicherungen durchführen, beginnen Sie mit den Seed-Knoten. Weitere Informationen finden Sie im Abschnitt Seed-Knoten identifizieren im Anhang.

Beenden, deinstallieren und bereinigen Sie den Cassandra-Knoten:

# 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

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

# 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

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

Achten Sie darauf, dass die Datei dem Apigee-Nutzer gehört und lesbar ist:

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

Installieren und richten Sie Cassandra ein:

# 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

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

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

Beenden Sie den Cassandra-Dienst und stellen Sie das Backup wieder her. Weitere Informationen finden Sie in der Dokumentation zu Sicherung und Wiederherstellung:

# 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

Entfernen Sie die zusätzlichen Konfigurationen, nachdem die Sicherung wiederhergestellt wurde:

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

Starten Sie den Cassandra-Dienst auf dem Knoten:

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

Wiederholen Sie die Schritte für jeden Cassandra-Knoten, den Sie mithilfe von Sicherungen nacheinander zurücksetzen möchten.

Nachdem alle Cassandra-Knoten wiederhergestellt wurden, 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)

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

Anhang

Seed-Knoten identifizieren

Führen Sie auf einem beliebigen Cassandra-Knoten in einem Rechenzentrum den folgenden Befehl 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 Seed-Knoten-IPs:

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

ZooKeeper-Rollback durchführen

Rollback

Falls ein Rollback erforderlich ist:

Führen Sie die Rollback-Schritte zuerst für Beobachter und Follower aus. Informationen zur Auswahl von Beobachtern und Followern finden Sie unter Leader, Follower und Beobachter identifizieren.
Laden Sie die Bootstrap-Datei der Version herunter, auf die Sie ein Rollback durchführen möchten (entweder 4.53.00 oder 4.53.01), und führen Sie sie aus. Der Vorgang hängt wahrscheinlich davon ab, ob der Knoten eine externe Internetverbindung hat oder ob Sie eine Offlineinstallation durchführen.

Beenden Sie Zookeeper, falls es auf dem Knoten ausgeführt wird:

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

Deinstallieren Sie den vorhandenen Zookeeper:

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

Installieren Sie ZooKeeper wie gewohnt:

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

Nachdem alle Follower und Beobachter zurückgesetzt wurden, setzen Sie den Leader-Knoten zurück. Führen Sie dazu die Schritte 2 bis 5 auf dem Leader-Knoten aus.
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 findest du unter Daten aus einer Sicherung wiederherstellen.

Rollback für Qpid durchführen

Hinweis:Führen Sie zuerst ein Rollback von apigee-qpidd durch, bevor Sie versuchen, ein Rollback anderer Edge-Komponenten (edge-qpid-server, edge-message-processor, edge-management-server) durchzuführen.

Wenn Sie ein Rollback auf einen früheren Feature Release durchführen möchten, laden Sie die Datei bootstrap.sh für die Version herunter, auf die Sie ein Rollback durchführen möchten. Wenn Sie ein Rollback auf Version 4.53.00/4.53.01 durchführen möchten, laden Sie bootstrap_4.53.00.sh herunter.

So führen Sie ein Rollback von Qpid auf allen Qpid-Hosts durch:

Beenden Sie den vorhandenen Qpid-Broker:
```
apigee-service apigee-qpidd stop
```
Blockieren Sie eingehenden Traffic auf Broker-Port 5672 von allen Message Processors, indem Sie eine Firewall anwenden. Sie können diese Firewall auf der Ebene der Qpid-Knoteninstanz oder einer anderen externen Firewall-/Netzwerkkomponente anwenden.
Wir empfehlen, diesen Schritt für alle IP-Adressen des Message Processors auszuführen. Wenn Sie beispielsweise Anfragen von Message Processor-IP-Adressen an den Qpid-Knoten auf Port 5672 mit IPTables ablehnen möchten, können Sie einen Befehl wie diesen verwenden:
```
iptables -A INPUT -p tcp --dport 5672 -s MESSAGE_PROCESSOR_IP -j DROP
```
Starten Sie den Qpid-Broker noch einmal, um vorhandene Nachrichten zu leeren:
```
apigee-service apigee-qpidd start
```
Die vorhandenen Warteschlangen müssen leer sein. Melden Sie sich zur Überprüfung im Qpid-Verwaltungsportal an:
```
http://QPID_NODE_IP:8090
```
Hinweis:Wenn auf diesen Port 8090 auf dem QPID-Knoten nicht zugegriffen werden kann, können Sie alternative Mechanismen wie die SSH-Portweiterleitung verwenden, um auf diese URL zuzugreifen.

Nachdem Sie überprüft haben, dass die Warteschlangen geleert wurden, beenden Sie Qpid und deinstallieren Sie es:

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

Löschen Sie das Qpid-Datenverzeichnis:
```
rm -r APIGEE_ROOT/data/apigee-qpidd
```

Installieren Sie den Qpid-Broker neu:

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

Nachdem der Qpid-Broker neu installiert wurde, entfernen Sie die Firewalleinstellungen und listen Sie alle vorhandenen Einstellungen mit den folgenden Befehlen auf:
```
iptables -F
iptables -L
```

Postgres-Rollback durchführen

Wenn Sie ein Downgrade von Version 4.54.00 auf Version 4.53.00/4.53.01 durchführen möchten, müssen Sie zusätzlich zu den Edge-Komponenten ein Rollback des Postgres-Updates durchführen.

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 bei den Analyse- und Consumer-Gruppen.

Wenn Sie mit dem Rollback fertig sind, wird der alte Masterknoten nicht mehr benötigt. Anschließend können Sie den alten Masterknoten außer Betrieb nehmen.

Hinweis

Führen Sie vor dem Rollback von Postgres 18 auf 17/14 die folgenden Schritte sowohl auf dem neuen als auch auf dem alten Standby-Host aus, um das Attribut max_locks_per_transaction in apigee-postgresql zu aktualisieren:

Erstellen Sie die Datei /opt/apigee/customer/application/postgresql.properties, falls sie nicht vorhanden ist.

Ändern Sie die Eigentümerschaft dieser Datei in „apigee“:

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

Fügen Sie der Datei das folgende Attribut hinzu:

conf/postgresql.conf+max_locks_per_transaction=30000

Konfigurieren Sie „apigee-postgresql“:

apigee-service apigee-postgresql configure

Starten Sie apigee-postgresql neu:

apigee-service apigee-postgresql restart

Detaillierte Rollback-Anleitung

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

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

Wenn Qpid installiert ist, starten Sie es auf dem alten Standby-Knoten:
```
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server start
```
Hinweis: In vielen Konfigurationen hostet der alte Standby-Knoten nur Postgres, aber nicht Qpid.
Stufen Sie den neuen Standby-Knoten zum Postgres-Master hoch:
1. Stufen Sie den neuen Stand-by-Knoten zum neuen Master hoch:
```
apigee-service apigee-postgresql promote-standby-to-master old_master_IP
```
  Geben Sie das Postgres-Passwort für den Nutzer „apigee“ ein, wenn Sie dazu aufgefordert werden. Der Standardwert ist „postgres“.
2. Bearbeiten Sie die Konfigurationsdatei, die Sie zur Installation Ihrer aktuellen Edge-Version 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
```
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
apigee-service edge-analytics 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, auf die Sie ein Rollback durchführen) auf den alten Standby-Knoten herunter und führen Sie es aus. Die genauen Schritte können variieren, je nachdem, ob Sie eine internetbasierte oder eine Offline-Installation verwenden. 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
```

Hinweis: Entfernen Sie das RPM postgresql18-libs-18.3-1PGDG, falls es noch vorhanden ist.

Erstellen Sie den alten Standby-Knoten neu:
1. Bearbeiten Sie die Konfigurationsdatei, die Sie zur Installation Ihrer aktuellen Edge-Version 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
```
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.

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 Analysegruppe im Feld name und den Namen der Nutzergruppe 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 so aussehen:

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

Rufen Sie die UUID-Adresse des alten Primärknotens ab, indem Sie den folgenden curl-Befehl auf dem alten Primärknoten ausführen:
```
curl -u sysAdminEmail:password http://node_IP:8084/v1/servers/self
```
Am Ende der Ausgabe sollte die UUID des Knotens in folgendem Format angezeigt werden:
```
"type" : [ "postgres-server" ],
"uUID" : "599e8ebf-5d69-4ae4-aa71-154970a8ec75"
```
Hinweis: Der edge-postgres-server-Dienst muss ausgeführt werden. Wenn der Postgres-Server nicht ausgeführt wird, können Sie den folgenden Befehl auf dem Management Server ausführen, um die UUID zu ermitteln:
```
curl -u sysAdminEmail:password http://ms_IP:8080/v1/servers?pod=analytics
```
Die Ausgabe dieses Befehls listet die UUID für die IP-Adresse jedes Postgres-Knotens auf.
Wiederholen Sie den vorherigen Schritt, um die IP-Adressen des alten Standby-Knotens und des neuen Primärknotens abzurufen.
Entfernen Sie die alten Master- und Standby-Knoten aus der Nutzergruppe:
```
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 Nutzergruppen. Die masterUUID,standbyUUID sind in derselben Reihenfolge wie oben, als Sie die aktuellen Analyse- und Nutzergruppeninformationen angesehen haben. Möglicherweise müssen Sie sie als standbyUUID,masterUUID angeben.

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

Entfernen Sie die alten Master- und Standby-Knoten aus der Analysegruppe:

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

Das Attribut postgres-server unter uuids sollte jetzt leer sein.

Registrieren Sie neue primäre und Standby-Knoten für 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

Validieren Sie die Analysegruppe:
```
curl -u sysAdminEmail:password http://ms_IP:8080/v1/analytics/groups/ax
```
Die UUIDs der neuen Master- und Standby-Knoten sollten in der Analyse- und der Consumer-Gruppe aufgeführt sein.

Starten Sie den Edge Management Server neu:

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

Starten Sie alle Qpid-Server neu:

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

Starten Sie alle Postgres-Server neu:

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

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 den folgenden Befehl aus:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-master
```
Prüfen Sie, ob es sich um den Master handelt. Führen Sie auf dem alten Stand-by-Knoten den folgenden Befehl aus:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-standby
```
Prüfen Sie, ob es sich um die Stand-by-Instanz handelt.
Wiederholen Sie den vorherigen Schritt nach mehreren API-Anfragen, um sicherzustellen, dass die Knoten synchronisiert sind.
Außerbetriebnahme des alten Postgres-Masters:
Hinweis:Wenn auf dem alten Masterknoten Qpid ausgeführt wurde, können Sie den Server für die Ausführung von Qpid beibehalten. Prüfen Sie, ob er ausgeführt wird. Falls nicht, starten Sie ihn:
```
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server start
/opt/apigee/apigee-service/bin/apigee-service apigee-qpidd start
```
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 der neuen Edge-Benutzeroberfläche durchführen

In Apigee Edge for Private Cloud 4.54.00 wird die klassische Benutzeroberfläche (edge-ui) durch die neue Edge-Benutzeroberfläche (edge-management-ui) ersetzt. Da sich die UI-Komponente in 4.54.00 ändert, müssen Sie für ein Rollback auf Version 4.53.00 oder 4.53.01 die edge-management-ui deinstallieren und Ihr vorheriges UI-Profil neu installieren:

Klassische Benutzeroberfläche (edge-ui): Installieren Sie das ui-Profil neu.
Neue Edge-Benutzeroberfläche (edge-ui und edge-management-ui): Installieren Sie die Profile ui und ue auf den jeweiligen Knoten neu.

So führen Sie ein Rollback der Benutzeroberfläche auf einem Knoten durch:

Die neue Edge-Benutzeroberfläche 4.54.00 beenden und deinstallieren und die vorherige Version installieren, um ein Rollback durchzuführen:

Beenden und deinstallieren Sie die New Edge-Benutzeroberfläche 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

Führen Sie die Bootstrap-Datei für Apigee Edge for Private Cloud 4.53.00/4.53.01 aus:

# 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

Rollback von apigee-setup von Version 4.54.00 auf die vorherige Version durchführen:

# 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

Konfigurationen der Benutzeroberfläche in Version 4.53.00/4.53.01 wiederherstellen:
- Wenn Sie die Konfigurationsdatei für die unbeaufsichtigte Installation aus Ihrer 4.53.00- oder 4.53.01-Installation gesichert haben, verwenden Sie diese Sicherungsdatei für das Rollback-Verfahren. Andernfalls müssen Sie in der Konfigurationsdatei für die automatische Installation von Version 4.54.00 die UI-Attribute von Version 4.53.00 oder 4.53.01 wiederherstellen oder die Auskommentierung aufheben, die während des Upgrades entfernt oder auskommentiert wurden. Weitere Informationen finden Sie im Abschnitt zum UI-Upgrade.
- Wenn /opt/apigee/customer/application/ui.properties während des Upgrades gelöscht wurde, stellen Sie es aus dem Sicherungsverzeichnis wieder her:
```
cp -rf /opt/apigee/backup/ui/customer/application/ui.properties /opt/apigee/customer/application/
chown apigee:apigee /opt/apigee/customer/application/ui.properties
```
Installieren und konfigurieren Sie die vorherige UI-Version neu:
- Rollback zur klassischen Benutzeroberfläche (edge-ui):
  1. Installieren und richten Sie die klassische Benutzeroberfläche ein (für die einfache Authentifizierung sind keine zusätzlichen Schritte erforderlich):
```
/opt/apigee/apigee-setup/bin/setup.sh -p ui -f configFile
```
  2. Wenn SSO aktiviert ist, konfigurieren Sie SSO in der klassischen Benutzeroberfläche (stellen Sie zuerst sicher, dass apigee-sso ausgeführt wird):
```
/opt/apigee/apigee-service/bin/apigee-service edge-ui configure-sso -f configFile
```
- Zurücksetzen auf 4.53.00 oder 4.53.01 – Neue Edge-Benutzeroberfläche (edge-management-ui und Shoehorn edge-ui):
  1. Achten Sie darauf, dass EDGEUI_ENABLE_UNIFIED_UI=y in der Konfigurationsdatei für die unbeaufsichtigte Installation festgelegt ist. Installieren und richten Sie dann die Profile ui und ue ein:
```
/opt/apigee/apigee-setup/bin/setup.sh -p ui -f configFile
/opt/apigee/apigee-setup/bin/setup.sh -p ue -f configFile
```
  2. Wenn SSO aktiviert ist, konfigurieren Sie SSO auf beiden UI-Komponenten. Achten Sie darauf, dass apigee-sso zuerst ausgeführt wird:
```
/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
```
Hinweis: In einer Topologie mit mehreren Knoten, in der die klassische Benutzeroberfläche und die neue Edge-Benutzeroberfläche 4.53.01 auf separaten Knoten gehostet wurden, führen Sie die Rollback-Befehle auf den jeweiligen Hosts aus. Der Befehl configure-sso muss nur ausgeführt werden, wenn SSO in der vorherigen Version konfiguriert wurde.
- Knoten 1 (Knoten der klassischen Benutzeroberfläche): Führen Sie die Befehle der klassischen Benutzeroberfläche aus:
```
/opt/apigee/apigee-setup/bin/setup.sh -p ui -f configFile
/opt/apigee/apigee-service/bin/apigee-service edge-ui configure-sso -f configFile
```
- Knoten 2 (neuer Edge-UI-Knoten): Führen Sie die Befehle für die neue Edge-UI aus (setup.sh -p ue und 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
```

Prüfen Sie den Status und die Version der zurückgesetzten Benutzeroberfläche:

Für die klassische UI (edge-ui):

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

Für die neue Edge-Benutzeroberfläche (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

Hinweis:In Apigee Edge for Private Cloud-Versionen vor 4.54.00 konnten die Classic Edge-Benutzeroberfläche (edge-ui) und die New Edge-Benutzeroberfläche (edge-management-ui) nicht auf demselben Knoten vorhanden sein. Administratoren mussten für jede UI-Komponente separate, dedizierte Knoten bereitstellen, wenn sie diese früheren Versionen ausführten.

Rollback für OpenLDAP durchführen

In diesem Abschnitt finden Sie eine detaillierte Anleitung zum Rollback von Symas OpenLDAP 2.6.10 in Edge for Private Cloud 4.54.00 auf OpenLDAP 2.4.46 (Edge for Private Cloud 4.53.00) oder Symas OpenLDAP 2.6.7 (Edge for Private Cloud 4.53.01). Sie müssen das Rollback für den gesamten LDAP-Cluster mit einer gültigen LDAP-Sicherung vor dem Upgrade durchführen.

Das Hauptziel besteht darin, den gesamten LDAP-Cluster aus einer bekannten, fehlerfreien Sicherung in einen konsistenten Zustand zurückzusetzen. Dieses Verfahren ist für alle Szenarien gleich: Einzelserver, Aktiv/Aktiv und Aktiv/Passiv.

Hinweis

Inkompatibilität von Sicherungen: Verwenden Sie eine Sicherung vor dem Upgrade von OpenLDAP 2.4.46 (Edge for Private Cloud 4.53.00) oder Symas OpenLDAP 2.6.7 (Edge for Private Cloud 4.53.01), die vor dem Upgradeversuch mit apigee-service apigee-openldap backup erstellt wurde. Sicherungen, die nach dem Upgrade erstellt wurden, sind inkompatibel und können nicht verwendet werden.
Ausfallzeiten der Management API:Während des LDAP-Rollbacks sind Management APIs nicht verfügbar. Dies kann sich auf Verwaltungsaufgaben auswirken. Fahren Sie alle edge-management-server- und edge-ui-Instanzen herunter, bevor Sie mit dem LDAP-Rollback fortfahren.
Hinweis: Wenn Sie die neue Edge-Benutzeroberfläche (edge-management-ui) verwenden, müssen Sie sowohl die klassische Benutzeroberfläche (edge-ui) als auch die neue Edge-Benutzeroberfläche (edge-management-ui) beenden.
Risiko von Datenverlust: Wenn Sie ohne ein gültiges, kompatibles Backup fortfahren, riskieren Sie einen irreversiblen Datenverlust.
Gültige Sicherung:Eine gültige LDAP-Sicherung vor dem Upgrade ist erforderlich.
Sicherung von silent.conf-Dateien: Behalten Sie Sicherungen Ihrer silent.conf-Dateien sowohl aus der vorherigen als auch aus der aktuellen Version bei, um Konfigurationsverwechslungen während der Upgrade- und Rollback-Verfahren zu vermeiden.
Rollback-Reihenfolge:Führen Sie die Rollback-Prozeduren für Cassandra, ZooKeeper, Qpid, PostgreSQL, apigee-sso und die Edge-UI aus, bevor Sie ein Rollback von OpenLDAP durchführen.

Rollback-Verfahren

Management Server und Benutzeroberfläche herunterfahren:Fahren Sie alle edge-management-server- und edge-ui-Instanzen herunter, bevor Sie mit dem LDAP-Rollback fortfahren:
```
apigee-service edge-management-server stop
apigee-service edge-ui stop
```
Aktuelle Anzahl der LDAP-Einträge aufzeichnen (bevor LDAP beendet wird): Rufen Sie die Gesamtzahl der Einträge von allen LDAP-Servern ab. Ersetzen Sie YOUR_PASSWORD durch Ihr aktuelles LDAP-Administratorpasswort. (Die Anzahl der Einträge muss 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
```
Neues LDAP 2.6 beenden und deinstallieren:Beenden Sie den Dienst apigee-openldap und löschen Sie die Konfigurations- und Datenverzeichnisse. Führen Sie diesen Schritt auf allen LDAP-Servern aus, jeweils ein Knoten im Cluster, um Konsistenz zu gewährleisten:
```
apigee-service apigee-openldap stop
apigee-service apigee-openldap uninstall
rm -rf /opt/apigee/data/apigee-openldap/*
```

Vorherige LDAP-Version 2.4.46 oder 2.6.7 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 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

Wiederholen Sie die vorherigen Teilschritte in Schritt 4 für jeden LDAP-Knoten einzeln.

Restdaten bereinigen: Beenden Sie auf allen LDAP-Servern nacheinander den neu installierten Dienst und bereinigen Sie das Datenverzeichnis, um die Wiederherstellung aus der Sicherung vorzubereiten:
```
apigee-service apigee-openldap stop
rm -rf /opt/apigee/data/apigee-openldap/*
```
LDAP-Daten wiederherstellen:Bei einer Einrichtung mit einem einzelnen Server fahren Sie direkt mit Schritt 6b fort. Fahren Sie bei einer Einrichtung mit mehreren Servern mit Schritt 6a 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
```
  Hinweis:
  1. Wenn dieser Befehl eine Ausgabe zurückgibt, ist der Server ein passiver Server.
  2. Wenn dieser Befehl keine Ausgabe zurückgibt, ist der Server der aktive Server.
2. LDAP-Daten wiederherstellen (Schritt 5 muss auf allen Servern abgeschlossen sein, bevor Sie die Daten wiederherstellen):
  - Rufen Sie auf dem einzelnen oder aktiven LDAP-Server (siehe Schritt 6a) das Sicherungsverzeichnis auf und stellen Sie die Sicherung von vor dem Upgrade wieder her (z. B. 2025.07.28,13.59.00 oder lassen Sie den Zeitstempel weg, wenn die Sicherung von vor dem Upgrade die letzte Sicherung im Verzeichnis ist):
```
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
```
Verbleibende LDAP-Server starten:Wenn Sie eine Einrichtung mit mehreren Servern haben, starten Sie den Dienst auf jedem der verbleibenden LDAP-Server:
```
apigee-service apigee-openldap start
```
Hinweis: Sie müssen die Daten auf diesen Peer-Servern nicht manuell wiederherstellen. Beim Starten stellen sie eine Verbindung zum ersten Server her (der jetzt die wiederhergestellten Daten enthält) und synchronisieren das gesamte Verzeichnis automatisch durch Replikation.
Abschließende Validierung:
- Prüfen Sie, ob das Rollback erfolgreich war und die Daten im gesamten LDAP-Cluster konsistent sind.
- Führen Sie den Validierungsbefehl auf allen LDAP-Servern aus und ersetzen Sie dabei YOUR_PASSWORD durch Ihr aktuelles LDAP-Manager-Passwort. Die Anzahl der Datensätze muss auf allen Servern identisch sein und mit der Anzahl übereinstimmen, die Sie in Schritt 2 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
```
- Nachdem Sie bestätigt haben, dass die Daten korrekt und konsistent sind, starten Sie edge-management-server, edge-ui und alle anderen abhängigen Komponenten gemäß dem Standardverfahren Ihrer Organisation.

Rollback für Edge-Komponenten durchführen

Komponenten mit gemeinsamem Code

Die folgenden Edge-Komponenten verwenden gemeinsamen 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 (Message Processor)
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.

Wenn Sie ein Rollback auf eine frühere Haupt- oder Nebenversion durchführen möchten, gehen Sie auf jedem Knoten, auf dem die Komponente gehostet wird, so vor:

Laden Sie die Datei bootstrap.sh für die Version herunter, auf die Sie ein Rollback durchführen möchten:
- Wenn Sie ein Rollback auf 4.53.00/4.53.01 durchführen möchten, laden Sie bootstrap_4.53.00.sh/bootstrap_4.53.01.sh herunter.

Beenden Sie die Komponente, um ein Rollback auszuführen:

Wenn Sie eine der Komponenten mit gemeinsamem Code auf dem Knoten zurücksetzen möchten, müssen 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

Wenn Sie eine andere Komponente auf dem Knoten zurücksetzen möchten, beenden Sie nur diese Komponente:
```
/opt/apigee/apigee-service/bin/apigee-service component stop
```

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
```
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 führen Sie ein Rollback für Nginx durch:
```
### Find the apigee-nginx RPM
rpm -qa | grep -i "apigee-nginx"

### Remove the apigee-nginx RPM
dnf remove apigee-nginx-1.30.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.
  Hinweis: Wenn edge-analytics nicht automatisch zusammen mit edge-qpid-server und edge-postgres-server deinstalliert wird, deinstallieren Sie es manuell mit dem folgenden Befehl:
```
/opt/apigee/apigee-service/bin/apigee-service edge-analytics uninstall
```
4. Wenn Sie ein Rollback des Edge-Routers durchführen 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 *
```

Deinstallieren Sie die Version 4.54.00 von apigee-setup:

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

Installieren Sie die Version 4.53.00 des apigee-service-Dienstprogramms und die zugehörigen Abhängigkeiten. Im folgenden Beispiel wird die Version 4.53.00 von apigee-service installiert:
```
sudo bash /tmp/bootstrap_4.53.00.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, es einzugeben.

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

Installieren Sie apigee-setup:

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

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 die Konfigurationsdatei für die ältere Version.
Wenn Sie ein Rollback von Qpid durchführen, leeren Sie iptables:
```
sudo iptables -F
```
Wiederholen Sie diesen Vorgang für jeden Knoten, auf dem die Komponente gehostet wird, für die Sie ein Rollback durchführen.

Hinweis: Bei der Deinstallation von apigee-cassandra-client werden apigee-provision und apigee-validate aufgrund ihrer Abhängigkeit automatisch entfernt. Wenn sie später benötigt werden, müssen sie neu installiert werden.

mTLS-Rollback durchführen

Führen Sie die folgenden Schritte auf allen Hosts aus, um das mTLS-Update rückgängig zu machen:

Apigee beenden:
```
apigee-all stop
```
mTLS beenden:
```
apigee-service apigee-mtls uninstall
```

mTLS neu installieren:

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