Ta strona została przetłumaczona przez Cloud Translation API.

Wycofanie wersji Apigee Edge 4.53.00

Jeśli podczas aktualizacji do wersji Edge 4.53.00 wystąpi błąd, możesz wycofać komponent, który go spowodował, a potem ponownie spróbować przeprowadzić aktualizację.

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

Wersja 4.52.02

Cofnięcie wersji polega na cofnięciu wszystkich komponentów, które mogły zostać uaktualnione. Dodatkowo podczas przywracania Cassandry do wersji 4.52.02 należy wziąć pod uwagę specjalne kwestie.

Cofnięcie zmian może być przydatne w 2 sytuacjach:

Przywróć poprzednią wersję główną lub pomocniczą. Na przykład z 4.53.00 na 4.52.02.
Przywróć poprzednią wersję poprawki w tej samej wersji. Na przykład z 4.53.00.01 na 4.53.00.00.

Więcej informacji znajdziesz w artykule Proces wydawania wersji Apigee Edge.

Kolejność wycofywania

Przywracanie poprzedniej wersji komponentów powinno odbywać się w odwrotnej kolejności niż uaktualnianie, z wyjątkiem serwerów zarządzających, które należy przywrócić po bazie danych Cassandra.

Typowa ogólna kolejność wycofywania zmian w przypadku chmury prywatnej w wersji 4.53.00 wygląda tak:

Cofanie zmian w przypadku Postgresa, Qpid i innych komponentów związanych z analityką
Przywracanie routerów i procesorów komunikatów
Cofanie zmian w przypadku Cassandra i Zookeeper
Przywracanie serwera zarządzania

Załóżmy, że cały klaster Cassandra, wszystkie serwery zarządzania i kilka modułów RMP zostało uaktualnionych z wersji 4.52.02 do wersji 4.53.00 i chcesz przywrócić poprzednią wersję. W takim przypadku:

Cofanie wszystkich RMP pojedynczo
Przywracanie całego klastra Cassandra za pomocą kopii zapasowych
Przywracanie węzłów serwera zarządzania brzegowego pojedynczo

Kto może cofnąć zmiany

Użytkownik, który przywraca poprzednią wersję, 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 przez różnych użytkowników. Jeśli np. router musi mieć dostęp do portów uprzywilejowanych, takich jak porty poniżej 1000, musisz uruchomić go jako roota lub jako użytkownika z dostępem do tych portów. Możesz też uruchomić jeden komponent jako jeden użytkownik, a inny komponent jako inny użytkownik.

Komponenty ze wspólnym kodem

Te komponenty Edge korzystają ze wspólnego kodu. Dlatego, aby wycofać dowolny z tych komponentów na węźle, musisz wycofać wszystkie komponenty znajdujące się na tym węźle.

edge-management-server (serwer zarządzający)
edge-message-processor (procesor komunikatów)
edge-router (router)
edge-postgres-server (serwer Postgres)
edge-qpid-server (serwer Qpid)

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

Wycofanie zmian w Cassandrze

Gdy na konkretnym węźle przeprowadzana jest główna aktualizacja Cassandry, modyfikuje ona schemat danych przechowywanych na tym węźle. W związku z tym bezpośrednie przywrócenie w miejscu nie jest możliwe.

Scenariusze wycofywania

Cassandra 4.0.X, dostępna w 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 wycofywania zmian, których możesz użyć:

Scenariusz	Strategia wycofywania
Pojedyncze centrum danych, niektóre węzły Cassandra zostały uaktualnione	Korzystanie z kopii zapasowych
Pojedyncze centrum danych, wszystkie węzły Cassandra uaktualnione	Nie przywracaj poprzedniej wersji Cassandra. Inne komponenty można przywrócić.
Pojedyncze centrum danych, wszystkie węzły (Cassandra i inne) uaktualnione	Nie przywracaj poprzedniej wersji Cassandra. Inne komponenty można przywrócić.
Wiele centrów danych, niektóre węzły w jednym centrum danych zostały zaktualizowane	Odtwórz z istniejącego DC
Wiele centrów danych, wszystkie węzły Cassandra w niektórych centrach danych zostały uaktualnione	Odtwórz z istniejącego DC
Wiele centrów danych, węzły Cassandra ostatniego centrum danych są uaktualniane	Spróbuj dokończyć uaktualnianie. Jeśli to niemożliwe, przywróć 1 centrum danych z kopii zapasowej. Odbuduj pozostałe kontrolery domeny z wycofanego kontrolera domeny.
Wiele centrów danych, wszystkie węzły Cassandra zaktualizowane	Nie przywracaj poprzedniej wersji Cassandra. Inne komponenty można przywrócić.
Wiele centrów danych, wszystkie węzły (Cassandra i inne) zaktualizowane	Nie przywracaj poprzedniej wersji Cassandra. Inne komponenty można przywrócić.

