Wycofanie wersji Apigee Edge 4.53.00

Jeśli podczas aktualizacji do wersji Edge 4.53.00 wystąpi błąd, możesz cofnąć zmianę komponentu, który spowodował błąd, a następnie ponownie spróbować przeprowadzić aktualizację.

Możesz przywrócić Edge 4.53.00 do tej wersji:

  • Wersja 4.52.02

Przywracanie wersji obejmuje przywrócenie wszystkich komponentów, które zostały ulepszone. Dodatkowo podczas przywracania Cassandra do wersji 4.52.02 należy wziąć pod uwagę kilka kwestii.

Możesz wykonać cofnięcie zmian w 2 sytuacjach:

  1. Przywróć poprzednią wersję główną lub podrzędną. Na przykład z 4,53,00 na 4,52,02.
  2. Przywróć poprzednią wersję poprawki w ramach tej samej wersji. Na przykład z 4.53.00.01 na 4.53.00.00.

Więcej informacji znajdziesz w artykule Proces publikowania Apigee Edge.

Kolejność przywracania

Przywracanie komponentów powinno odbywać się w odwrotnej kolejności, w jakiej zostały one uaktualnione, z tym wyjątkiem, że serwery zarządzania powinny zostać przywrócone po Cassandra.

Typowa kolejność odzyskiwania w przypadku Private Cloud 4.53.00 będzie wyglądać tak:

  1. wycofanie serwera Postgres, Qpid i innych komponentów związanych z analizą;
  2. Przywracanie routerów i procesorów wiadomości
  3. Cofnięcie zmian w Cassandra i Zookeeper
  4. Serwer zarządzania rollbackiem

Załóżmy na przykład, że zaktualizowano cały klaster Cassandra, wszystkie serwery zarządzające i kilka usług RMP z wersji 4.52.02 do wersji 4.53.00 i chcesz cofnąć tę zmianę. W takim przypadku:

  1. Przywracanie wszystkich RMP pojedynczo
  2. Przywróć cały klaster Cassandra za pomocą kopii zapasowych.
  3. Cofnięty rollback węzłów serwera Edge Management

Kto może cofnąć zmiany

Użytkownik wykonujący wycofanie powinien być tym samym użytkownikiem, który pierwotnie zaktualizował Edge, lub użytkownikiem działającym jako root.

Domyślnie komponenty Edge działają jako użytkownik „apigee”. W niektórych przypadkach komponenty Edge mogą być uruchamiane jako różne użytkownicy. Jeśli na przykład Router musi uzyskać dostęp do portów uprzywilejowanych, takich jak te poniżej 1000, musisz uruchomić Router jako root lub jako użytkownik z dostępem do tych portów. Możesz też uruchomić jeden komponent jako jeden użytkownik, a inny jako inny użytkownik.

Komponenty z kodem wspólnym

Te komponenty Edge korzystają z wspólnego kodu. Dlatego aby cofnąć zmiany w dowolnym z tych komponentów na węźle, musisz cofnąć zmiany we wszystkich komponentach na tym węźle.

  • edge-management-server (serwer zarządzania)
  • edge-message-processor (procesor komunikatów)
  • edge-router (Router)
  • edge-postgres-server (serwer Postgres)
  • edge-qpid-server (Qpid Server)

Jeśli na przykład masz na węźle zainstalowane serwer zarządzania, router i przetwarzacz wiadomości, aby cofnąć zmiany w jednym z nich, musisz cofnąć zmiany we wszystkich trzech.

Wycofanie Cassandra

Wycofanie Cassandra

Gdy na określonym węźle zostanie przeprowadzona duża aktualizacja Cassandra, Cassandra zmodyfikuje schemat danych przechowywanych na tym węźle. W związku z tym nie można przywrócić zmian bezpośrednio na miejscu.

Scenariusze przywracania

Cassandra 4.0.X, dostępna z Edge for Private Cloud 4.53.00, jest zgodna z innymi komponentami Private Cloud 4.52.02.

W tabeli poniżej znajdziesz podsumowanie różnych strategii przywracania, których możesz użyć:

