Recentemente, eu estava tentando aplicar a atualização do conjunto de patches (PSU) mais recente e melhor a um sistema Oracle RAC de 2 nós. Tudo correu bem no primeiro nó. Eu tive problemas ao tentar aplicar o PSU ao segundo nó. O problema não era com o OPatch ou a PSU, mas sim, eu não consegui nem mesmo derrubar a Grid Infrastructure (GI) com sucesso. E para piorar as coisas, também não apareceria.
Rastreei meu problema até o Grid Inter Process Communication Daemon (gipcd) Ao emitir 'crsctl stop crs', recebi uma mensagem informando que o gipcd não pôde ser encerrado com êxito. Ao iniciar o GI, a inicialização chegou a tentar iniciar o gipcd e depois foi encerrada. Encontrei muitos artigos úteis no My Oracle Support (MOS) e nas pesquisas do Google. Muitos desses documentos pareciam estar no caminho certo com o meu problema, mas não consegui fazer o GI voltar a funcionar. A reinicialização do nó também não ajudou. O restante deste artigo pode ajudar mesmo que seu problema não seja com o gipcd, foi apenas o ponto de discórdia para mim.
Então, neste momento, eu tinha uma decisão a tomar. Eu poderia registrar uma solicitação de serviço (SR) no MOS. Ou eu poderia “reconstruir” esse nó no cluster. Eu sabia que se apresentasse um SR, teria sorte de ter o nó operacional a qualquer momento na próxima semana. Eu não queria esperar tanto e se isso fosse um sistema de produção, não poderia esperar tanto. Então eu decidi reconstruir o nó. Esta postagem no blog detalhará as etapas que dei. Em um nível alto, é isso que está envolvido:
- Remova o nó do cluster
- Limpe todos os remanescentes de GI e RDBMS nesse nó.
- Adicione o nó de volta ao cluster.
- Adicione a instância e o serviço para o novo nó.
- Inicie a instância.
Caso seja importante, este sistema é o Oracle 12.1.0.2 (tanto GI quanto RDBMS) em execução no Oracle Linux 7. No meu exemplo, host01 é o nó "bom" e host02 é o nó "ruim". O nome do banco de dados é “orcl”. Sempre que possível, meu comando terá o prompt indicando o nó do qual estou executando esse comando.
Primeiro, removerei o nó inválido do cluster.
Começo removendo o software RDBMS do inventário do nó bom.
[oracle@host01]$ ./runInstaller -updateNodeList ORACLE_HOME=$RDBMS_HOME "CLUSTER_NODES={host01}"
LOCAL_NODE=host01 Então eu removo o software GI do inventário.
[oracle@host01]# ./runInstaller -updateNodeList ORACLE_HOME=$GRID_HOME "CLUSTER_NODES={host01}"
CRS=TRUE -silent Agora vou remover esse nó do registro do cluster.
[root@host01]# crsctl delete node -n host02
CRS-4661: Node host02 successfully deleted.
Remova o 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
Em seguida, remova a instância.
[root@host01]# srvctl remove instance -db orcl -instance orcl2 Remove instance from the database orcl? (y/[n]) y
Neste ponto, o nó ruim não faz mais parte do cluster, do ponto de vista do nó bom.
Em seguida, passarei para o nó defeituoso e removerei o software e limparei alguns arquivos de configuração.
[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
Peguei o caminho mais fácil e usei apenas 'rm' para remover o software doméstico RDBMS e Grid. As coisas estão todas limpas agora. O nó bom pensa que faz parte de um cluster de nó único e o nó ruim nem sabe sobre o cluster. Em seguida, adicionarei esse nó de volta ao cluster. Usarei o utilitário addnode no host01.
[oracle@host01]$ cd $GRID_HOME/addnode
[oracle@host01]$ ./addnode.sh -ignoreSysPrereqs -ignorePrereq -silent "CLUSTER_NEW_NODES={host02}"
"CLUSTER_NEW_VIRTUAL_HOSTNAMES={host02-vip}" Isso clonará o GI inicial do host01 para o host02. No final, sou solicitado a executar root.sh no host02. A execução desse script conectará o GI aos discos OCR e Voting e exibirá a pilha de clusterware. No entanto, preciso executar mais uma rotina de limpeza como root no host02 antes de prosseguir.
[root@host02]# cd $GRID_HOME/crs/install
[root@host02]# ./rootcrs.sh -verbose -deconfig -force
É possível que eu tenha executado o acima antes ao limpar o nó. Mas foi aqui que eu o executei neste momento. Agora eu executo o script root.sh conforme solicitado.
[root@host02]# cd $GRID_HOME
[root@host02]# ./root.sh
Neste ponto, o host02 agora faz parte do cluster e o GI está funcionando. Eu verifico com “crs_stat -t” e “olsnodes -n”. Eu também verifico o VIP.
[root@host02]# srvctl status vip -vip host02-vip VIP host02-vip is enabled VIP host02-vip is running on node: host02
Agora de volta ao host01, é hora de clonar o software RDBMS.
[oracle@host01]$ cd $RDBMS_HOME/addnode
[oracle@host01]$ ./addnode.sh "CLUSTER_NEW_NODES={host02}" Isso iniciará o OUI. Percorra o assistente para concluir o processo de clonagem.
Agora vou adicionar a instância de volta nesse nó.
[oracle@host01]$ srvctl add instance -db orcl -instance orcl2 -node host02
Se tudo correu bem, a instância iniciará imediatamente.
[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
Impressionante! Tudo o que resta é reconfigurar e iniciar os serviços necessários. Eu tenho um.
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
É isso. Agora tenho tudo operacional.
Espero que esta postagem no blog tenha mostrado como é fácil remover um nó “ruim” do cluster e adicioná-lo novamente. Todo esse processo levou cerca de 2 horas para ser concluído. Muito mais rápido do que qualquer resolução que já obtive do MOS.
Eu nunca cheguei à causa raiz do meu problema original. Tirar o nó do cluster e adicioná-lo de volta me fez voltar a funcionar. Esse processo não funcionará se a causa raiz do meu problema for relacionada a hardware ou sistema operacional.
E a melhor parte para mim em tudo isso? Como o host01 já tinha a PSU aplicada aos lares GI e RDBMS, cloná-los para o host02 significa que não precisei executar o OPatch no host02. Esse host recebeu o patch da PSU. Tudo o que eu precisava fazer para concluir o patch era executar o datapatch no banco de dados.