Uwagi ogólne

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

Cofanie zmian w komponentach środowiska wykonawczego lub zarządzania: jeśli chcesz cofnąć zmiany w komponentach takich jak edge-management-server, edge-message-processor lub dowolny komponent inny niż Cassandra do wersji chmury prywatnej 4.52.02, nie cofaj zmian w Cassandrze. Cassandra dostarczana z chmurą prywatną w wersji 4.53.00 jest zgodna ze wszystkimi komponentami Edge for Private Cloud w wersji 4.52.02, które nie są komponentami Cassandra. Możesz wycofać komponenty inne niż Cassandra, korzystając z metodologii podanej tutaj, podczas gdy Cassandra pozostanie w wersji 4.0.13.
Wycofanie zmian po uaktualnieniu całego klastra Cassandra do wersji 4.0.X: jeśli cały klaster Cassandra zostanie uaktualniony do wersji 4.0.X w ramach uaktualnienia do wersji 4.53.00 chmury prywatnej, zalecamy kontynuowanie konfiguracji tego klastra i NIE wycofywanie zmian w Cassandrze. Komponenty takie jak edge-management-server, edge-message-processor, edge-router itp. w wersji 4.52.02 chmury prywatnej są zgodne z Cassandrą w wersji 4.0.X.
Cofanie zmian w Cassandrze podczas jej uaktualniania: jeśli podczas uaktualniania Cassandry napotkasz problemy, możesz rozważyć cofnięcie zmian. Strategie wycofywania zmian wymienione w tym artykule można stosować w zależności od stanu, w jakim znajduje się proces uaktualniania.
Cofanie zmian za pomocą kopii zapasowych: kopie zapasowe utworzone w Cassandrze 4.0.X nie są zgodne z kopiami zapasowymi Cassandry 3.11.X. Aby cofnąć zmiany w Cassandrze za pomocą przywracania kopii zapasowej, przed rozpoczęciem uaktualniania musisz utworzyć kopie zapasowe Cassandry 3.11.X.

Przywracanie Cassandra za pomocą ponownego tworzenia

Wymagania wstępne

Używasz klastra Edge for Private Cloud w wersji 4.52.02 w wielu centrach danych.
Uaktualniasz bazę danych Cassandra z wersji 3.11.X do 4.0.X i napotykasz problemy.
W klastrze masz co najmniej 1 w pełni funkcjonalne centrum danych, które nadal działa w starszej wersji Cassandry (Cassandra 3.11.X).

Ta procedura opiera się na przesyłaniu strumieniowym danych z istniejącego centrum danych. Może to zająć sporo czasu, w zależności od ilości danych przechowywanych w Cassandrze. Podczas wycofywania zmian musisz być gotowy na przekierowanie ruchu środowiska wykonawczego z tego centrum danych.

Najważniejsze kroki

Wybierz jedno centrum danych (częściowo lub w pełni zaktualizowane), do którego chcesz przywrócić poprzednią wersję. Przekierowywanie ruchu w czasie działania do innego działającego centrum danych.
Określ węzeł początkowy w centrum danych i zacznij od jednego z węzłów początkowych.
Zatrzymaj, odinstaluj i wyczyść węzeł Cassandra.
Zainstaluj starszą wersję Cassandra na węźle i skonfiguruj ją w razie potrzeby.
Usuń dodatkowe konfiguracje dodane wcześniej.
Powtórz powyższe kroki w przypadku wszystkich węzłów początkowych w centrum danych, jeden po drugim.
Powtórz powyższe kroki w przypadku wszystkich pozostałych węzłów Cassandra w centrum danych, jeden po drugim.
Odtwórz węzły z istniejącego, działającego centrum danych, jeden po drugim.
Uruchom ponownie wszystkie komponenty edge-* w centrum danych, które są połączone z Cassandrą.
Przeprowadź test i przekieruj ruch z powrotem do tego centrum danych.
Powtórz te czynności w przypadku każdego centrum danych, po kolei.

Szczegółowe instrukcje

