Zrovna nedávno jsem se pokoušel aplikovat nejnovější a nejlepší aktualizaci sady oprav (PSU) na 2uzlový systém Oracle RAC. Na prvním uzlu šlo vše hladce. Měl jsem problémy, když jsem se snažil použít PSU na druhý uzel. Problém nebyl s OPatch nebo PSU, ale spíše jsem nemohl úspěšně svrhnout Grid Infrastructure (GI). A aby toho nebylo málo, ani to by nepřišlo.
Vysledoval jsem svůj problém až k Grid Inter Process Communication Daemon (gipcd) Při vydávání „crsctl stop crs“ jsem obdržel zprávu, že gipcd nelze úspěšně ukončit. Při spouštění GI se startup dostal tak daleko, že se pokusil spustit gipcd a pak skončil. Našel jsem mnoho užitečných článků o podpoře My Oracle (MOS) ao vyhledávání Google. Mnoho z těchto dokumentů se zdálo být v souladu s mým problémem, ale nepodařilo se mi úspěšně zprovoznit GI. Nepomohlo ani restartování uzlu. Zbytek tohoto článku vám může pomoci, i když váš problém není s gipcd, byl to pro mě jen problémový bod.
Takže v tomto okamžiku jsem se musel rozhodnout. Mohl bych podat Service Request (SR) na MOS. Nebo bych mohl „přebudovat“ tento uzel v clusteru. Věděl jsem, že když podám SR, budu mít štěstí, že uzel bude funkční kdykoli během příštího týdne. Nechtěl jsem čekat tak dlouho a pokud by se jednalo o produkční systém, nemohl bych tak dlouho čekat. Rozhodl jsem se tedy uzel přestavět. Tento blogový příspěvek podrobně popisuje kroky, které jsem podnikl. Na vysoké úrovni se jedná o toto:
- Odstraňte uzel z clusteru
- Vyčistěte všechny zbytky GI a RDBMS na tomto uzlu.
- Přidejte uzel zpět do clusteru.
- Přidejte instanci a službu pro nový uzel.
- Spusťte instanci.
V případě, že na tom záleží, je tento systém Oracle 12.1.0.2 (jak GI, tak RDBMS) běžící na Oracle Linux 7. V mém příkladu je „dobrý“ uzel host01 a „špatný“ uzel host02. Název databáze je „orcl“. Kde je to možné, bude můj příkaz obsahovat výzvu označující uzel, ze kterého tento příkaz spouštím.
Nejprve odstraním špatný uzel z clusteru.
Začnu odstraněním softwaru RDBMS z inventáře dobrého uzlu.
[oracle@host01]$ ./runInstaller -updateNodeList ORACLE_HOME=$RDBMS_HOME "CLUSTER_NODES={host01}"
LOCAL_NODE=host01 Poté odstraním GI software z inventáře.
[oracle@host01]# ./runInstaller -updateNodeList ORACLE_HOME=$GRID_HOME "CLUSTER_NODES={host01}"
CRS=TRUE -silent Nyní tento uzel odstraním z registru clusteru.
[root@host01]# crsctl delete node -n host02
CRS-4661: Node host02 successfully deleted.
Odeberte 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
Poté instanci odeberte.
[root@host01]# srvctl remove instance -db orcl -instance orcl2 Remove instance from the database orcl? (y/[n]) y
V tomto okamžiku už špatný uzel není součástí shluku, z pohledu dobrého uzlu.
Dále se přesunu do špatného uzlu a odstraním software a vyčistím některé konfigurační soubory.
[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
Vybral jsem si snadný způsob a použil jsem „rm“ k odstranění domácího softwaru RDBMS a Grid. Nyní jsou všechny věci uklizeny. Dobrý uzel si myslí, že je součástí jednouzlového clusteru, a špatný uzel o clusteru ani neví. Dále přidám tento uzel zpět do clusteru. Použiji nástroj addnode na host01.
[oracle@host01]$ cd $GRID_HOME/addnode
[oracle@host01]$ ./addnode.sh -ignoreSysPrereqs -ignorePrereq -silent "CLUSTER_NEW_NODES={host02}"
"CLUSTER_NEW_VIRTUAL_HOSTNAMES={host02-vip}" Tím se naklonuje domov GI z host01 na host02. Na konci jsem vyzván ke spuštění root.sh na host02. Spuštěním tohoto skriptu se GI připojí k diskům OCR a Voting a vyvolá se clusterware stack. Než však budu moci pokračovat, musím spustit ještě jednu rutinu čištění jako root na hostiteli 02.
[root@host02]# cd $GRID_HOME/crs/install
[root@host02]# ./rootcrs.sh -verbose -deconfig -force
Je možné, že výše uvedené jsem mohl spustit dříve při čištění uzlu. Ale tady jsem to v tuto chvíli provedl. Nyní spustím skript root.sh podle požadavku.
[root@host02]# cd $GRID_HOME
[root@host02]# ./root.sh
V tomto okamžiku je host02 nyní součástí clusteru a GI je v provozu. Ověřuji pomocí „crs_stat -t“ a „olsnodes -n“. Kontroluji také VIP.
[root@host02]# srvctl status vip -vip host02-vip VIP host02-vip is enabled VIP host02-vip is running on node: host02
Nyní zpět na host01, je čas naklonovat software RDBMS.
[oracle@host01]$ cd $RDBMS_HOME/addnode
[oracle@host01]$ ./addnode.sh "CLUSTER_NEW_NODES={host02}" Tím se spustí OUI. Projděte si průvodce a dokončete proces klonování.
Nyní přidám instanci zpět do tohoto uzlu.
[oracle@host01]$ srvctl add instance -db orcl -instance orcl2 -node host02
Pokud vše proběhlo v pořádku, instance se spustí hned.
[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
Úžasný! Zbývá pouze překonfigurovat a spustit všechny potřebné služby. Jeden mám.
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
A je to. Nyní mám vše funkční.
Doufejme, že tento příspěvek na blogu ukázal, jak snadné je vyjmout „špatný“ uzel z clusteru a přidat jej zpět. Celý tento proces mi zabral asi 2 hodiny. Mnohem rychlejší než jakékoli rozlišení, které jsem kdy získal od MOS.
Nikdy jsem se nedostal ke kořenové příčině mého původního problému. Vyjmutím uzlu z clusteru a jeho přidáním jsem se znovu zprovoznil. Tento proces nebude fungovat, pokud hlavní příčinou mého problému byl hardware nebo OS.
A co je pro mě na tom všem nejlepší? Protože host01 již měl PSU aplikovaný na domovech GI i RDBMS, klonování těchto do hostitele02 znamená, že jsem nemusel spouštět OPatch na hostiteli02. Tento hostitel obdržel opravu PSU. Vše, co jsem potřeboval k dokončení opravy, bylo spustit datapatch proti databázi.