sql >> Database teknologi >  >> RDS >> Oracle

KGXGN polling fejl (15)

Når du forsøger at starte den anden instans i en to-node RAC-klynge, vil den anden instans ikke starte. Hvis instansen på node1 kører, starter instansen på node2 ikke. Hvis instansen på node2 kører, starter instansen på node1 ikke. Advarselsloggen viser følgende:

Error: KGXGN polling error (15)
Errors in file /u01/app/oracle/diag/rdbms/bsp/bsp1/trace/bsp1_lmon_9151.trc:
ORA-29702: error occurred in Cluster Group Service operation
LMON (ospid: 9151): terminating the instance due to error 29702

Desværre giver LMON-sporingsfilen kun de samme fejlmeddelelser, så der er ikke noget at gå efter.

Denne fejl opstår på grund af en forkert konfiguration for klynge-sammenkoblingen. Hvis du ser på OCR'en for at se klyngeforbindelsen, kan du se, at NIC-enheden er eth4.1338:

[oracle@myhost bin]$ oifcfg getif -global
eth2 192.168.33.0 global public
eth4.1338 10.0.0.0 global cluster_interconnect

På én knude er enheden eth4 korrekt. På den anden node er enheden imidlertid eth5.1338, og OCR'en deles mellem noderne. OCR forventer, at enheden er eth4.1338. Begge servere har brug for, at klyngeforbindelsen er på den samme netværksenhed. Serverens netværkskonfiguration blev ændret, så begge noder blev konfigureret på eth5.1338-enheden. Når serverne var konfigureret identisk, omdefinerede vi OCR-konfigurationen:

[oracle@myhost bin]$ ./oifcfg setif -global eth5.1338/10.0.0.0:cluster_interconnect

Når vi ser på konfigurationen, kan vi se, at både eth4 og eth5 stadig er i OCR:

[oracle@myhost bin]$ ./oifcfg getif -global
eth2 192.168.33.0 global public
eth4.1338 10.0.0.0 global cluster_interconnect
eth5.1338 10.0.0.0 global cluster_interconnect

Så vi fjerner eth4-enheden:

[oracle@myhost bin]$ ./oifcfg delif -global eth4.1338/10.0.0.0

Vi har nu OCR rekonfigureret. Vi genstartede CRS, og begge forekomster dukkede op på begge noder!

Dette var en af ​​de fejl, hvor fejlmeddelelserne virkelig ikke pegede på en grundlæggende årsag til problemet. I stedet måtte jeg søge rundt i de områder, som jeg følte var de mest sandsynlige syndere, da jeg ret blindt opdagede konfigurationsforskellene.


  1. Sådan eksporteres resultaterne af en forespørgsel ved hjælp af MySQL Workbench

  2. NOT NULL begrænsning over et sæt kolonner

  3. Sådan fungerer TIME_TO_SEC() i MariaDB

  4. Risiko ved brug af dynamisk hukommelse i Hyper-V