Nyligen försökte jag använda den senaste och bästa uppdateringen av patchuppsättningar (PSU) på ett 2-nods Oracle RAC-system. Allt gick smidigt på den första noden. Jag hade problem när jag försökte applicera PSU:n på den andra noden. Problemet var inte med OPatch eller PSU, utan snarare kunde jag inte ens få ner Grid Infrastructure (GI) framgångsrikt. Och för att göra saken värre, det skulle inte komma upp heller.
Jag spårade mitt problem till Grid Inter Process Communication Daemon (gipcd) När jag utfärdade 'crsctl stop crs' fick jag ett meddelande om att gipcd inte kunde avslutas. När man startade GI kom uppstarten så långt som att försöka starta gipcd och sedan avslutades den. Jag hittade många användbara artiklar om My Oracle Support (MOS) och med Google-sökningar. Många av dessa dokument verkade vara på rätt spår med mitt problem, men jag lyckades inte få GI igång igen. Att starta om noden hjälpte inte heller. Resten av den här artikeln kan hjälpa dig även om ditt problem inte är med gipcd, det var bara problematiken för mig.
Så vid denna tidpunkt hade jag ett beslut att fatta. Jag skulle kunna lämna in en Service Request (SR) på MOS. Eller så kan jag "bygga om" den noden i klustret. Jag visste att om jag lämnade in en SR skulle jag ha turen att ha noden i drift när som helst under nästa vecka. Jag ville inte vänta så länge och om det här vore ett produktionssystem hade jag inte kunnat vänta så länge. Så jag bestämde mig för att bygga om noden. Det här blogginlägget kommer att beskriva de steg jag tog. På hög nivå är detta vad som gäller:
- Ta bort noden från klustret
- Rensa eventuella GI- och RDBMS-rester på den noden.
- Lägg till noden tillbaka till klustret.
- Lägg till instansen och tjänsten för den nya noden.
- Starta instansen.
Om det spelar någon roll är det här systemet Oracle 12.1.0.2 (både GI och RDBMS) som körs på Oracle Linux 7. I mitt exempel är host01 den "bra" noden och host02 är den "dåliga" noden. Databasnamnet är "orcl". Om möjligt kommer mitt kommando att ha en prompt som indikerar noden jag kör kommandot från.
Först tar jag bort den dåliga noden från klustret.
Jag börjar med att ta bort RDBMS-programvaran från den goda nodens inventering.
[oracle@host01]$ ./runInstaller -updateNodeList ORACLE_HOME=$RDBMS_HOME "CLUSTER_NODES={host01}"
LOCAL_NODE=host01 Sedan tar jag bort GI-programvaran från inventeringen.
[oracle@host01]# ./runInstaller -updateNodeList ORACLE_HOME=$GRID_HOME "CLUSTER_NODES={host01}"
CRS=TRUE -silent Nu tar jag bort den noden från klusterregistret.
[root@host01]# crsctl delete node -n host02
CRS-4661: Node host02 successfully deleted.
Ta bort 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
Ta sedan bort instansen.
[root@host01]# srvctl remove instance -db orcl -instance orcl2 Remove instance from the database orcl? (y/[n]) y
Vid denna tidpunkt är den dåliga noden inte längre en del av klustret, ur den goda nodens perspektiv.
Därefter ska jag flytta till den dåliga noden och ta bort programvaran och rensa upp några konfigurationsfiler.
[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
Jag tog den enkla vägen ut och använde bara "rm" för att ta bort RDBMS och Grid Home-programvaran. Allt är städat nu. Den bra noden tror att den är en del av ett ennodkluster och den dåliga noden vet inte ens om klustret. Därefter lägger jag till den noden tillbaka till klustret. Jag använder addnode-verktyget på host01.
[oracle@host01]$ cd $GRID_HOME/addnode
[oracle@host01]$ ./addnode.sh -ignoreSysPrereqs -ignorePrereq -silent "CLUSTER_NEW_NODES={host02}"
"CLUSTER_NEW_VIRTUAL_HOSTNAMES={host02-vip}" Detta kommer att klona GI-hemmet från host01 till host02. I slutet uppmanas jag att köra root.sh på host02. Att köra det här skriptet kommer att ansluta GI till OCR- och Voting-diskarna och ta upp clusterware-stacken. Jag behöver dock köra ytterligare en rensningsrutin som root på host02 innan jag kan fortsätta.
[root@host02]# cd $GRID_HOME/crs/install
[root@host02]# ./rootcrs.sh -verbose -deconfig -force
Det är möjligt att jag kunde ha kört ovanstående tidigare när jag rensade upp noden. Men det var här jag utförde det vid den här tiden. Nu kör jag root.sh-skriptet som efterfrågat.
[root@host02]# cd $GRID_HOME
[root@host02]# ./root.sh
Vid det här laget är host02 nu en del av klustret och GI är igång. Jag verifierar med "crs_stat -t" och "olsnodes -n". Jag kollar också VIP.
[root@host02]# srvctl status vip -vip host02-vip VIP host02-vip is enabled VIP host02-vip is running on node: host02
Nu tillbaka på host01, är det dags att klona RDBMS-programvaran.
[oracle@host01]$ cd $RDBMS_HOME/addnode
[oracle@host01]$ ./addnode.sh "CLUSTER_NEW_NODES={host02}" Detta kommer att starta OUI. Gå igenom guiden för att slutföra klonprocessen.
Nu ska jag lägga till instansen igen på den noden.
[oracle@host01]$ srvctl add instance -db orcl -instance orcl2 -node host02
Om allt har gått bra kommer instansen att starta direkt.
[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
Grymt bra! Allt som återstår är att konfigurera om och starta alla nödvändiga tjänster. Jag har en.
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
Det är allt. Jag har nu allt i drift.
Förhoppningsvis har det här blogginlägget visat hur lätt det är att ta ut en "dålig" nod ur klustret och lägga till den igen. Hela denna process tog mig cirka 2 timmar att slutföra. Mycket snabbare än någon upplösning jag någonsin har fått från MOS.
Jag kom aldrig till grundorsaken till mitt ursprungliga problem. Att ta ut noden ur klustret och lägga till den igen fick mig igång igen. Den här processen kommer inte att fungera om grundorsaken till mitt problem var hårdvaru- eller OS-relaterad.
Och det bästa för mig i allt detta? Eftersom host01 redan hade nätaggregatet applicerat på både GI- och RDBMS-hem, betyder kloning av dessa till host02 att jag inte behövde köra OPatch på host02. Den värden fick PSU-patchen. Allt jag behövde göra för att slutföra patchen var att köra datapatch mot databasen.