Niedawno próbowałem zastosować najnowszą i najlepszą aktualizację zestawu poprawek (PSU) do 2-węzłowego systemu Oracle RAC. Na pierwszym węźle wszystko poszło gładko. Miałem problemy podczas próby zastosowania zasilacza do drugiego węzła. Problem nie dotyczył OPatch ani zasilacza, ale raczej nie mogłem nawet skutecznie obniżyć infrastruktury sieciowej (GI). A co gorsza, to też by się nie pojawiło.
Wyśledziłem mój problem do demona komunikacji Grid Inter Process Communication (gipcd) Podczas wydawania „crsctl stop crs” otrzymałem komunikat z informacją, że nie można pomyślnie zakończyć gipcd. Uruchamiając GI, startup próbował uruchomić gipcd, a następnie zakończył działanie. Znalazłem wiele pomocnych artykułów na My Oracle Support (MOS) oraz w wyszukiwarkach Google. Wiele z tych dokumentów wydawało się być na dobrej drodze z moim problemem, ale nie mogłem pomyślnie przywrócić GI do działania. Ponowne uruchomienie węzła też nie pomogło. Pozostała część tego artykułu może pomóc, nawet jeśli Twój problem nie dotyczy gipcd, był to dla mnie tylko punkt zaczepienia.
Więc w tym momencie musiałem podjąć decyzję. Mogę złożyć zgłoszenie serwisowe (SR) na MOS. Lub mógłbym „odbudować” ten węzeł w klastrze. Wiedziałem, że jeśli złożę SR, będę miał szczęście, że węzeł będzie działał w dowolnym momencie w przyszłym tygodniu. Nie chciałem czekać tak długo i gdyby to był system produkcyjny, nie mógłbym czekać tak długo. Postanowiłem więc odbudować węzeł. W tym poście na blogu szczegółowo opisano kroki, które podjąłem. Na wysokim poziomie chodzi o to:
- Usuń węzeł z klastra
- Usuń wszelkie pozostałości GI i RDBMS w tym węźle.
- Dodaj węzeł z powrotem do klastra.
- Dodaj instancję i usługę dla nowego węzła.
- Uruchom instancję.
Jeśli ma to znaczenie, ten system to Oracle 12.1.0.2 (zarówno GI, jak i RDBMS) działający w systemie Oracle Linux 7. W moim przykładzie host01 jest „dobrym” węzłem, a host02 jest „złym” węzłem. Nazwa bazy danych to „orcl”. Tam, gdzie to możliwe, moje polecenie będzie zawierało monit wskazujący węzeł, z którego uruchamiam to polecenie.
Najpierw usunę zły węzeł z klastra.
Zaczynam od usunięcia oprogramowania RDBMS z inwentarza dobrego węzła.
[oracle@host01]$ ./runInstaller -updateNodeList ORACLE_HOME=$RDBMS_HOME "CLUSTER_NODES={host01}"
LOCAL_NODE=host01 Następnie usuwam oprogramowanie GI z ekwipunku.
[oracle@host01]# ./runInstaller -updateNodeList ORACLE_HOME=$GRID_HOME "CLUSTER_NODES={host01}"
CRS=TRUE -silent Teraz usunę ten węzeł z rejestru klastra.
[root@host01]# crsctl delete node -n host02
CRS-4661: Node host02 successfully deleted.
Usuń VIP.
[root@host01]# srvctl config vip -node host02 VIP exists: network number 1, hosting node host02 VIP Name: host02-vip VIP IPv4 Address: 192.168.1.101 VIP IPv6 Address: VIP is enabled. VIP is individually enabled on nodes: VIP is individually disabled on nodes: [root@host01]# srvctl stop vip -vip host02-vip -force [root@host01]# srvctl remove vip -vip host02-vip Please confirm that you intend to remove the VIPs host02-vip (y/[n]) y
Następnie usuń instancję.
[root@host01]# srvctl remove instance -db orcl -instance orcl2 Remove instance from the database orcl? (y/[n]) y
W tym momencie zły węzeł nie jest już częścią klastra, z perspektywy dobrego węzła.
Następnie przejdę do uszkodzonego węzła, usunę oprogramowanie i wyczyszczę niektóre pliki konfiguracyjne.
[oracle@host02]$ rm -rf /u01/app/oracle/product/12.1.0.2/ [root@host02 ~]# rm -rf /u01/grid/crs12.1.0.2/* [root@host02 ~]# rm /var/tmp/.oracle/* [oracle@host02]$ /tmp]$ rm -rf /tmp/* [root@host02]# rm /etc/oracle/ocr* [root@host02]# rm /etc/oracle/olr* [root@host02]# rm -rf /pkg/oracle/app/oraInventory [root@host02]# rm -rf /etc/oracle/scls_scr
Poszedłem na łatwiznę i po prostu użyłem „rm”, aby usunąć domowe oprogramowanie RDBMS i Grid. Wszystko jest teraz posprzątane. Dobry węzeł uważa, że jest częścią klastra z jednym węzłem, a zły węzeł nawet nie wie o klastrze. Następnie dodam ten węzeł z powrotem do klastra. Użyję narzędzia addnode na hoście01.
[oracle@host01]$ cd $GRID_HOME/addnode
[oracle@host01]$ ./addnode.sh -ignoreSysPrereqs -ignorePrereq -silent "CLUSTER_NEW_NODES={host02}"
"CLUSTER_NEW_VIRTUAL_HOSTNAMES={host02-vip}" Spowoduje to sklonowanie domu GI z host01 do host02. Na koniec jestem proszony o uruchomienie root.sh na hoście02. Uruchomienie tego skryptu połączy GI z dyskami OCR i Voting oraz wywoła stos oprogramowania klastrowego. Muszę jednak uruchomić jeszcze jedną procedurę czyszczenia jako root na hoście02, zanim będę mógł kontynuować.
[root@host02]# cd $GRID_HOME/crs/install
[root@host02]# ./rootcrs.sh -verbose -deconfig -force
Możliwe, że mogłem uruchomić powyższe wcześniej podczas czyszczenia węzła. Ale w tym momencie wykonałem to. Teraz uruchamiam skrypt root.sh zgodnie z żądaniem.
[root@host02]# cd $GRID_HOME
[root@host02]# ./root.sh
W tym momencie host02 jest teraz częścią klastra, a GI już działa. Weryfikuję za pomocą „crs_stat -t” i „olsnodes -n”. Sprawdzam też VIP.
[root@host02]# srvctl status vip -vip host02-vip VIP host02-vip is enabled VIP host02-vip is running on node: host02
Teraz z powrotem na host01, czas sklonować oprogramowanie RDBMS.
[oracle@host01]$ cd $RDBMS_HOME/addnode
[oracle@host01]$ ./addnode.sh "CLUSTER_NEW_NODES={host02}" To uruchomi OUI. Przejdź przez kreatora, aby zakończyć proces klonowania.
Teraz dodam instancję z powrotem do tego węzła.
[oracle@host01]$ srvctl add instance -db orcl -instance orcl2 -node host02
Jeśli wszystko poszło dobrze, instancja uruchomi się od razu.
[oracle@host01]$ srvctl start instance -db orcl -instance orcl2
[oracle@host01]$ srvctl status database -d orcl Instance orcl1 is running on node host01 Instance orcl2 is running on node host02
SQL> select inst_id,status from gv$instance;
INST_ID STATUS ---------- ------------ 1 OPEN 2 OPEN
Niesamowite! Pozostaje tylko przekonfigurować i uruchomić wszelkie niezbędne usługi. Mam jeden.
srvctl modify service -db orcl -service hr_svc -modifyconfig -preferred "orcl1,orcl2"
srvctl start service -db orcl -service hr_svc -node host02
srvctl status service -db orcl
Otóż to. Teraz wszystko działa.
Mam nadzieję, że ten wpis na blogu pokazał, jak łatwo jest usunąć „zły” węzeł z klastra i dodać go z powrotem. Cały ten proces zajął mi około 2 godzin. Znacznie szybszy niż jakakolwiek rozdzielczość, jaką kiedykolwiek uzyskałem od MOS.
Nigdy nie dotarłem do pierwotnej przyczyny mojego pierwotnego problemu. Wyjęcie węzła z klastra i dodanie go z powrotem przywróciło mi działanie. Ten proces nie zadziała, jeśli główna przyczyna mojego problemu była związana ze sprzętem lub systemem operacyjnym.
A co w tym wszystkim jest dla mnie najlepsze? Ponieważ host01 miał już zasilacz zastosowany zarówno w domach GI, jak i RDBMS, sklonowanie ich do host02 oznacza, że nie musiałem uruchamiać OPatch na hoście02. Ten host otrzymał łatkę zasilacza. Wszystko, co musiałem zrobić, aby zakończyć łatanie, to uruchomić poprawkę danych w bazie danych.