Scenariusz Strategia cofnięcia
Pojedynczy DC, niektóre węzły Cassandra zostały uaktualnione Używanie kopii zapasowych
Pojedynczy DC, wszystkie węzły Cassandra zostały uaktualnione Nie przywracaj Cassandra. Inne komponenty można cofnąć.
Pojedyncza lokalizacja, wszystkie węzły (Cassandra i inne) zostały uaktualnione Nie przywracaj Cassandra. Inne komponenty można cofnąć.
Wiele węzłów, niektóre węzły w jednym węźle zaktualizowane Odtworzenie z dotychczasowego DC
Wiele serwerów, wszystkie węzły Cassandra w niektórych serwerach zostały zaktualizowane Odtworzenie z dotychczasowego DC
Wiele węzłów DC, węzły Cassandra ostatniego węzła DC są uaktualniane Spróbuj dokończyć uaktualnianie. Jeśli nie jest to możliwe, przywróć 1 DC za pomocą kopii zapasowej. Odbuduj pozostałe węzły danych na podstawie wycofanego węzła danych.
Wiele DC, wszystkie węzły Cassandra zostały zaktualizowane Nie przywracaj Cassandra. Inne komponenty można cofnąć.
Wiele klastrów, wszystkie węzły (Cassandra i inne) zostały ulepszone Nie przywracaj Cassandra. Inne komponenty można cofnąć.

Uwagi ogólne

Jeśli rozważasz wycofanie zmian, pamiętaj o tych kwestiach:

  • Cofnięcie zmian komponentów zarządzających lub komponentów środowiska wykonawczego: jeśli chcesz cofnąć zmiany komponentów takich jak edge-management-server, edge-message-processor lub dowolnego komponentu innego niż Cassandra do wersji 4.52.02 chmury prywatnej, zalecamy, aby NIE cofać zmian Cassandra. Cassandra dostarczana z Private Cloud 4.53.00 jest zgodna ze wszystkimi komponentami Edge for Private Cloud 4.52.02, które nie są związane z Cassandra. Możesz cofnąć zmiany w komponentach innych niż Cassandra, korzystając z metody opisanej tutaj, przy czym Cassandra pozostaje w wersji 4.0.13.
  • Cofnięcie zmian po uaktualnieniu całego klastra Cassandra do wersji 4.0.X: jeśli cały klaster Cassandra został uaktualniony do wersji 4.0.X w ramach uaktualnienia do wersji 4.53.00 chmury prywatnej, zalecamy kontynuowanie konfiguracji tego klastra i NIE cofanie zmian w Cassandra. Komponenty takie jak edge-management-server, edge-message-processor, edge-router itp. w wersji Private Cloud 4.52.02 są zgodne z wersją Cassandra 4.0.X.
  • Cofnięcie zmian w Cassandra podczas uaktualniania Cassandra: jeśli podczas uaktualniania Cassandra napotkasz problemy, możesz rozważyć cofnięcie zmian. Strategii odzyskiwania wymienionych w tym artykule możesz używać w zależności od stanu, w jakim znajdujesz się w trakcie procesu uaktualniania.
  • Cofnięcie zmian za pomocą kopii zapasowych: kopie zapasowe z Cassandra 4.0.X nie są zgodne z kopiami zapasowymi z Cassandra 3.11.X. Aby cofnąć zmiany w Cassandra za pomocą przywrócenia kopii zapasowej, przed uaktualnieniem musisz utworzyć kopię zapasową Cassandra 3.11.X.

Przywracanie Cassandra za pomocą funkcji odbudowy

Wymagania wstępne

  • Używasz klastra Edge for Private Cloud 4.52.02 w wielu centrach danych.
  • Przechodzisz na wersję Cassandra 4.0.X z wersji 3.11.X i napotykasz problemy podczas aktualizacji.
  • W klastrze masz co najmniej 1 w pełni sprawne centrum danych, w którym nadal działa starsza wersja Cassandra (Cassandra 3.11.X).

Ta procedura polega na przesyłaniu strumieniowym danych z dotychczasowego centrum danych. Może to zająć sporo czasu, w zależności od ilości danych przechowywanych w Cassandra. Podczas cofania zmian musisz być przygotowany na przekierowanie ruchu z czasu wykonywania z tego centrum danych.

Najważniejsze kroki

  1. Wybierz jedno centrum danych (częściowo lub całkowicie zaktualizowane), które chcesz przywrócić. Przekieruj ruch w czasie wykonywania do innego działającego centrum danych.
  2. Zidentyfikuj węzeł początkowy w centrum danych i zacznij od jednego z węzłów początkowych.
  3. Zatrzymaj, odinstaluj i wyczyść węzeł Cassandra.
  4. Zainstaluj na węźle starszą wersję Cassandra i w razie potrzeby skonfiguruj ją.
  5. Usuń dodatkowe konfiguracje, które zostały dodane wcześniej.
  6. Powtórz te czynności w przypadku wszystkich węzłów początkowych w centrum danych, po jednym.
  7. Powtórz powyższe czynności w przypadku wszystkich pozostałych węzłów Cassandra w danym centrum danych, po jednym.
  8. Pojedynczo odtwarzaj węzły z dotychczasowego, działającego centrum danych.
  9. Zrestartuj wszystkie komponenty edge-* w centrum danych, które są połączone z Cassandra.
  10. Przetestuj i przekieruj ruch z powrotem do tego centrum danych.
  11. Powtórz te czynności w przypadku każdego centrum danych.

