Proprio di recente, stavo cercando di applicare l'ultimo e più grande Patch Set Update (PSU) a un sistema Oracle RAC a 2 nodi. Tutto è andato liscio sul primo nodo. Ho avuto problemi durante il tentativo di applicare l'alimentatore al secondo nodo. Il problema non era con OPatch o l'alimentatore, ma piuttosto, non potevo nemmeno abbattere con successo Grid Infrastructure (GI). E come se non bastasse, non verrebbe nemmeno fuori.
Ho rintracciato il mio problema nel daemon di comunicazione tra processi di Grid (gipcd). Quando ho emesso "crsctl stop crs", ho ricevuto un messaggio in cui si affermava che gipcd non poteva essere terminato con successo. Quando si avvia GI, l'avvio è arrivato al punto di provare ad avviare gipcd e poi si è chiuso. Ho trovato molti articoli utili su My Oracle Support (MOS) e con le ricerche su Google. Molti di questi documenti sembravano essere in linea con il mio problema, ma non sono riuscito a ripristinare con successo GI. Anche il riavvio del nodo non ha aiutato. Il resto di questo articolo può aiutarti anche se il tuo problema non riguarda gipcd, era solo il punto critico per me.
Quindi, in questo momento, dovevo prendere una decisione. Potrei presentare una richiesta di servizio (SR) su MOS. Oppure potrei "ricostruire" quel nodo nel cluster. Sapevo che se avessi presentato una SR, sarei stato fortunato ad avere il nodo operativo in qualsiasi momento nella prossima settimana. Non volevo aspettare così tanto e se questo fosse stato un sistema di produzione, non avrei potuto aspettare così tanto. Quindi ho deciso di ricostruire il nodo. Questo post sul blog descriverà in dettaglio i passaggi che ho fatto. Ad alto livello, questo è ciò che è coinvolto:
- Rimuovi il nodo dal cluster
- Pulisci tutti i resti GI e RDBMS su quel nodo.
- Aggiungi di nuovo il nodo al cluster.
- Aggiungi l'istanza e il servizio per il nuovo nodo.
- Avvia l'istanza.
Nel caso sia importante, questo sistema è Oracle 12.1.0.2 (sia GI che RDBMS) in esecuzione su Oracle Linux 7. Nel mio esempio, host01 è il nodo "buono" e host02 è il nodo "cattivo". Il nome del database è "orcl". Ove possibile, il mio comando avrà il prompt che indica il nodo da cui sto eseguendo quel comando.
Innanzitutto, rimuoverò il nodo danneggiato dal cluster.
Comincio rimuovendo il software RDBMS dall'inventario del nodo buono.
[oracle@host01]$ ./runInstaller -updateNodeList ORACLE_HOME=$RDBMS_HOME "CLUSTER_NODES={host01}"
LOCAL_NODE=host01 Quindi rimuovo il software GI dall'inventario.
[oracle@host01]# ./runInstaller -updateNodeList ORACLE_HOME=$GRID_HOME "CLUSTER_NODES={host01}"
CRS=TRUE -silent Ora rimuoverò quel nodo dal registro del cluster.
[root@host01]# crsctl delete node -n host02
CRS-4661: Node host02 successfully deleted.
Rimuovi il 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
Quindi rimuovi l'istanza.
[root@host01]# srvctl remove instance -db orcl -instance orcl2 Remove instance from the database orcl? (y/[n]) y
A questo punto, il nodo danneggiato non fa più parte del cluster, dal punto di vista del nodo buono.
Successivamente, passerò al nodo danneggiato e rimuoverò il software e ripulirò alcuni file di configurazione.
[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
Ho preso la via più semplice e ho appena usato "rm" per rimuovere il software domestico RDBMS e Grid. Le cose sono tutte ripulite ora. Il nodo buono pensa di far parte di un cluster a nodo singolo e il nodo danneggiato non conosce nemmeno il cluster. Successivamente, aggiungerò di nuovo quel nodo al cluster. Userò l'utilità addnode su host01.
[oracle@host01]$ cd $GRID_HOME/addnode
[oracle@host01]$ ./addnode.sh -ignoreSysPrereqs -ignorePrereq -silent "CLUSTER_NEW_NODES={host02}"
"CLUSTER_NEW_VIRTUAL_HOSTNAMES={host02-vip}" Questo clonerà la casa GI da host01 a host02. Alla fine, mi viene chiesto di eseguire root.sh su host02. L'esecuzione di questo script collegherà GI ai dischi OCR e Voting e farà apparire lo stack del clusterware. Tuttavia, ho bisogno di eseguire un'altra routine di pulizia come root su host02 prima di poter procedere.
[root@host02]# cd $GRID_HOME/crs/install
[root@host02]# ./rootcrs.sh -verbose -deconfig -force
È possibile che avrei potuto eseguire quanto sopra prima durante la pulizia del nodo. Ma è qui che l'ho eseguito in questo momento. Ora eseguo lo script root.sh come richiesto.
[root@host02]# cd $GRID_HOME
[root@host02]# ./root.sh
A questo punto, host02 fa ora parte del cluster e GI è attivo e funzionante. Verifico con "crs_stat -t" e "olsnodes -n". Controllo anche il VIP.
[root@host02]# srvctl status vip -vip host02-vip VIP host02-vip is enabled VIP host02-vip is running on node: host02
Ora di nuovo su host01, è il momento di clonare il software RDBMS.
[oracle@host01]$ cd $RDBMS_HOME/addnode
[oracle@host01]$ ./addnode.sh "CLUSTER_NEW_NODES={host02}" Questo avvierà l'OUI. Segui la procedura guidata per completare il processo di clonazione.
Ora aggiungerò nuovamente l'istanza su quel nodo.
[oracle@host01]$ srvctl add instance -db orcl -instance orcl2 -node host02
Se tutto è andato bene, l'istanza si avvierà correttamente.
[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
Eccezionale! Non resta che riconfigurare e avviare gli eventuali servizi necessari. Ne ho uno.
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
Questo è tutto. Ora ho tutto operativo.
Si spera che questo post sul blog abbia mostrato quanto sia facile rimuovere un nodo "cattivo" dal cluster e aggiungerlo di nuovo. L'intero processo mi ha richiesto circa 2 ore per essere completato. Molto più veloce di qualsiasi risoluzione che abbia mai ottenuto da MOS.
Non sono mai arrivato alla causa principale del mio problema originale. Rimuovere il nodo dal cluster e aggiungerlo di nuovo mi ha ripristinato e funzionante. Questo processo non funzionerà se la causa principale del mio problema era l'hardware o il sistema operativo.
E la parte migliore per me in tutto questo? Poiché host01 aveva già applicato l'alimentatore alle case GI e RDBMS, clonarli su host02 significa che non dovevo eseguire OPatch su host02. Quell'host ha ricevuto la patch PSU. Tutto quello che dovevo fare per completare l'applicazione era eseguire datapatch sul database.
