Oracle
 sql >> Base de données >  >> RDS >> Oracle

Recréer un mauvais nœud RAC

Tout récemment, j'essayais d'appliquer la dernière et la meilleure mise à jour de l'ensemble de correctifs (PSU) à un système Oracle RAC à 2 nœuds. Tout s'est bien passé sur le premier nœud. J'ai eu des problèmes en essayant d'appliquer le bloc d'alimentation au deuxième nœud. Le problème n'était pas avec OPatch ou le PSU, mais plutôt, je ne pouvais même pas faire tomber Grid Infrastructure (GI) avec succès. Et pour aggraver les choses, cela ne se présenterait pas non plus.

J'ai suivi mon problème jusqu'au démon de communication inter-processus Grid (gipcd). Lors de l'émission de « crsctl stop crs », j'ai reçu un message indiquant que gipcd n'a pas pu être terminé avec succès. Lors du démarrage de GI, le démarrage est allé jusqu'à essayer de démarrer gipcd, puis il s'est arrêté. J'ai trouvé de nombreux articles utiles sur My Oracle Support (MOS) et avec les recherches Google. Beaucoup de ces documents semblaient être sur la bonne voie avec mon problème, mais je n'ai pas réussi à remettre GI en marche. Redémarrer le nœud n'a pas aidé non plus. Le reste de cet article peut vous aider même si votre problème n'est pas avec gipcd, c'était juste le point de blocage pour moi.

Donc, à ce stade, j'avais une décision à prendre. Je pourrais déposer une demande de service (SR) sur MOS. Ou je pourrais "reconstruire" ce nœud dans le cluster. Je savais que si je déposais une SR, j'aurais de la chance d'avoir le nœud opérationnel à tout moment la semaine prochaine. Je ne voulais pas attendre aussi longtemps et s'il s'agissait d'un système de production, je n'aurais pas pu attendre aussi longtemps. J'ai donc décidé de reconstruire le nœud. Cet article de blog détaillera les étapes que j'ai suivies. À un niveau élevé, voici ce qui est impliqué :

  1. Supprimer le nœud du cluster
  2. Nettoyez tous les restes GI et RDBMS sur ce nœud.
  3. Rajoutez le nœud au cluster.
  4. Ajoutez l'instance et le service pour le nouveau nœud.
  5. Démarrez l'instance.

Au cas où cela importe, ce système est Oracle 12.1.0.2 (à la fois GI et RDBMS) exécuté sur Oracle Linux 7. Dans mon exemple, host01 est le "bon" nœud et host02 est le "mauvais" nœud. Le nom de la base de données est "orcl". Dans la mesure du possible, ma commande aura l'invite indiquant le nœud à partir duquel j'exécute cette commande.

Tout d'abord, je supprimerai le mauvais nœud du cluster.

Je commence par supprimer le logiciel RDBMS de l'inventaire du bon nœud.

[oracle@host01]$ ./runInstaller -updateNodeList ORACLE_HOME=$RDBMS_HOME "CLUSTER_NODES={host01}" LOCAL_NODE=host01

Ensuite, je supprime le logiciel GI de l'inventaire.

[oracle@host01]# ./runInstaller -updateNodeList ORACLE_HOME=$GRID_HOME "CLUSTER_NODES={host01}" CRS=TRUE -silent

Je vais maintenant supprimer ce nœud du registre du cluster.

[root@host01]# crsctl delete node -n host02
CRS-4661 :Le nœud host02 a bien été supprimé.

Supprimez le VIP.

[root@host01]# srvctl config vip -node host02VIP existe :numéro de réseau 1, nœud d'hébergement host02VIP Name :host02-vipVIP IPv4 Address :192.168.1.101VIP IPv6 Address :VIP est activé. VIP est activé individuellement sur les nœuds :Le VIP est désactivé individuellement sur les nœuds :[root@host01]# srvctl stop vip -vip host02-vip -force[root@host01]# srvctl remove vip -vip host02-vipVeuillez confirmer que vous avez l'intention de supprimer les VIP host02-vip (y /[n]) y

Supprimez ensuite l'instance.

[root@host01]# srvctl remove instance -db orcl -instance orcl2Remove instance from the database orcl ? (y/[n]) y
 

 À ce stade, le mauvais nœud ne fait plus partie du cluster, du point de vue du bon nœud.
 

 Ensuite, je vais passer au mauvais nœud, supprimer le logiciel et nettoyer certains fichiers de configuration.
 
