Onlangs probeerde ik de nieuwste en beste Patch Set Update (PSU) toe te passen op een Oracle RAC-systeem met 2 knooppunten. Alles verliep soepel op de eerste node. Ik had problemen bij het toepassen van de PSU op het tweede knooppunt. Het probleem lag niet bij OPatch of de PSU, maar ik kon Grid Infrastructure (GI) niet eens met succes uitschakelen. En om het nog erger te maken, het zou ook niet ter sprake komen.
Ik heb mijn probleem opgespoord tot aan de Grid Inter Process Communication Daemon (gipcd) Bij het uitgeven van 'crsctl stop crs' kreeg ik een bericht waarin stond dat gipcd niet succesvol kon worden beëindigd. Bij het starten van GI kwam het opstarten zover dat het probeerde gipcd te starten en stopte toen. Ik vond veel nuttige artikelen over My Oracle Support (MOS) en met Google-zoekopdrachten. Veel van die documenten leken goed op weg te zijn met mijn probleem, maar het lukte me niet om GI weer aan de gang te krijgen. Het opnieuw opstarten van de node hielp ook niet. De rest van dit artikel kan helpen, zelfs als je probleem niet bij gipcd ligt, het was gewoon het knelpunt voor mij.
Dus op dit moment moest ik een beslissing nemen. Ik zou een Service Request (SR) kunnen indienen bij MOS. Of ik zou dat knooppunt in het cluster kunnen "herbouwen". Ik wist dat als ik een SR zou indienen, ik het geluk zou hebben om het knooppunt de komende week operationeel te hebben. Ik wilde niet zo lang wachten en als dit een productiesysteem was, had ik niet zo lang kunnen wachten. Dus besloot ik het knooppunt opnieuw te bouwen. In deze blogpost worden de stappen beschreven die ik heb genomen. Op hoog niveau is dit waar het om gaat:
- Verwijder het knooppunt uit het cluster
- Ruim alle GI- en RDBMS-resten op dat knooppunt op.
- Voeg het knooppunt weer toe aan het cluster.
- Voeg de instantie en service voor het nieuwe knooppunt toe.
- Start de instantie.
In het geval dat het ertoe doet, is dit systeem Oracle 12.1.0.2 (zowel GI als RDBMS) dat draait op Oracle Linux 7. In mijn voorbeeld is host01 het 'goede' knooppunt en host02 het 'slechte' knooppunt. De databasenaam is "orcl". Waar mogelijk zal mijn opdracht de prompt hebben die aangeeft vanaf welk knooppunt ik die opdracht uitvoer.
Eerst verwijder ik de slechte node uit het cluster.
Ik begin met het verwijderen van de RDBMS-software uit de inventaris van de goede node.
[oracle@host01]$ ./runInstaller -updateNodeList ORACLE_HOME=$RDBMS_HOME "CLUSTER_NODES={host01}"
LOCAL_NODE=host01 Dan verwijder ik de GI-software uit de inventaris.
[oracle@host01]# ./runInstaller -updateNodeList ORACLE_HOME=$GRID_HOME "CLUSTER_NODES={host01}"
CRS=TRUE -silent Nu zal ik dat knooppunt uit het clusterregister verwijderen.
[root@host01]# crsctl delete node -n host02
CRS-4661: Node host02 successfully deleted.
Verwijder de 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
Verwijder vervolgens de instantie.
[root@host01]# srvctl remove instance -db orcl -instance orcl2 Remove instance from the database orcl? (y/[n]) y
Op dit punt maakt het slechte knooppunt geen deel meer uit van het cluster, vanuit het perspectief van het goede knooppunt.
Vervolgens ga ik naar het slechte knooppunt en verwijder ik de software en ruim ik enkele configuratiebestanden op.
[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
Ik nam de gemakkelijke uitweg en gebruikte gewoon 'rm' om de RDBMS- en Grid-thuissoftware te verwijderen. Alles is nu opgeruimd. Het goede knooppunt denkt dat het deel uitmaakt van een cluster met één knooppunt en het slechte knooppunt weet niet eens van het cluster af. Vervolgens voeg ik dat knooppunt weer toe aan het cluster. Ik gebruik het addnode-hulpprogramma op host01.
[oracle@host01]$ cd $GRID_HOME/addnode
[oracle@host01]$ ./addnode.sh -ignoreSysPrereqs -ignorePrereq -silent "CLUSTER_NEW_NODES={host02}"
"CLUSTER_NEW_VIRTUAL_HOSTNAMES={host02-vip}" Dit zal de GI-home van host01 naar host02 klonen. Aan het einde wordt ik gevraagd om root.sh uit te voeren op host02. Door dit script uit te voeren, wordt GI verbonden met de OCR- en stemschijven en wordt de clusterware-stack weergegeven. Ik moet echter nog een opruimroutine als root uitvoeren op host02 voordat ik verder kan gaan.
[root@host02]# cd $GRID_HOME/crs/install
[root@host02]# ./rootcrs.sh -verbose -deconfig -force
Het is mogelijk dat ik het bovenstaande eerder had kunnen uitvoeren bij het opschonen van het knooppunt. Maar dit is waar ik het op dit moment heb uitgevoerd. Nu voer ik het root.sh-script uit zoals gevraagd.
[root@host02]# cd $GRID_HOME
[root@host02]# ./root.sh
Op dit moment maakt host02 nu deel uit van het cluster en is GI in gebruik. Ik verifieer met "crs_stat -t" en "olsnodes -n". Ik controleer ook de VIP.
[root@host02]# srvctl status vip -vip host02-vip VIP host02-vip is enabled VIP host02-vip is running on node: host02
Nu terug op host01, is het tijd om de RDBMS-software te klonen.
[oracle@host01]$ cd $RDBMS_HOME/addnode
[oracle@host01]$ ./addnode.sh "CLUSTER_NEW_NODES={host02}" Hiermee wordt de OUI gestart. Loop door de wizard om het kloonproces te voltooien.
Nu voeg ik de instantie weer toe aan dat knooppunt.
[oracle@host01]$ srvctl add instance -db orcl -instance orcl2 -node host02
Als alles goed is gegaan, start de instantie meteen op.
[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
Geweldig! Het enige dat overblijft is om de benodigde services opnieuw te configureren en te starten. Ik heb er een.
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
Dat is het. Ik heb nu alles operationeel.
Hopelijk heeft deze blogpost laten zien hoe gemakkelijk het is om een "slechte" node uit het cluster te halen en weer toe te voegen. Dit hele proces kostte me ongeveer 2 uur om te voltooien. Veel sneller dan welke resolutie dan ook die ik ooit van MOS heb gekregen.
Ik ben nooit tot de oorzaak van mijn oorspronkelijke probleem gekomen. Door het knooppunt uit het cluster te halen en weer toe te voegen, kon ik weer aan de slag. Dit proces werkt niet als de hoofdoorzaak van mijn probleem hardware- of OS-gerelateerd was.
En het beste deel voor mij in dit alles? Omdat host01 de PSU al had toegepast op zowel GI- als RDBMS-huizen, betekent het klonen van die naar host02 dat ik OPatch niet op host02 hoefde uit te voeren. Die host heeft de PSU-patch ontvangen. Het enige wat ik hoefde te doen om het patchen te voltooien, was datapatch uitvoeren tegen de database.