Szczegółowe instrukcje

  1. Wybierz jedno centrum danych, w którym wszystkie lub niektóre węzły Cassandra zostaną zaktualizowane. Odsyłanie z tego centrum danych całego ruchu proxy i ruchu związanego z zarządzaniem, gdy węzły Cassandra w tym centrum danych są cofane. Upewnij się, że wszystkie węzły Cassandra są w stanie UN (Up/Normal), gdy na tych węzłach wykonywane jest polecenie nodetool ring. Jeśli niektóre węzły są niedostępne, rozwiąż problem i uruchom je ponownie, zanim przejdziesz dalej.

    Zobacz ten przykład:

    /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
    

    Aby poznać bieżący stan całego klastra, możesz uruchomić na węzłach polecenie nodetool describecluster. Na przykład poniższy przykład pokazuje instancję klastra z 2 centrami danych, w której wszystkie węzły DC-1 są na wersji 4 Cassandra, a wszystkie węzły DC-2 są na wersji 3 Cassandra:

    # 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. Znajdź węzły początkowe w centrum danych: w Appendiksie przeczytaj sekcję Jak znaleźć węzły początkowe. Wykonaj te czynności na jednym z węzłów początkowych:
  3. Zatrzymaj, odinstaluj i usuń dane z węzła Cassandra. Wybierz pierwszy węzeł początkowy w Cassandra w wersji 4 w tym centrum danych. Przestań.
    # 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. Zainstaluj na węźle starsze oprogramowanie Cassandra i skonfiguruj niektóre ustawienia. Uruchom plik bootstrap Edge for Private Cloud 4.52.02.
  5. # Download bootstrap of 4.52.02
    curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh -u uName:pWord
    
    # Execute bootstrap of 4.52.02
    sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord
        

Konfigurowanie ustawień Cassandra

  1. Utwórz lub zmodyfikuj plik /opt/apigee/customer/application/cassandra.properties.
  2. Dodaj do pliku te treści: ipOfNode to adres IP węzła, którego Cassandra używa do komunikacji z innymi węzłami Cassandra:
    conf_jvm_options_custom_settings=-Dcassandra.replace_address=ipOfNode -Dcassandra.allow_unsafe_replace=true
  3. Upewnij się, że plik należy do użytkownika apige i jest przez niego czytelny:
    chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
  4. Instalowanie i konfigurowanie Cassandra:
    • Zainstaluj Cassandra w wersji 3.11.X:
      /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra install
    • Skonfiguruj Cassandra, przekazując standardowy plik konfiguracji:
      /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra setup -f configFile
    • Upewnij się, że zainstalowana jest Cassandra 3.11.X i usługa działa:
      /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra version
      /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra status
  5. Sprawdź, czy węzeł został uruchomiony. Uruchom to polecenie na tym węźle i na innych węzłach w klastrze. Węzeł powinien zgłaszać, że jest w stanie „UN” (włączony/normalny):
    /opt/apigee/apigee-cassandra/bin/nodetool status
  6. Usuń z pliku /opt/apigee/customer/application/cassandra.properties dodatkowe konfiguracje dodane wcześniej.
  7. Powtórz kroki 3–6 w przypadku wszystkich węzłów początkowych Cassandra w danym centrum danych (po kolei).
  8. Powtórz kroki 3–6 w przypadku wszystkich pozostałych węzłów Cassandra w danym centrum danych, po kolei.
  9. Odbuduj wszystkie węzły w centrum danych z centrum danych, w którym działa starsza wersja Cassandra. Wykonuj ten krok dla każdego węzła osobno:
    /opt/apigee/apigee-cassandra/bin/nodetool rebuild -dc <name of working DC>
    Ta procedura może trochę potrwać. W razie potrzeby możesz dostosować streamingthroughput. Sprawdź stan za pomocą:
    /opt/apigee/apigee-cassandra/bin/nodetool netstats
  10. Po kolei uruchamiaj wszystkie komponenty edge-* w centrum danych:
    /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. Zweryfikuj i przekieruj ruch z powrotem do tego centrum danych. Przeprowadź w tym centrum danych weryfikację interfejsów API do zarządzania i interfejsów API do zarządzania ruchem. Następnie zacznij przekierowywać ruch do serwera proxy i do interfejsów API do zarządzania.
  12. Powtórz te czynności w przypadku każdego centrum danych, które chcesz cofnąć.