[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
 

 J'ai choisi la solution de facilité et j'ai simplement utilisé «rm» pour supprimer le logiciel RDBMS et Grid home. Les choses sont toutes nettoyées maintenant. Le bon nœud pense qu'il fait partie d'un cluster à nœud unique et le mauvais nœud ne connaît même pas le cluster. Ensuite, je rajouterai ce nœud au cluster. Je vais utiliser l'utilitaire addnode sur host01.
 
[oracle@host01]$ cd $GRID_HOME/addnode
 
[oracle@host01]$ ./addnode.sh -ignoreSysPrereqs -ignorePrereq -silent "CLUSTER_NEW_NODES={host02}" "CLUSTER_NEW_VIRTUAL_HOSTNAMES={host02-vip}"
 

 Cela clonera la maison GI de host01 à host02. À la fin, je suis invité à exécuter root.sh sur host02. L'exécution de ce script connectera GI aux disques OCR et Voting et affichera la pile de clusterware. Cependant, je dois exécuter une autre routine de nettoyage en tant que root sur host02 avant de pouvoir continuer.
 
[root@host02]# cd $GRID_HOME/crs/install
 
[root@host02]# ./rootcrs.sh -verbose -deconfig -force
 

 Il est possible que j'ai pu exécuter ce qui précède plus tôt lors du nettoyage du nœud. Mais c'est là que je l'ai exécuté à ce moment. Maintenant, j'exécute le script root.sh comme demandé.
 
[root@host02]# cd $GRID_HOME
 
[root@host02]# ./root.sh
 

 À ce stade, host02 fait maintenant partie du cluster et GI est opérationnel. Je vérifie avec "crs_stat -t" et "olsnodes -n". Je vérifie aussi le VIP.
 
[root@host02]# srvctl status vip -vip host02-vipVIP host02-vip is enabledVIP host02-vip is running on node:host02
 

 Maintenant de retour sur host01, il est temps de cloner le logiciel RDBMS.
 
[oracle@host01]$ cd $RDBMS_HOME/addnode
 
[oracle@host01]$ ./addnode.sh "CLUSTER_NEW_NODES={host02}"
 

 Cela démarrera le OUI. Parcourez l'assistant pour terminer le processus de clonage.
 

 Je vais maintenant rajouter l'instance sur ce nœud.
 
[oracle@host01]$ srvctl add instance -db orcl -instance orcl2 -node host02
 

 Si tout s'est bien passé, l'instance démarrera immédiatement.
 
[oracle@host01]$ srvctl start instance -db orcl -instance orcl2
 
[oracle@host01]$ srvctl status database -d orclInstance orcl1 s'exécute sur le nœud host01Instance orcl2 s'exécute sur le nœud host02
 
SQL> sélectionnez inst_id,status depuis gv$instance ;
 
INST_ID STATUS---------- ------------ 1 OUVERT 2 OUVERT
 

 Génial! Il ne reste plus qu'à reconfigurer et démarrer les services nécessaires. J'en ai un.
 
srvctl modify service -db orcl -service hr_svc -modifyconfig -preferred "orcl1,orcl2"
 
srvctl start service -db orcl -service hr_svc -node host02
 
service d'état srvctl -db orcl
 

 
 

 C'est ça. J'ai maintenant tout opérationnel.
 

 J'espère que ce billet de blog a montré à quel point il est facile de retirer un "mauvais" nœud du cluster et de le rajouter. L'ensemble de ce processus m'a pris environ 2 heures. Beaucoup plus rapide que n'importe quelle résolution que j'ai jamais obtenue avec MOS.
 

 Je n'ai jamais trouvé la cause première de mon problème d'origine. Retirer le nœud du cluster et le rajouter m'a permis de redémarré. Ce processus ne fonctionnera pas si la cause principale de mon problème était liée au matériel ou au système d'exploitation.
 

 Et le meilleur pour moi dans tout ça ? Étant donné que host01 avait déjà appliqué le PSU à la fois aux maisons GI et RDBMS, les cloner sur host02 signifie que je n'ai pas eu à exécuter OPatch sur host02. Cet hôte a reçu le correctif PSU. Tout ce que j'avais à faire pour terminer le patch était d'exécuter datapatch sur la base de données.