Wybierz jedno centrum danych, w którym wszystkie lub niektóre węzły Cassandra zostaną uaktualnione. Przekieruj cały ruch związany z proxy w czasie działania i ruch związany z zarządzaniem z tego centrum danych, gdy węzły Cassandra w tym centrum danych są wycofywane. Sprawdź, czy wszystkie węzły Cassandra są w stanie UN (Up/Normal), gdy na węzłach zostanie wykonane polecenie nodetool ring. Jeśli niektóre węzły nie działają, rozwiąż problem i przywróć je przed kontynuowaniem.

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 sprawdzić bieżący stan całego klastra, możesz uruchomić na węzłach polecenie nodetool describecluster. Na przykład poniżej przedstawiamy instancję klastra z 2 centrami danych, w którym wszystkie węzły DC-1 działają w wersji 4 Cassandry, a wszystkie węzły DC-2 – w wersji 3:

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

Określ węzły początkowe w centrum danych: zapoznaj się z sekcją Jak określić węzły początkowe w dodatku. Wykonaj poniższe czynności na jednym z węzłów początkowych:

Zatrzymaj, odinstaluj i wyczyść dane z węzła Cassandra. Wybierz pierwszy węzeł początkowy w Cassandrze 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

Zainstaluj na węźle starsze oprogramowanie Cassandra i skonfiguruj niektóre ustawienia. Uruchom plik bootstrap Edge for Private Cloud 4.52.02.

# 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

Utwórz lub edytuj plik /opt/apigee/customer/application/cassandra.properties.
Dodaj do pliku te wiersze: 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
```
Sprawdź, czy plik jest własnością użytkownika apigee i czy ma on do niego dostęp do odczytu:
```
chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
```

Zainstaluj i skonfiguruj Cassandrę:

# 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

Sprawdź, czy węzeł został uruchomiony. Sprawdź to polecenie w tym węźle i innych węzłach w klastrze. Węzeł powinien zgłosić stan „UN” (Up/Normal):
```
/opt/apigee/apigee-cassandra/bin/nodetool status
```
Usuń z pliku /opt/apigee/customer/application/cassandra.properties dodatkowe konfiguracje dodane wcześniej.
Powtórz kroki od 3 do 10 na wszystkich węzłach początkowych Cassandry w centrum danych, jeden po drugim.
Powtórz kroki 3–10 na wszystkich pozostałych węzłach Cassandra w centrum danych, jeden po drugim.
Odtwórz wszystkie węzły w centrum danych z centrum danych, w którym działa starsza wersja Cassandry. Wykonaj ten krok na każdym węźle z osobna:
```
/opt/apigee/apigee-cassandra/bin/nodetool rebuild -dc <name of working DC>
```
Ta procedura może zająć trochę czasu. W razie potrzeby możesz dostosować streamingthroughput. Sprawdź nodetool netstats, aby poznać stan zakończenia operacji.
(Opcjonalnie) Jeśli dane nie są odbudowywane, wykonaj polecenie naprawy w węźle Cassandra.
```
/opt/apigee/apigee-cassandra/bin/nodetool -h node-IP repair -pr
```

Uruchom ponownie wszystkie komponenty edge-* w centrum danych, 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

Sprawdź i przekieruj ruch z powrotem do tego centrum danych. Przeprowadź w tym centrum danych weryfikację ruchu w czasie działania i interfejsów API do zarządzania, a następnie zacznij przekierowywać do niego ruch serwera proxy i interfejsu API do zarządzania.
Powtórz powyższe kroki dla każdego centrum danych, w którym chcesz cofnąć zmiany.

Przywracanie bazy danych Cassandra za pomocą kopii zapasowej

Wymagania wstępne

Uaktualniasz bazę danych Cassandra z wersji 3.11.X do 4.0.X i napotykasz problemy.
Masz kopie zapasowe węzła, który chcesz przywrócić. Kopia zapasowa została utworzona przed próbą uaktualnienia z wersji 3.11.X do 4.0.X.

Kroki

Wybierz węzeł, do którego chcesz przywrócić poprzednią wersję. Jeśli przywracasz wszystkie węzły w centrum danych za pomocą kopii zapasowych, zacznij od węzłów początkowych. W dodatku znajdziesz sekcję „Jak identyfikować węzły początkowe”.

Zatrzymaj, odinstaluj i wyczyść 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

Zainstaluj starsze oprogramowanie Cassandra na węźle i skonfiguruj je:

Uruchom plik bootstrap dla Edge for Private Cloud w wersji 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 edytuj plik /opt/apigee/customer/application/cassandra.properties:

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

Sprawdź, czy plik należy do użytkownika apigee i czy można go odczytać:

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

Zainstaluj i skonfiguruj Cassandrę:

# 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. Sprawdź to polecenie w tym węźle i 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

Zatrzymaj usługę Cassandra i przywróć kopię zapasową. Więcej informacji znajdziesz w dokumentacji dotyczącej tworzenia i przywracania kopii zapasowych:

# 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

Po przywróceniu kopii zapasowej usuń dodatkowe konfiguracje:

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

Uruchom usługę Cassandra w węźle:

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

Powtórz te czynności na każdym węźle Cassandra, który chcesz przywrócić za pomocą kopii zapasowych, po kolei.

Po przywróceniu wszystkich węzłów Cassandra uruchom ponownie 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 zapasowej (opcja zaawansowana)

Podczas przywracania kopii zapasowych możesz zminimalizować (lub wyeliminować) utratę danych, jeśli masz dostępne repliki zawierające najnowsze dane. Jeśli repliki są dostępne, po przywróceniu kopii zapasowej uruchom naprawę węzła, który został przywrócony.

Dodatek

Jak identyfikować 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 wiele wierszy. Sprawdź 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-IP1 i DC-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

Cofanie do poprzedniej wersji głównej lub pomocniczej

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

Pobierz plik bootstrap.sh dla wersji, do której chcesz wró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 
```

