Recientemente, estaba tratando de aplicar la última y mejor actualización de conjunto de parches (PSU) a un sistema Oracle RAC de 2 nodos. Todo salió bien en el primer nodo. Tuve problemas al intentar aplicar la PSU al segundo nodo. El problema no era con OPatch o la fuente de alimentación, sino que ni siquiera podía desactivar Grid Infrastructure (GI) con éxito. Y para colmo, tampoco saldría.
Rastreé mi problema hasta el Daemon de comunicación entre procesos de Grid (gipcd) Al emitir 'crsctl stop crs', recibí un mensaje que indica que gipcd no se pudo terminar con éxito. Al iniciar GI, el inicio llegó tan lejos como para intentar iniciar gipcd y luego se cerró. Encontré muchos artículos útiles en My Oracle Support (MOS) y con las búsquedas de Google. Muchos de esos documentos parecían estar bien encaminados con mi problema, pero no pude hacer que GI volviera a funcionar correctamente. Reiniciar el nodo tampoco ayudó. El resto de este artículo puede ayudar incluso si su problema no es con gipcd, solo fue el punto de conflicto para mí.
Entonces, en este momento, tenía que tomar una decisión. Podría presentar una solicitud de servicio (SR) en MOS. O podría "reconstruir" ese nodo en el clúster. Sabía que si presentaba una SR, tendría suerte de tener el nodo operativo en cualquier momento de la próxima semana. No quería esperar tanto y si esto fuera un sistema de producción, no podría haber esperado tanto. Así que decidí reconstruir el nodo. Esta publicación de blog detallará los pasos que tomé. A un alto nivel, esto es lo que está involucrado:
- Eliminar el nodo del clúster
- Limpie cualquier resto de GI y RDBMS en ese nodo.
- Vuelva a agregar el nodo al clúster.
- Agregue la instancia y el servicio para el nuevo nodo.
- Inicie la instancia.
En caso de que importe, este sistema es Oracle 12.1.0.2 (GI y RDBMS) que se ejecuta en Oracle Linux 7. En mi ejemplo, host01 es el nodo "bueno" y host02 es el nodo "malo". El nombre de la base de datos es "orcl". Siempre que sea posible, mi comando tendrá el indicador que indica el nodo desde el que estoy ejecutando ese comando.
Primero, eliminaré el nodo defectuoso del clúster.
Comienzo eliminando el software RDBMS del inventario del nodo bueno.
[oracle@host01]$ ./runInstaller -updateNodeList ORACLE_HOME=$RDBMS_HOME "CLUSTER_NODES={host01}"
LOCAL_NODE=host01 Luego elimino el software GI del inventario.
[oracle@host01]# ./runInstaller -updateNodeList ORACLE_HOME=$GRID_HOME "CLUSTER_NODES={host01}"
CRS=TRUE -silent Ahora eliminaré ese nodo del registro del clúster.
[root@host01]# crsctl delete node -n host02
CRS-4661: Node host02 successfully deleted.
Eliminar el 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
Luego elimine la instancia.
[root@host01]# srvctl remove instance -db orcl -instance orcl2 Remove instance from the database orcl? (y/[n]) y
En este punto, el nodo malo ya no forma parte del clúster, desde la perspectiva del nodo bueno.
A continuación, pasaré al nodo defectuoso, eliminaré el software y limpiaré algunos archivos de configuración.
[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
Tomé la salida fácil y simplemente usé 'rm' para eliminar el software doméstico RDBMS y Grid. Las cosas están todas limpias ahora. El nodo bueno piensa que es parte de un clúster de un solo nodo y el nodo malo ni siquiera sabe sobre el clúster. A continuación, volveré a agregar ese nodo al clúster. Usaré la utilidad addnode en host01.
[oracle@host01]$ cd $GRID_HOME/addnode
[oracle@host01]$ ./addnode.sh -ignoreSysPrereqs -ignorePrereq -silent "CLUSTER_NEW_NODES={host02}"
"CLUSTER_NEW_VIRTUAL_HOSTNAMES={host02-vip}" Esto clonará la casa GI de host01 a host02. Al final, se me solicita que ejecute root.sh en host02. Ejecutar este script conectará GI a los discos OCR y Voting y abrirá la pila de clusterware. Sin embargo, necesito ejecutar una rutina de limpieza más como root en host02 antes de poder continuar.
[root@host02]# cd $GRID_HOME/crs/install
[root@host02]# ./rootcrs.sh -verbose -deconfig -force
Es posible que pudiera haber ejecutado lo anterior antes al limpiar el nodo. Pero aquí es donde lo ejecuté en este momento. Ahora ejecuto el script root.sh según lo solicitado.
[root@host02]# cd $GRID_HOME
[root@host02]# ./root.sh
En este punto, host02 ahora es parte del clúster y GI está funcionando. Verifico con "crs_stat -t" y "olsnodes -n". También reviso el VIP.
[root@host02]# srvctl status vip -vip host02-vip VIP host02-vip is enabled VIP host02-vip is running on node: host02
Ahora de vuelta en host01, es hora de clonar el software RDBMS.
[oracle@host01]$ cd $RDBMS_HOME/addnode
[oracle@host01]$ ./addnode.sh "CLUSTER_NEW_NODES={host02}" Esto iniciará el OUI. Recorra el asistente para completar el proceso de clonación.
Ahora volveré a agregar la instancia en ese nodo.
[oracle@host01]$ srvctl add instance -db orcl -instance orcl2 -node host02
Si todo ha ido bien, la instancia se iniciará de inmediato.
[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
¡Impresionante! Todo lo que queda es reconfigurar e iniciar los servicios necesarios. Yo tengo 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
Eso es todo. Ya tengo todo operativo.
Con suerte, esta publicación de blog ha demostrado lo fácil que es sacar un nodo "malo" del clúster y volver a agregarlo. Todo este proceso me tomó alrededor de 2 horas para completarlo. Mucho más rápido que cualquier resolución que haya obtenido de MOS.
Nunca llegué a la causa raíz de mi problema original. Sacar el nodo del clúster y volver a agregarlo me permitió volver a funcionar. Este proceso no funcionará si la causa principal de mi problema está relacionada con el hardware o el sistema operativo.
¿Y la mejor parte para mí en todo esto? Debido a que host01 ya tenía la fuente de alimentación aplicada en los hogares GI y RDBMS, clonarlos en host02 significa que no tuve que ejecutar OPatch en host02. Ese host recibió el parche de PSU. Todo lo que tenía que hacer para completar el parche era ejecutar datapatch en la base de datos.
