For nylig prøvede jeg at anvende den nyeste og bedste Patch Set Update (PSU) til et 2-node Oracle RAC-system. Alt gik glat på den første knude. Jeg havde problemer, da jeg forsøgte at anvende PSU'en til den anden node. Problemet var ikke med OPatch eller PSU'en, men snarere kunne jeg ikke engang nedbringe Grid Infrastructure (GI) med succes. Og for at gøre ondt værre ville det heller ikke komme op.
Jeg sporede mit problem ned til Grid Inter Process Communication Daemon (gipcd) Da jeg udstedte 'crsctl stop crs', modtog jeg en meddelelse om, at gipcd ikke kunne afsluttes. Da man startede GI, kom opstarten så langt som at forsøge at starte gipcd, og så stoppede den. Jeg fandt mange nyttige artikler om My Oracle Support (MOS) og med Google-søgninger. Mange af disse dokumenter så ud til at være på rette spor med mit problem, men jeg kunne ikke få GI op at køre igen. Det hjalp heller ikke at genstarte noden. Resten af denne artikel kan hjælpe, selvom dit problem ikke er med gipcd, det var bare et problem for mig.
Så på dette tidspunkt havde jeg en beslutning at tage. Jeg kunne indgive en serviceanmodning (SR) på MOS. Eller jeg kunne "genopbygge" den node i klyngen. Jeg vidste, at hvis jeg indgav en SR, ville jeg være heldig at have noden operationel når som helst i den næste uge. Jeg ønskede ikke at vente så længe, og hvis dette var et produktionssystem, kunne jeg ikke have ventet så længe. Så jeg besluttede at genopbygge noden. Dette blogindlæg beskriver de trin, jeg tog. På et højt niveau er dette, hvad der er involveret:
- Fjern noden fra klyngen
- Ryd op i eventuelle GI- og RDBMS-rester på den node.
- Tilføj noden tilbage til klyngen.
- Tilføj forekomsten og tjenesten for den nye node.
- Start forekomsten.
Hvis det er vigtigt, er dette system Oracle 12.1.0.2 (både GI og RDBMS), der kører på Oracle Linux 7. I mit eksempel er host01 den "gode" node, og host02 er den "dårlige" node. Databasenavnet er "orcl". Hvor det er muligt, vil min kommando have prompten, der angiver den node, jeg kører kommandoen fra.
Først fjerner jeg den dårlige node fra klyngen.
Jeg starter med at fjerne RDBMS-softwaren fra den gode nodes beholdning.
[oracle@host01]$ ./runInstaller -updateNodeList ORACLE_HOME=$RDBMS_HOME "CLUSTER_NODES={host01}"
LOCAL_NODE=host01 Så fjerner jeg GI-softwaren fra inventaret.
[oracle@host01]# ./runInstaller -updateNodeList ORACLE_HOME=$GRID_HOME "CLUSTER_NODES={host01}"
CRS=TRUE -silent Nu fjerner jeg den node fra klyngeregistret.
[root@host01]# crsctl delete node -n host02
CRS-4661: Node host02 successfully deleted.
Fjern VIP'en.
[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
Fjern derefter forekomsten.
[root@host01]# srvctl remove instance -db orcl -instance orcl2 Remove instance from the database orcl? (y/[n]) y
På dette tidspunkt er den dårlige node ikke længere en del af klyngen set fra den gode nodes perspektiv.
Dernæst vil jeg flytte til den dårlige node og fjerne softwaren og rydde op i nogle 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
Jeg tog den nemme vej ud og brugte bare 'rm' til at fjerne RDBMS og Grid home-softwaren. Der er ryddet op nu. Den gode node mener, at den er en del af en enkelt-node-klynge, og den dårlige node kender ikke engang til klyngen. Dernæst tilføjer jeg den node tilbage til klyngen. Jeg bruger addnode-værktøjet 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}" Dette vil klone GI-hjemmet fra host01 til host02. Til sidst bliver jeg bedt om at køre root.sh på host02. Kørsel af dette script vil forbinde GI til OCR- og Voting-diskene og bringe clusterware-stakken frem. Jeg skal dog køre endnu en oprydningsrutine som root på host02, før jeg kan fortsætte.
[root@host02]# cd $GRID_HOME/crs/install
[root@host02]# ./rootcrs.sh -verbose -deconfig -force
Det er muligt, at jeg kunne have kørt ovenstående tidligere, når jeg rensede noden. Men det var her, jeg udførte det på dette tidspunkt. Nu kører jeg root.sh-scriptet som anmodet.
[root@host02]# cd $GRID_HOME
[root@host02]# ./root.sh
På dette tidspunkt er host02 nu en del af klyngen, og GI er oppe og køre. Jeg verificerer med "crs_stat -t" og "olsnodes -n". Jeg tjekker også VIP'en.
[root@host02]# srvctl status vip -vip host02-vip VIP host02-vip is enabled VIP host02-vip is running on node: host02
Nu tilbage på host01, er det tid til at klone RDBMS-softwaren.
[oracle@host01]$ cd $RDBMS_HOME/addnode
[oracle@host01]$ ./addnode.sh "CLUSTER_NEW_NODES={host02}" Dette vil starte OUI. Gå gennem guiden for at fuldføre klonprocessen.
Nu vil jeg tilføje forekomsten tilbage på den node.
[oracle@host01]$ srvctl add instance -db orcl -instance orcl2 -node host02
Hvis alt er gået godt, starter instansen lige 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
Fantastisk! Det eneste, der er tilbage, er at omkonfigurere og starte eventuelle nødvendige tjenester. Jeg 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 er det. Jeg har nu alt i drift.
Forhåbentlig har dette blogindlæg vist, hvor nemt det er at tage en "dårlig" node ud af klyngen og tilføje den igen. Hele denne proces tog mig omkring 2 timer at fuldføre. Meget hurtigere end nogen opløsning, jeg nogensinde har fået fra MOS.
Jeg nåede aldrig frem til årsagen til mit oprindelige problem. At tage noden ud af klyngen og tilføje den igen fik mig i gang igen. Denne proces vil ikke fungere, hvis hovedårsagen til mit problem var hardware- eller OS-relateret.
Og det bedste for mig i alt dette? Fordi host01 allerede havde PSU'en anvendt i både GI- og RDBMS-hjem, betyder kloning af dem til host02, at jeg ikke behøvede at køre OPatch på host02. Den vært modtog PSU-patchen. Alt jeg skulle gøre for at fuldføre patchen var at køre datapatch mod databasen.