Rollback auf Apigee Edge 4.53.00

Wenn bei einem Update auf Edge 4.53.00 ein Fehler auftritt, können Sie die Komponente, die den Fehler verursacht hat, rückgängig machen und das Update dann noch einmal versuchen.

Sie können Edge 4.53.00 auf die folgende Minor-Release-Version zurücksetzen:

• Version 4.52.02

Wenn Sie eine Version rückgängig machen, wird jede Komponente rückgängig gemacht, die Sie möglicherweise aktualisiert haben. Außerdem sollten Sie beim Zurücksetzen von Cassandra auf Version 4.52.02 besondere Aspekte berücksichtigen.

Es gibt zwei Szenarien, in denen Sie ein Rollback ausführen können:

1. Führen Sie ein Rollback auf eine vorherige Haupt- oder Nebenversion durch. Beispiel: von 4.53.00 auf 4.52.02.
2. Rollback zu einem früheren Patch-Release im selben Release durchführen Beispiel: von 4.53.00.01 auf 4.53.00.00.

Weitere Informationen finden Sie im Apigee Edge-Releaseprozess.

Reihenfolge des Rollbacks

Das Rollback von Komponenten sollte in umgekehrter Reihenfolge der durchgeführten Upgrades erfolgen, mit der Ausnahme, dass Verwaltungsserver nach Cassandra rückgesetzt werden sollten.

Ein typischer allgemeiner Ablauf für das Rollback bei Private Cloud 4.53.00 sieht so aus:

1. Rollback für Postgres, Qpid und andere analysebezogene Komponenten
2. Rollback für Router und Message Processors
3. Rollback für Cassandra, Zookeeper
4. Rollback-Verwaltungsserver

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

1. Alle RMPs einzeln rückgängig machen
2. Mithilfe von Back-ups ein Rollback für den gesamten Cassandra-Cluster ausführen
3. Edge-Verwaltungsserverknoten einzeln rückgängig machen

Wer kann ein Rollback ausführen?

Der Nutzer, der ein Rollback ausführt, muss derselbe sein wie der Nutzer, 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 zugreifen muss, z. B. auf Ports unter 1.000, müssen Sie ihn als Root oder als Nutzer mit Zugriff auf diese Ports ausführen. Sie können auch eine Komponente als einen Nutzer und eine andere Komponente als einen anderen Nutzer ausführen.

Komponenten mit gemeinsamem Code

Die folgenden Edge-Komponenten teilen sich gemeinsamen Code. Wenn Sie also eine dieser Komponenten auf einem Knoten rückgängig machen möchten, müssen Sie alle Komponenten auf diesem Knoten rückgängig machen.

• 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 Verwaltungsserver, den Router und den Nachrichtenprozessor auf dem Knoten installiert haben, müssen Sie alle drei zurücksetzen, um einen davon rückgängig zu machen.

Rollback von Cassandra

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

Rollback-Szenarien

Cassandra 4.0.X, verfügbar mit Edge for Private Cloud 4.53.00, 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
Ein einzelnes Rechenzentrum, alle Cassandra-Knoten werden aktualisiert	Führen Sie kein Rollback für Cassandra durch. Andere Komponenten können rückgängig gemacht werden.
Ein einzelnes Rechenzentrum, alle Knoten (Cassandra und andere) wurden aktualisiert	Führen Sie kein Rollback für Cassandra durch. Andere Komponenten können rückgängig gemacht 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 DC, Cassandra-Knoten des letzten DC werden aktualisiert	Versuchen Sie, das Upgrade abzuschließen. Falls nicht möglich, führe einen Rollback für einen DC mithilfe der Sicherung durch. Erstellen Sie die verbleibenden DCs neu, ausgehend vom rückgängig gemachten DC.
Mehrere Rechenzentren, alle Cassandra-Knoten aktualisiert	Führen Sie kein Rollback für Cassandra durch. Andere Komponenten können rückgängig gemacht werden.
Mehrere Rechenzentren, alle Knoten (Cassandra und andere) wurden aktualisiert	Führen Sie kein Rollback für Cassandra durch. Andere Komponenten können rückgängig gemacht werden.