Przywracanie Cassandra przy użyciu kopii zapasowej

Wymagania wstępne

  1. Przechodzisz na wersję Cassandra 4.0.X z wersji 3.11.X i napotykasz problemy podczas aktualizacji.
  2. Masz kopie zapasowe węzła, którego dotyczy wycofanie. Kopie zapasowe zostały utworzone przed próbą uaktualnienia z wersji 3.11.X do 4.0.X.

Kroki

  1. Wybierz jeden węzeł, który chcesz cofnąć. Jeśli przywracasz wszystkie węzły w centrum danych, korzystając z kopii zapasowych, zacznij od węzłów początkowych. W załączniku zapoznaj się z sekcją „Jak zidentyfikować węzły początkowe”.

  2. Zatrzymaj, odinstaluj i oczyść węzeł Cassandra:

    # Stop Cassandra service on the node
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop
    
    # Uninstall Cassandra software
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra uninstall
    
    # Wipe Cassandra data
    rm -rf /opt/apigee/data/apigee-cassandra
    
  3. Zainstaluj na węźle starsze oprogramowanie Cassandra i skonfiguruj je:

    • Uruchom plik bootstrap Edge for Private Cloud 4.52.02:
    • # Download bootstrap for 4.52.02
      curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh -u ‘uName:pWord’
      
      # Execute bootstrap for 4.52.02
      sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord
      
    • Utwórz lub zmodyfikuj plik /opt/apigee/customer/application/cassandra.properties:
    • conf_jvm_options_custom_settings=-Dcassandra.replace_address=ipOfNode -Dcassandra.allow_unsafe_replace=true
    • Upewnij się, że plik należy do użytkownika apigee i jest czytelny:
    • chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
    • Instalowanie i konfigurowanie Cassandra:
    • # Install Cassandra version 3.11.X
      /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra install
      
      # Set up Cassandra with the standard configuration file
      /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra setup -f configFile
      
      # Verify Cassandra version and check service status
      /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra version
      /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra status
      

    Sprawdź, czy węzeł został uruchomiony. Uruchom to polecenie na tym węźle i na innych węzłach w klastrze. Węzły powinny zgłaszać, że ten węzeł jest w stanie „UN”:

    /opt/apigee/apigee-cassandra/bin/nodetool status
  4. Zatrzymaj usługę Cassandra i przywróć kopię zapasową. Więcej informacji znajdziesz w dokumentacji kopii zapasowych i przywracania:

    # 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. Po przywróceniu kopii zapasowej usuń dodatkowe konfiguracje:

    Usuń z pliku /opt/apigee/customer/application/cassandra.properties konfigurację dodaną wcześniej.

  6. Uruchom usługę Cassandra na węźle:

    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra start
  7. Powtórz te czynności w przypadku każdego węzła Cassandra, którego chcesz cofnąć do poprzedniego stanu, używając kopii zapasowych.

  8. Po przywróceniu wszystkich węzłów Cassandra ponownie uruchom wszystkie komponenty edge-* jeden po drugim:

    /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
            

Optymalizacje kopii zapasowych (opcja zaawansowana)

Jeśli masz dostępne repliki zawierające najnowsze dane, możesz zminimalizować (lub wyeliminować) utratę danych podczas przywracania kopii zapasowych. Jeśli repliki są dostępne, po przywróceniu kopii zapasowej przeprowadź naprawę przywróconego węzła.

Dodatek

Jak zidentyfikować węzły początkowe

Na dowolnym węźle Cassandra w centrum danych uruchom to polecenie:

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

Polecenie wygeneruje kilka wierszy. Znajdź ostatni wiersz danych wyjściowych. Adresy IP wymienione w ostatnim wierszu to węzły początkowe. W przykładzie poniżej adresy IP węzłów początkowych to DC-1-IP1, DC-1-IP2, DC-2-IP1DC-2-IP2:

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

przywrócić poprzednią wersję główną lub podrzędną,

