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, zurücksetzen und das Update dann noch einmal versuchen.

Sie können ein Rollback von Edge 4.53.00 auf die folgende Nebenversionsnummer durchführen:

  • Version 4.52.02

Beim Rollback einer Version wird jede Komponente zurückgesetzt, die Sie möglicherweise aktualisiert haben. Außerdem sollten Sie beim Downgrade von Cassandra auf Version 4.52.02 besondere Aspekte berücksichtigen.

Es gibt zwei Szenarien, in denen Sie möglicherweise ein Rollback durchführen möchten:

  1. Rollback zu einem vorherigen Haupt- oder Nebenrelease durchführen Beispiel: von 4.53.00 auf 4.52.02.
  2. Rollback zu einem früheren Patch-Release im selben Release durchführen: Zum Beispiel von 4.53.00.01 zu 4.53.00.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.00 sieht so aus:

  1. Postgres, Qpid und andere analysebezogene Komponenten zurücksetzen
  2. Router und Message Processors zurücksetzen
  3. Cassandra und Zookeeper zurücksetzen
  4. Rollback des Verwaltungsservers

Angenommen, Sie haben den gesamten Cassandra-Cluster, alle Verwaltungsserver und einige RMPs von Version 4.52.02 auf Version 4.53.00 aktualisiert und möchten das Upgrade rückgängig machen. In diesem Fall gehen Sie so vor:

  1. Alle RMPs einzeln zurücksetzen
  2. Gesamten Cassandra-Cluster mithilfe von Back-ups zurücksetzen
  3. 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

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.00 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: 
    # 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 zu einem vorherigen Haupt- oder Nebenrelease durchführen

So führen Sie ein Rollback zu einem früheren Haupt- oder Nebenrelease durch:

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

    • Wenn Sie ein Rollback auf Version 4.52.02 durchführen 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. 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 Komponenten deinstallieren, indem Sie die Komponentengruppe edge-gateway deinstallieren. Das folgende Beispiel zeigt, wie das geht: 
      /opt/apigee/apigee-service/bin/apigee-service edge-gateway 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.00 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.

Rollback zu einem vorherigen Patch-Release durchführen

So machen Sie ein Rollback einer Komponente auf einen bestimmten Patch-Release auf jedem Knoten, auf dem die Komponente gehostet wird:

  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-Onlinerepo 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 angeben, nicht die Version.

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