Allgemeines

Beachten Sie Folgendes, wenn Sie ein Rollback in Betracht ziehen:

• Rollback von Laufzeit- oder Verwaltungskomponenten:Wenn Sie Komponenten wie edge-management-server, edge-message-processor oder eine andere nicht-Cassandra-Komponente auf die Private Cloud-Version 4.52.02 zurücksetzen möchten, sollten Sie Cassandra NICHT zurücksetzen. Die mit Private Cloud 4.53.00 gelieferte 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 aufgeführten Methode rücksetzen, während Cassandra bei Version 4.0.13 bleibt.
• Rollback, nachdem der gesamte Cassandra-Cluster auf 4.0.X aktualisiert wurde:Wenn Ihr gesamter Cassandra-Cluster im Rahmen des Upgrades auf die Private Cloud-Version 4.53.00 auf Version 4.0.X aktualisiert wurde, sollten Sie mit dieser Clusterkonfiguration fortfahren und KEIN Rollback für Cassandra ausfü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 ein Rollback in Betracht ziehen. Die in diesem Artikel aufgeführten Rollback-Strategien können je nach Status während des Upgrade-Prozesses angewendet 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 Cassandra mithilfe der Sicherungswiederherstellung rückgängig machen möchten, müssen Sie vor dem Upgrade Sicherungen von Cassandra 3.11.X erstellen.

Cassandra mithilfe von „Rebuild“ rückgängig machen

Vorbereitung

• Sie betreiben einen Edge for Private Cloud 4.52.02-Cluster in mehreren Rechenzentren.
• Sie führen ein Upgrade von Cassandra von Version 3.11.X auf Version 4.0.X durch und haben dabei Probleme festgestellt.
• Im Cluster gibt es mindestens ein voll funktionsfähiges Rechenzentrum, in dem noch die ältere Cassandra-Version (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 bereit sein, den Laufzeit-Traffic während des Rollbacks von diesem Rechenzentrum wegzuleiten.

Allgemeine Schritte

1. Wählen Sie ein Rechenzentrum aus, das Sie teilweise oder vollständig auf die vorherige Version zurücksetzen möchten. Laufzeit-Traffic wird an ein anderes funktionierendes Rechenzentrum weitergeleitet.
2. Identifizieren Sie den Startknoten im Rechenzentrum und beginnen Sie mit einem der Startknoten.
3. Beenden, deinstallieren und bereinigen Sie den Cassandra-Knoten.
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 Startknoten im Rechenzentrum nacheinander.
7. Wiederholen Sie die oben genannten Schritte für alle verbleibenden Cassandra-Knoten im Rechenzentrum.
8. Erstellen Sie die Knoten nacheinander im vorhandenen funktionsfähigen Rechenzentrum neu.
9. Starten Sie alle edge-*-Komponenten im Rechenzentrum neu, die mit Cassandra verbunden sind.
10. Testen Sie den Traffic und leiten Sie ihn zurück an dieses Rechenzentrum weiter.
11. Wiederholen Sie die Schritte für jedes Rechenzentrum einzeln.

Detaillierte Schritte

1. Wählen Sie ein Rechenzentrum aus, in dem alle oder einige Cassandra-Knoten aktualisiert werden. Leiten Sie den gesamten Laufzeit-Proxy- und Verwaltungsverkehr von diesem Rechenzentrum weiter, 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 ausgefallen sind, beheben Sie das Problem und starten Sie die Knoten neu, 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 wird beispielsweise eine Instanz eines Clusters mit zwei Rechenzentren gezeigt, in dem alle Knoten von DC-1 Cassandra-Version 4 verwenden, während alle Knoten von DC-2 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:
       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. Seedknoten im Rechenzentrum identifizieren:Weitere Informationen finden Sie im Anhang im Abschnitt Seedknoten identifizieren. Führen Sie die folgenden Schritte auf einem der Startknoten aus:
3. Beenden, deinstallieren und Daten aus dem Cassandra-Knoten entfernen Wählen Sie den ersten Startknoten 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 nehmen Sie einige Konfigurationen vor. Führen Sie die Bootstrap-Datei von Edge für Private Cloud 4.52.02 aus.

# 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
    

Cassandra-Konfigurationen festlegen

1. Erstellen oder bearbeiten Sie die Datei /opt/apigee/customer/application/cassandra.properties.
2. Fügen Sie der Datei den folgenden Inhalt hinzu. ipOfNode ist die IP-Adresse des Knotens, über den Cassandra mit anderen Cassandra-Knoten kommuniziert:

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

3. Achten Sie darauf, dass der apigee-Nutzer Inhaber der Datei ist und sie lesen kann:

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

4. Installieren und einrichten Sie Cassandra:
   • Installieren Sie Cassandra-Version 3.11.X:

     /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra install

   • Richten Sie Cassandra ein, indem Sie die Standardkonfigurationsdatei übergeben:

     /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra setup -f configFile

   • Prüfen Sie, ob Cassandra 3.11.X installiert und der Dienst ausgeführt wird:

     /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra version

     /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra status

5. 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) melden:

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