Zatrzymaj komponent, aby przywrócić poprzednią wersję:

Aby wycofać dowolny z komponentów ze wspólnym kodem w węźle, musisz zatrzymać wszystkie komponenty, 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

Aby wycofać inny komponent na węźle, zatrzymaj tylko ten komponent:
```
/opt/apigee/apigee-service/bin/apigee-service component stop
```

Jeśli wycofujesz Monetization, odinstaluj ją ze wszystkich serwerów zarządzania i węzłów Message Processor:
```
/opt/apigee/apigee-service/bin/apigee-service edge-mint-gateway uninstall
```
Odinstaluj komponent, aby przywrócić poprzednią wersję węzła:
1. Aby wycofać dowolny komponent ze wspólnym kodem na węźle, musisz odinstalować wszystkie komponenty, odinstalowując edge-gateway grupę komponentów, jak pokazano w tym przykładzie:
```
/opt/apigee/apigee-service/bin/apigee-service edge-gateway uninstall
```
2. Aby wycofać Nginx, wykonaj te czynności:
```
###Find the apigee-nginx RPM 
rpm -qa | grep -i "apigee-nginx"

###Remove the apigee-nginx RPM
dnf remove apigee-nginx-1.26.x
```
3. Aby wycofać zmiany w dowolnym innym komponencie na węźle, odinstaluj tylko ten komponent, jak pokazano w tym przykładzie:
```
/opt/apigee/apigee-service/bin/apigee-service component uninstall
```
  Gdzie component to nazwa komponentu.
4. Aby wycofać zmiany w routerze brzegowym, musisz usunąć zawartość pliku /opt/nginx/conf.d oraz odinstalować grupę komponentów edge-gateway:
```
cd /opt/nginx/conf.d
rm -rf *
```

Odinstaluj apigee-setup w wersji 4.53.00:

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

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 uName i pWord to nazwa użytkownika i hasło otrzymane od Apigee. Jeśli pominiesz pWord, pojawi się prośba o jego wpisanie.

Jeśli wystąpi błąd, upewnij się, że w kroku 1 pobrano plik bootstrap.sh.

Zainstaluj apigee-setup:

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

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.
Jeśli wycofujesz Qpid, wyczyść iptables:
```
sudo iptables -F
```
Powtórz ten proces dla każdego węzła, który hostuje komponent, do którego chcesz przywrócić poprzednią wersję.

Cofanie do poprzedniej wersji poprawki

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

Pobierz konkretną wersję komponentu:
```
/opt/apigee/apigee-service/bin/apigee-service component_version install
```
gdzie component_version to komponent i wersja poprawki do zainstalowania. Na przykład:
```
/opt/apigee/apigee-service/bin/apigee-service edge-ui-4.53.00-0.0.20254 install
```
Jeśli używasz repozytorium online 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
```
Aby zainstalować komponent, użyj tego polecenia: 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ę.
Powtórz ten proces dla każdego węzła, który hostuje komponent, do którego chcesz przywrócić poprzednią wersję.

Wycofywanie zmian mTLS

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

Zatrzymaj Apigee:
```
apigee-all stop
```
Zatrzymywanie mTLS:
```
apigee-service apigee-mtls uninstall
```

Ponownie zainstaluj mTLS:

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