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:
- Przywróć poprzednią wersję główną lub podrzędną. Na przykład z 4,53,00 na 4,52,02.
- 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:
- wycofanie serwera Postgres, Qpid i innych komponentów związanych z analizą;
- Przywracanie routerów i procesorów wiadomości
- Cofnięcie zmian w Cassandra i Zookeeper
- 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:
- Przywracanie wszystkich RMP pojedynczo
- Przywróć cały klaster Cassandra za pomocą kopii zapasowych.
- 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
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
- 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.
- Zidentyfikuj 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 na węźle starszą wersję Cassandra i w razie potrzeby skonfiguruj ją.
- Usuń dodatkowe konfiguracje, które zostały dodane wcześniej.
- Powtórz te czynności w przypadku wszystkich węzłów początkowych w centrum danych, po jednym.
- Powtórz powyższe czynności w przypadku wszystkich pozostałych węzłów Cassandra w danym centrum danych, po jednym.
- Pojedynczo odtwarzaj węzły z dotychczasowego, działającego centrum danych.
- Zrestartuj wszystkie komponenty edge-* w centrum danych, które są połączone z Cassandra.
- Przetestuj i przekieruj ruch z powrotem do tego centrum danych.
- Powtórz te czynności w przypadku każdego centrum danych.
Szczegółowe instrukcje
-
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-1Aby 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] - 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:
- 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 datarm -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.02curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh -u uName:pWord
# Execute bootstrap of 4.52.02sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord
Konfigurowanie ustawień Cassandra
- Utwórz lub zmodyfikuj plik
/opt/apigee/customer/application/cassandra.properties
. - 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
- Upewnij się, że plik należy do użytkownika apige i jest przez niego czytelny:
chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
- 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
- Zainstaluj Cassandra w wersji 3.11.X:
- 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
- Usuń z pliku
/opt/apigee/customer/application/cassandra.properties
dodatkowe konfiguracje dodane wcześniej. - Powtórz kroki 3–6 w przypadku wszystkich węzłów początkowych Cassandra w danym centrum danych (po kolei).
- Powtórz kroki 3–6 w przypadku wszystkich pozostałych węzłów Cassandra w danym centrum danych, po kolei.
- 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
- 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
- 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.
- 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
- Przechodzisz na wersję Cassandra 4.0.X z wersji 3.11.X i napotykasz problemy podczas aktualizacji.
- 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
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”.
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 datarm -rf /opt/apigee/data/apigee-cassandra
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.02sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord
- Utwórz lub zmodyfikuj plik
/opt/apigee/customer/application/cassandra.properties
: - Upewnij się, że plik należy do użytkownika apigee i jest czytelny:
- Instalowanie i konfigurowanie Cassandra:
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 restorerm -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 na węźle:
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra start
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.
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
conf_jvm_options_custom_settings=-Dcassandra.replace_address=ipOfNode -Dcassandra.allow_unsafe_replace=true
chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
# 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
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-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
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:
-
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
- Aby przywrócić wersję 4.52.02, pobierz
- Zatrzymaj komponent, aby cofnąć zmiany:
- 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
- Aby cofnąć dowolny inny komponent na węźle, zatrzymaj tylko ten komponent:
/opt/apigee/apigee-service/bin/apigee-service component stop
- Aby cofnąć dowolny z komponentów z kodem wspólnym w węźle, musisz je wszystkie zatrzymać, jak pokazano w tym przykładzie:
- 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
- Odinstaluj komponent, aby cofnąć zmiany na węźle:
- 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
- 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.
- Aby przywrócić Edge Router, musisz usunąć zawartość pliku
/opt/nginx/conf.d
, a także odinstalować grupę komponentówedge-gateway
:cd /opt/nginx/conf.d
rm -rf *
- Aby wycofać dowolny z komponentów z kodem wspólnym w węźle, musisz odinstalować wszystkie komponenty, odinstalowując grupę komponentów
- Odinstaluj wersję
apigee-setup
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 aplikacjiapigee-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 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. - 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 cofasz Qpid, opróżnij iptables:
sudo iptables -F
- 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:
- 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
- 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ę.
- 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:
- Zatrzymaj Apigee:
apigee-all stop
- Zatrzymanie mTLS:
apigee-service apigee-mtls uninstall
- Ponownie zainstaluj mTLS:
apigee-service apigee-mtls install
apigee-service apigee-mtls setup -f /opt/silent.conf