6. Entfernen Sie die zuvor hinzugefügten zusätzlichen Konfigurationen aus der Datei /opt/apigee/customer/application/cassandra.properties.
7. Wiederholen Sie die Schritte 3 bis 6 nacheinander auf allen Cassandra-Seed-Knoten im Rechenzentrum.
8. Wiederholen Sie die Schritte 3 bis 6 nacheinander auf allen verbleibenden Cassandra-Knoten im Rechenzentrum.
9. Alle Knoten im Rechenzentrum aus einem Rechenzentrum mit der älteren Cassandra-Version neu erstellen. 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. Sie können die streamingthroughput bei Bedarf anpassen. Prüfen Sie den Status mit:

   /opt/apigee/apigee-cassandra/bin/nodetool netstats

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

11. Validieren Sie den Traffic und leiten Sie ihn zurück an dieses Rechenzentrum weiter. Führen Sie einige Validierungen für den Laufzeit-Traffic und die Verwaltungs-APIs in diesem Rechenzentrum durch und leiten Sie den Proxy- und Verwaltungs-API-Traffic wieder dorthin weiter.
12. Wiederholen Sie die oben genannten Schritte für jedes Rechenzentrum, das Sie rückgängig machen möchten.

Cassandra mithilfe eines Back-ups rückgängig machen

Vorbereitung

1. Sie führen ein Upgrade von Cassandra von Version 3.11.X auf Version 4.0.X durch und haben dabei Probleme festgestellt.
2. Sie haben Sicherungen für den Knoten, für den Sie ein Rollback durchführen. Die Sicherung wurde vor dem Upgrade von 3.11.X auf 4.0.X erstellt.

Schritte

1. Wählen Sie einen Knoten aus, den Sie rückgängig machen möchten. Wenn Sie alle Knoten in einem Rechenzentrum mithilfe von Sicherungen rückgängig machen, beginnen Sie zuerst mit den Startknoten. Weitere Informationen finden Sie im Anhang im Abschnitt „Startknoten identifizieren“.

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

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
   

   • So 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 der Inhaber der Datei der apigee-Nutzer ist und dass sie 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 Back-up 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 mithilfe von Sicherungen rückgängig machen möchten.

8. Sobald alle Cassandra-Knoten wiederhergestellt sind, starten Sie alle edge-*-Komponenten 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
           

Sicherungsoptimierungen (erweiterte Option)

Wenn Sie Repliken mit den neuesten Daten haben, können Sie Datenverluste beim Wiederherstellen von Sicherungen minimieren oder vermeiden. Wenn Replikatdateien verfügbar sind, führen Sie nach der Wiederherstellung der Sicherung eine Reparatur am wiederhergestellten Knoten aus.

