Erst kürzlich habe ich versucht, das neueste und beste Patch Set Update (PSU) auf ein 2-Knoten-Oracle-RAC-System anzuwenden. Beim ersten Knoten lief alles reibungslos. Ich hatte Probleme, als ich versuchte, das Netzteil auf den zweiten Knoten anzuwenden. Das Problem lag nicht bei OPatch oder dem Netzteil, sondern ich konnte Grid Infrastructure (GI) nicht einmal erfolgreich herunterfahren. Und zu allem Überfluss würde es auch nicht auftauchen.
Ich habe mein Problem bis zum Grid Inter Process Communication Daemon (gipcd) zurückverfolgt. Bei der Ausgabe von „crsctl stop crs“ erhielt ich eine Meldung, dass gipcd nicht erfolgreich beendet werden konnte. Beim Starten von GI versuchte das Startup, gipcd zu starten, und beendete es dann. Ich habe viele hilfreiche Artikel zu My Oracle Support (MOS) und mit Google-Suchen gefunden. Viele dieser Dokumente schienen genau auf dem richtigen Weg zu meinem Problem zu sein, aber ich konnte GI nicht erfolgreich wieder zum Laufen bringen. Auch ein Neustart des Knotens hat nicht geholfen. Der Rest dieses Artikels kann helfen, auch wenn Ihr Problem nicht mit gipcd zusammenhängt, es war nur der Knackpunkt für mich.
An diesem Punkt musste ich also eine Entscheidung treffen. Ich könnte einen Service Request (SR) bei MOS einreichen. Oder ich könnte diesen Knoten im Cluster „neu erstellen“. Ich wusste, wenn ich einen SR einreiche, hätte ich das Glück, den Knoten jederzeit in der nächsten Woche betriebsbereit zu haben. Ich wollte nicht so lange warten und wenn dies ein Produktionssystem wäre, hätte ich nicht so lange warten können. Also beschloss ich, den Knoten neu zu erstellen. In diesem Blogbeitrag werden die Schritte beschrieben, die ich unternommen habe. Auf hoher Ebene geht es um Folgendes:
- Entfernen Sie den Knoten aus dem Cluster
- Alle GI- und RDBMS-Reste auf diesem Knoten bereinigen.
- Fügen Sie den Knoten wieder zum Cluster hinzu.
- Fügen Sie die Instanz und den Dienst für den neuen Knoten hinzu.
- Starten Sie die Instanz.
Falls es darauf ankommt, dieses System ist Oracle 12.1.0.2 (sowohl GI als auch RDBMS), das auf Oracle Linux 7 ausgeführt wird. In meinem Beispiel ist host01 der „gute“ Knoten und host02 der „schlechte“ Knoten. Der Datenbankname ist „orcl“. Wo möglich, wird mein Befehl die Eingabeaufforderung haben, die den Knoten angibt, von dem aus ich diesen Befehl ausführe.
Zuerst entferne ich den fehlerhaften Knoten aus dem Cluster.
Ich beginne damit, die RDBMS-Software aus dem Inventar des guten Knotens zu entfernen.
[oracle@host01]$ ./runInstaller -updateNodeList ORACLE_HOME=$RDBMS_HOME "CLUSTER_NODES={host01}"
LOCAL_NODE=host01 Dann entferne ich die GI-Software aus dem Inventar.
[oracle@host01]# ./runInstaller -updateNodeList ORACLE_HOME=$GRID_HOME "CLUSTER_NODES={host01}"
CRS=TRUE -silent Jetzt entferne ich diesen Knoten aus der Cluster-Registrierung.
[root@host01]# crsctl delete node -n host02
CRS-4661: Node host02 successfully deleted.
VIP entfernen.
[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
Entfernen Sie dann die Instanz.
[root@host01]# srvctl remove instance -db orcl -instance orcl2 Remove instance from the database orcl? (y/[n]) y
An diesem Punkt ist der fehlerhafte Knoten aus Sicht des guten Knotens nicht mehr Teil des Clusters.
Als Nächstes gehe ich zum fehlerhaften Knoten, entferne die Software und bereinige einige Konfigurationsdateien.
[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
Ich habe den einfachen Ausweg gewählt und einfach „rm“ verwendet, um die RDBMS- und Grid-Home-Software zu entfernen. Jetzt ist alles aufgeräumt. Der gute Knoten denkt, dass er Teil eines Einzelknoten-Clusters ist, und der schlechte Knoten weiß nicht einmal von dem Cluster. Als Nächstes füge ich diesen Knoten wieder dem Cluster hinzu. Ich verwende das Dienstprogramm addnode auf host01.
[oracle@host01]$ cd $GRID_HOME/addnode
[oracle@host01]$ ./addnode.sh -ignoreSysPrereqs -ignorePrereq -silent "CLUSTER_NEW_NODES={host02}"
"CLUSTER_NEW_VIRTUAL_HOSTNAMES={host02-vip}" Dadurch wird das GI-Home von host01 nach host02 geklont. Am Ende werde ich aufgefordert, root.sh auf host02 auszuführen. Wenn Sie dieses Skript ausführen, wird GI mit den OCR- und Voting-Festplatten verbunden und der Clusterware-Stack wird aufgerufen. Allerdings muss ich eine weitere Bereinigungsroutine als root auf host02 ausführen, bevor ich fortfahren kann.
[root@host02]# cd $GRID_HOME/crs/install
[root@host02]# ./rootcrs.sh -verbose -deconfig -force
Es ist möglich, dass ich das obige früher beim Bereinigen des Knotens hätte ausführen können. Aber hier habe ich es damals ausgeführt. Jetzt führe ich das root.sh-Skript wie gewünscht aus.
[root@host02]# cd $GRID_HOME
[root@host02]# ./root.sh
Zu diesem Zeitpunkt ist host02 nun Teil des Clusters und GI ist betriebsbereit. Ich verifiziere mit „crs_stat -t“ und „olsnodes -n“. Ich überprüfe auch den VIP.
[root@host02]# srvctl status vip -vip host02-vip VIP host02-vip is enabled VIP host02-vip is running on node: host02
Jetzt zurück auf host01, es ist an der Zeit, die RDBMS-Software zu klonen.
[oracle@host01]$ cd $RDBMS_HOME/addnode
[oracle@host01]$ ./addnode.sh "CLUSTER_NEW_NODES={host02}" Dadurch wird die OUI gestartet. Gehen Sie durch den Assistenten, um den Klonvorgang abzuschließen.
Jetzt füge ich die Instanz wieder auf diesem Knoten hinzu.
[oracle@host01]$ srvctl add instance -db orcl -instance orcl2 -node host02
Wenn alles gut gegangen ist, startet die Instanz 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
Fantastisch! Es bleibt nur noch, alle erforderlichen Dienste neu zu konfigurieren und zu starten. Ich habe einen.
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
Das ist es. Ich habe jetzt alles in Betrieb.
Hoffentlich hat dieser Blogbeitrag gezeigt, wie einfach es ist, einen „schlechten“ Knoten aus dem Cluster zu entfernen und ihn wieder hinzuzufügen. Dieser gesamte Vorgang dauerte etwa 2 Stunden. Viel schneller als jede Auflösung, die ich jemals von MOS erhalten habe.
Ich bin nie auf die Ursache meines ursprünglichen Problems gekommen. Das Entfernen des Knotens aus dem Cluster und das erneute Hinzufügen brachte mich wieder zum Laufen. Dieser Vorgang funktioniert nicht, wenn die Hauptursache meines Problems hardware- oder betriebssystembezogen war.
Und das Beste an all dem für mich? Da auf host01 bereits das Netzteil sowohl auf GI- als auch auf RDBMS-Homes angewendet wurde, bedeutet das Klonen dieser auf host02, dass ich OPatch nicht auf host02 ausführen musste. Dieser Host hat den PSU-Patch erhalten. Alles, was ich tun musste, um das Patchen abzuschließen, war, datapatch gegen die Datenbank laufen zu lassen.