Aby przywrócić poprzednią główną lub pomocniczą wersję, wykonaj te czynności w każdym węźle, który hostuje komponent:

  1. Pobierz plik bootstrap.sh dla wersji, do której chcesz przywrócić:

    • Aby przywrócić wersję 4.52.02, pobierz bootstrap_4.52.02.sh:
      curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh 
  2. Zatrzymaj komponent, aby cofnąć zmiany:
    1. Aby cofnąć dowolny z komponentów z kodem wspólnym w węźle, musisz je wszystkie zatrzymać, jak pokazano w tym przykładzie:
      /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. Aby cofnąć dowolny inny komponent na węźle, zatrzymaj tylko ten komponent:
      /opt/apigee/apigee-service/bin/apigee-service component stop
  3. Jeśli chcesz przywrócić poprzednią wersję funkcji Monetyzacja, odinstaluj ją ze wszystkich węzłów serwera zarządzania i procesora wiadomości:
    /opt/apigee/apigee-service/bin/apigee-service edge-mint-gateway uninstall
  4. Odinstaluj komponent, aby cofnąć zmiany na węźle:
    1. Aby wycofać dowolny z komponentów z kodem wspólnym w węźle, musisz odinstalować wszystkie komponenty, odinstalowując grupę komponentów edge-gateway, jak pokazano w tym przykładzie:
      /opt/apigee/apigee-service/bin/apigee-service edge-gateway uninstall
    2. Aby wycofać inny komponent w węźle, odinstaluj tylko ten komponent, jak w tym przykładzie:
      /opt/apigee/apigee-service/bin/apigee-service component uninstall

      Gdzie component to nazwa komponentu.

    3. Aby przywrócić Edge Router, musisz usunąć zawartość pliku /opt/nginx/conf.d, a także odinstalować grupę komponentów edge-gateway:
      cd /opt/nginx/conf.d
      rm -rf *
  5. Odinstaluj wersję apigee-setup 4.53.00:
    /opt/apigee/apigee-service/bin/apigee-service apigee-setup uninstall
  6. Zainstaluj wersję 4.52.02 narzędzia apigee-service i jego zależności. W tym przykładzie instalowana jest wersja 4.52.02 aplikacji apigee-service:
    sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord

    Gdzie uNamepWord to nazwa użytkownika i hasło otrzymane z Apigee. Jeśli pominiesz pWord, pojawi się prośba o jego podanie.

    Jeśli pojawi się błąd, sprawdź, czy plik bootstrap.sh został pobrany w kroku 1.

  7. Zainstaluj apigee-setup:
    /opt/apigee/apigee-service/bin/apigee-service apigee-setup install
  8. Zainstaluj starszą wersję komponentu:
    /opt/apigee/apigee-setup/bin/setup.sh -p component -f configFile

    Gdzie component to komponent do zainstalowania, a configFile to plik konfiguracji starszej wersji.

  9. Jeśli cofasz Qpid, opróżnij iptables:
    sudo iptables -F
  10. Powtórz tę procedurę dla każdego węzła, który hostuje komponent, który chcesz cofnąć.

Przywróć poprzednią wersję poprawki

Aby przywrócić komponent do konkretnej wersji poprawki, wykonaj te czynności na każdym węźle, na którym jest on hostowany:

  1. Pobierz wersję konkretnego komponentu:
    /opt/apigee/apigee-service/bin/apigee-service component_version install

    Gdzie component_version to wersja komponentu i łatki do zainstalowania. Przykład:

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

    Jeśli korzystasz z repozytorium internetowego Apigee, możesz określić dostępne wersje komponentów za pomocą tego polecenia:

    yum --showduplicates list comp

    Na przykład:

    yum --showduplicates list edge-ui
  2. Aby zainstalować komponent, użyj apigee-setup:
    /opt/apigee/apigee-setup/bin/setup.sh -p comp -f configFile

    Na przykład:

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

    Pamiętaj, że podczas instalacji podajesz tylko nazwę komponentu, a nie jego wersję.

  3. Powtórz tę procedurę dla każdego węzła, który hostuje komponent, który chcesz cofnąć.

Przywracanie mTLS

Aby cofnąć aktualizację mTLS, wykonaj te czynności na wszystkich hostach:

  1. Zatrzymaj Apigee:
    apigee-all stop
  2. Zatrzymanie mTLS:
    apigee-service apigee-mtls uninstall
  3. Ponownie zainstaluj mTLS:
    apigee-service apigee-mtls install
    apigee-service apigee-mtls setup -f /opt/silent.conf