Anhang

Startknoten 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 Startknoten. Im folgenden Beispiel sind DC-1-IP1, DC-1-IP2, DC-2-IP1 und DC-2-IP2 die IP-Adressen der Startknoten:

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 auf einen vorherigen Haupt- oder Nebenrelease durchführen

Wenn Sie zu einer früheren Haupt- oder Minor-Version zurückkehren möchten, führen Sie auf jedem Knoten, auf dem die Komponente gehostet wird, die folgenden Schritte aus:

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

   • Wenn Sie zu 4.52.02 zurückkehren möchten, laden Sie bootstrap_4.52.02.sh herunter:

     curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh 

2. Beenden Sie die Komponente, um ein Rollback durchzuführen:
   1. Wenn Sie eine der Komponenten mit gemeinsamem Code auf dem Knoten rückgängig machen möchten, müssen Sie sie alle anhalten, wie das folgende Beispiel zeigt:

      /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 rückgängig machen möchten, beenden Sie nur diese Komponente:

      /opt/apigee/apigee-service/bin/apigee-service component stop

3. Wenn Sie die Monetarisierung rückgängig machen möchten, deinstallieren Sie sie auf allen Management-Server- und Message-Processor-Knoten:

   /opt/apigee/apigee-service/bin/apigee-service edge-mint-gateway uninstall

4. Deinstallieren Sie die Komponente, um den Knoten rückgängig zu machen:
   1. Wenn Sie eine der Komponenten mit gemeinsamem Code auf dem Knoten rückgängig machen möchten, müssen Sie alle Komponenten entfernen, indem Sie die edge-gateway-Komponentengruppe deinstallieren, wie im folgenden Beispiel gezeigt:

      /opt/apigee/apigee-service/bin/apigee-service edge-gateway uninstall

   2. Wenn Sie eine andere Komponente auf dem Knoten rückgängig machen 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.

   3. Wenn Sie den Edge-Router rücksetzen möchten, müssen Sie nicht nur die edge-gateway-Komponentengruppe deinstallieren, sondern auch den Inhalt der Datei /opt/nginx/conf.d löschen:

      cd /opt/nginx/conf.d
      rm -rf *

5. Deinstallieren Sie die Version 4.53.00 von apigee-setup:

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

6. Installieren Sie die Version 4.52.02 des apigee-service-Dienstprogramms und die zugehörigen Abhängigkeiten. Im folgenden Beispiel wird die Version 4.52.02 der 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. apigee-setup installieren:

   /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 die Konfigurationsdatei für die ältere Version.

9. Wenn Sie Qpid rückgängig machen, leeren Sie iptables:

   sudo iptables -F

10. Wiederholen Sie diesen Vorgang für jeden Knoten, auf dem die Komponente gehostet wird, die Sie rückgängig machen möchten.

Rollback auf einen vorherigen Patch-Release durchführen

Wenn Sie eine Komponente auf einen bestimmten Patch-Release zurücksetzen möchten, gehen Sie auf jedem Knoten, auf dem die Komponente gehostet wird, so vor:

1. Laden Sie die entsprechende Komponentenversion herunter:

   /opt/apigee/apigee-service/bin/apigee-service component_version install

   Dabei ist component_version die zu installierende Komponente und Patch-Version. Beispiel:

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

   Wenn Sie das Apigee-Online-Repository verwenden, können Sie die verfügbaren Komponentenversionen mit dem folgenden Befehl ermitteln:

   yum --showduplicates list comp

   Beispiel:

   yum --showduplicates list edge-ui

2. Verwenden Sie apigee-setup, um die Komponente zu installieren:

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

   Beispiel:

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

   Beachten Sie, dass Sie bei der Installation nur den Komponentennamen und nicht die Version angeben.

3. Wiederholen Sie diesen Vorgang für jeden Knoten, auf dem die Komponente gehostet wird, die Sie rückgängig machen möchten.

mTLS rückgängig machen

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

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