Oracle 叢集的自啟動,OLR與套接字檔案

Hehuyi_In發表於2020-10-24

當Oracle叢集安裝部署完成後,預設會處於啟動的狀態,當伺服器重啟之後叢集也會被自動啟動,那麼,Oracle叢集是如何來實現自啟動的呢?

一、 叢集的自啟動

1. 自啟動指令碼

Oracle 10G: 

cat /etc/inittab
h1:35:respawn:/etc/init.d/init.evmd run >/dev/null 2>&1 </dev/null
h2:35:respawn:/etc/init.d/init.cssd fatal >/dev/null 2>&1 </dev/null
h3:35:respawn:/etc/init.d/init.crsd run >/dev/null 2>&1 </dev/null

Oracle 11G:

cat /etc/inittab
h1:35:respawn:/etc/init.d/init.ohasd run >/dev/null 2>&1 </dev/null

10g版本中,系統啟動時由init程式根據/etc/inittab配置檔案來派生出叢集的高可用守護程式。11g中,init僅派生出init.ohasd,然後由init.ohasd啟動ohasd.bin實現叢集的自啟動。

另外,由於RedHat 6.x棄用了inittab檔案,目前配置init.ohasd程式的檔案由/etc/inittab變為/etc/init/oracle-ohasd.conf。

 cat /etc/rc.d/init.d/oracle-ohasd.conf 
 # Copyright (c) 2001, 2011, Oracle and/or its affiliates. All rights reserved. 
 #
 # Oracle OHASD startup
 start on runlevel [35]
 stop  on runlevel [!35]
 respawn
 exec /etc/init.d/init.ohasd run >/dev/null 2>&1 </dev/null

在RedHat 7.*以上版本中,init.ohasd變為以service形式配置在/etc/systemd/system下。

cat /etc/systemd/system/oracle-ohasd.service
# Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved.
#
# Oracle OHASD startup
[Unit]
Description=Oracle High Availability Services
After=syslog.target network-online.target remote-fs.target
[Service]
ExecStart=/etc/init.d/init.ohasd run >/dev/null 2>&1 </dev/null
ExecStop=/etc/init.d/init.ohasd stop >/dev/null 2>&1 </dev/null
TimeoutStopSec=60min
Type=simple
Restart=always
# Do not kill any processes except init.ohasd after ExecStop, unless the
# stop command times out.
KillMode=process
SendSIGKILL=yes
[Install]
WantedBy=multi-user.target graphical.target

 

實際上,Oracle叢集自啟動是由init.ohasd和ohasd兩個指令碼相互配合來完成的,這兩個指令碼均位於/etc/rc.d/init.d目錄下。

[root@rac1 init.d]# pwd
/etc/rc.d/init.d

[root@rac1 init.d]# ls -ltr *ohasd*
-rwxr-xr-x. 1 root root 6835 Aug 29 09:57 ohasd
-rwxr-xr-x. 1 root root 9076 Aug 29 10:40 init.ohasd

 

2. init.ohasd

主要有兩個作用:

  • 建立名為npohasd的命名管道檔案,並在init.ohasd執行過程中始終read該命名管道檔案,以此作為標記,該作用為init.ohasd最重要的作用。當命名管道檔案未被read標記時,叢集無法啟動
  • init.ohasd作為ohasd.bin的高可用守護程式而存在,當ohasd.bin程式異常終止時,由init.ohasd再次啟動ohasd.bin,來實現ohasd.bin程式的高可用。ohasd.bin程式是叢集的高可用程式,當叢集資源意外終止時由ohasd.bin所屬的agent程式負責重新啟動相應資源,同時ohasd.bin也是負責整個叢集啟動的程式。(叢集並非由init.ohasd指令碼啟動,init.ohasd做叢集啟動時的前期準備工作)

 

3. ohasd

ohasd指令碼是在系統啟動時真正啟動叢集的指令碼,叢集安裝完畢後,ohasd指令碼被軟連線到/etc/rc.d下面的相關啟動級別目錄中(/etc/rc.d/rc[0-6].d/*)。系統啟動時,執行不同級別的指令碼程式,啟動級別為3時,/etc/rc.d/rc3.d/S96ohasd被執行,此時ohasd指令碼呼叫$ORACLE_HOME/bin/crsctl指令碼來啟動叢集。

ohasd指令碼在執行時會判斷/var/tmp/.oracle目錄是否存在,如果不存在將會建立,並將目錄許可權置為01777 ,/var/tmp/.oracle目錄中存放著叢集啟動及正常執行時所產生的套接字以及命名管道檔案。

如下為/etc/rc.d/rc[0-6]/*中ohasd指令碼的軟連線情況:

ls -ltr /etc/rc.d/rc[0-6].d/*ohasd*
lrwxrwxrwx. 1 root root 17 Feb 21  2018 /etc/rc.d/rc5.d/S96ohasd -> /etc/init.d/ohasd
lrwxrwxrwx. 1 root root 17 Feb 21  2018 /etc/rc.d/rc6.d/K15ohasd -> /etc/init.d/ohasd
lrwxrwxrwx. 1 root root 17 Feb 21  2018 /etc/rc.d/rc4.d/K15ohasd -> /etc/init.d/ohasd
lrwxrwxrwx. 1 root root 17 Feb 21  2018 /etc/rc.d/rc2.d/K15ohasd -> /etc/init.d/ohasd
lrwxrwxrwx. 1 root root 17 Feb 21  2018 /etc/rc.d/rc1.d/K15ohasd -> /etc/init.d/ohasd
lrwxrwxrwx. 1 root root 17 Feb 21  2018 /etc/rc.d/rc0.d/K15ohasd -> /etc/init.d/ohasd
lrwxrwxrwx. 1 root root 17 Mar 26 01:40 /etc/rc.d/rc3.d/S96ohasd -> /etc/init.d/ohasd

 

4. init.ohasd/ohasd何時被呼叫

  • 1)開機BIOS自檢,根據BIOS中配置的啟動裝置讀取MBR並載入Bootloader程式。
  • 2)載入並執行載入程式GRUB。
  • 3)GRUB根據配置載入核心映像。
  • 4)核心啟動(根檔案系統掛載,核心執行/sbin/init)
  • 5)init依據/etc/inittab中配置執行級別進行系統的初始化(/etc/rc.d/rc.sysinit),/etc/init/*內配置檔案生效是在該步進行
  • 6)根據不同的執行級別,啟動相應服務 (服務程式指令碼位於/etc/rc.d/rc[0-6].d中)。

其中,init.ohasd和ohash是在第5步和第6步來被呼叫啟動叢集。

當系統啟動到第5步的時候,init程式會掃描/etc/init/下所有配置檔案,根據/etc/init/oracle-ohasd.conf中的內容派生init.ohasd程式(由init.ohasd發出read命名管道檔案npohasd的命令)。

系統啟動到第6步時,根據系統的不同啟動級別,/etc/rc.d/rc[0-6].d/*中的指令碼程式被執行,此時ohasd呼叫$ORACLE_HOME/bin/crsctl指令碼,由crsctl負責叢集的啟動。

 

5. init.ohasd/ohasd丟失怎麼辦

這兩個指令碼是在叢集安裝時執行root.sh過程中,從$GRID_HOME/crs/init/目錄中複製而來的。如果丟失,可以從$GRID_HOME/crs/init目錄中重新複製,並將/etc/init.d中的init.ohasd/ohasd許可權置為755即可。

 

二、 禁用叢集自啟動

1. ohasdstr

在/etc/oracle/scls_scr/[SID]/root/目錄中有一個配置檔案ohasdstr,當ohasd指令碼被呼叫時會讀取ohasdstr檔案,根據ohasdstr檔案中記錄的enable/disable來判斷叢集是否自啟動。

正確啟/禁用叢集自啟動的做法是:

crsctl disable/enable crs

 

該命令實際上就是修改配置檔案ohasdstr

cat /etc/oracle/scls_scr/qdata1/root/ohasdstr 
enable

crsctl disable crs
CRS-4621: Oracle High Availability Services autostart is disabled.

cat /etc/oracle/scls_scr/qdata1/root/ohasdstr 
disable

crsctl enable crs
CRS-4622: Oracle High Availability Services autostart is enabled.

cat /etc/oracle/scls_scr/qdata1/root/ohasdstr 
enable

當然,也可以直接手工修改ohasdstr檔案。

 

前面我們說到,系統啟動後由init.ohasd和ohasd兩個指令碼相互配合共同來完成叢集的啟動。當init.ohash前期工作準備完成,ohasd啟動叢集時需要首先讀取olr檔案,根據olr檔案中記錄的資訊啟動叢集的初始化資源層,並在該過程中建立叢集啟動及執行時所需的套接字檔案。

三、 OLR檔案

1. OLR檔案作用及位置

OLR檔案中記錄ohasd守護程式啟動叢集初始化資源時所需要的資源定義資訊。當叢集啟動時ohasd會從/etc/oracle/olr.loc檔案中獲取olr檔案的位置。

cat /etc/oracle/olr.loc
#輸出
olrconfig_loc=/u01/app/11.2.0/grid/cdata/node1.olr  #olr檔案的位置
crs_home=/u01/app/11.2.0/grid

ls -ltr /u01/app/11.2.0/grid/cdata/node1.olr
#輸出
-rw-------. 1 root oinstall 272756736 Jan  8 21:40 /u01/app/11.2.0/grid/cdata/node1.olr

每個節點都有自己的olr檔案,預設位置在$GRID_HOME/cdata/<hostname>.olr,olr配置檔案的位置也可以使用ocrcheck命令獲取,ocrcheck命令同時會驗證ocr/olr的邏輯完整性。

ocrcheck -local
#輸出
Status of Oracle Local Registry is as follows :
     Version                  :          3
     Total space (kbytes)     :     262120
     Used space (kbytes)      :       2676
     Available space (kbytes) :     259444
     ID                       :  810831447
     Device/File Name         : /u01/app/11.2.0/grid/cdata/node1.olr
                                Device/File integrity check succeeded
     Local registry integrity check succeeded
     Logical corruption check succeeded


ocrcheck -local -config
#輸出
Oracle Local Registry configuration is :
     Device/File Name         : /u01/app/11.2.0/grid/cdata/node1.olr

ocrcheck驗證完整性是根據安裝時生成的libocr11.so檔案的內容來檢查ocr/olr。如果ocrcheck檢查完整性失敗可以參考文件(ID 1617639.1)。

 

2. 轉儲OLR檔案

olr檔案為二進位制檔案,可以使用oracle提供的ocrdump工具進行轉儲,生成文字模式,方便了解檔案內容。

[root@node1 ~]# ocrdump -local
[root@node1 ~]# ls -ltr
total 284
drwxr-xr-x. 2 root   root       4096 Jan 10  2018 tmp
drwxr-xr-x. 2 root   root       4096 Jan 10  2018 scripts
...
-rw-r--r--. 1 root   root      10257 Nov 20 09:20 install.log.syslog
-rw-r--r--. 1 root   root      52196 Nov 20 09:23 install.log
-rw-------. 1 root   root       1717 Nov 20 09:23 anaconda-ks.cfg
-rw-------. 1 root   root     179399 Jan  8 22:05 OCRDUMPFILE

OLR與OCR檔案的資料儲存都是採用樹形結構,詳細資訊檢視dump後的檔案即可,這裡不再解讀。

cat OCRDUMPFILE 
# 輸出
05/31/2018 03:50:13
/u01/app/11.2.0/grid/bin/ocrdump.bin -local 

[SYSTEM]
UNDEF : 
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : root, GROUP_NAME : root}
... 
[SYSTEM.ORA_CRS_HOME]
ORATEXT : /u01/app/11.2.0/grid
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : root, GROUP_NAME : root}

##GI_HOME資訊
[SYSTEM.WALLET]
UNDEF : 
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_CREATE_SUB_KEY, OTHER_PERMISSION : PROCR_CREATE_SUB_KEY, USER_NAME : root, GROUP_NAME : root}
... 
[SYSTEM.version.activeversion]
ORATEXT : 11.2.0.4.0
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : root, GROUP_NAME : root}

##叢集版本資訊
[SYSTEM.GPnP]
UNDEF : 
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_NONE, OTHER_PERMISSION : PROCR_NONE, USER_NAME : grid, GROUP_NAME : oinstall}

##叢集初始化資源GPnP定義資訊
[SYSTEM.GPnP.profiles]
BYTESTREAM (16) : 
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_NONE, OTHER_PERMISSION : PROCR_NONE, USER_NAME : grid, GROUP_NAME : oinstall}

[SYSTEM.GPnP.profiles.peer]
UNDEF : 
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_NONE, OTHER_PERMISSION : PROCR_NONE, USER_NAME : grid, GROUP_NAME : oinstall}
…
[SYSTEM.network]
UNDEF : 
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : grid, GROUP_NAME : oinstall}

[SYSTEM.network.haip]
UNDEF : 
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : grid, GROUP_NAME : oinstall}

[SYSTEM.network.haip.group]
UNDEF : 
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : grid, GROUP_NAME : oinstall}

[SYSTEM.network.haip.group.cluster_interconnect]
UNDEF : 
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : grid, GROUP_NAME : oinstall}

[SYSTEM.network.haip.group.cluster_interconnect.interface]
UNDEF : 
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : grid, GROUP_NAME : oinstall}

##叢集初始化資源HAIP資訊
[SYSTEM.OCR]
UNDEF : 
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : root, GROUP_NAME : root}

##OCR資訊
[SYSTEM.OCR.BACKUP]
UNDEF : 
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : root, GROUP_NAME : root}
...

 

3. OLR檔案丟失導致的初始化資源層無法啟動

olr檔案丟失後,叢集啟動時alert日誌中會有明顯olr檔案無法讀取的錯誤資訊,如下:

2018-03-26 06:15:17.579: 
[ohasd(5219)]CRS-0704:Oracle High Availability Service aborted due to Oracle Local Registry error [PROCL-33: Oracle Local Registry is not configured Storage layer error [Error opening olr.loc file. No such file or directory] [2]]. Details at (:OHAS00106:) in /u01/app/11.2.0/grid/log/node1/ohasd/ohasd.log.

2018-03-26 06:15:17.733: 
[ohasd(5230)]CRS-0704:Oracle High Availability Service aborted due to Oracle Local Registry error [PROCL-33: Oracle Local Registry is not configured Storage layer error [Error opening olr.loc file. No such file or directory] [2]]. Details at (:OHAS00106:) in /u01/app/11.2.0/grid/log/node1/ohasd/ohasd.log.

2018-03-26 06:15:17.886: 
[ohasd(5241)]CRS-0704:Oracle High Availability Service aborted due to Oracle Local Registry error [PROCL-33: Oracle Local Registry is not configured Storage layer error [Error opening olr.loc file. No such file or directory] [2]]. Details at (:OHAS00106:) in /u01/app/11.2.0/grid/log/node1/ohasd/ohasd.log.

[client(5256)]CRS-10001:CRS-10132: No msg for has:crs-10132 [10][60]

後臺程式中,只有init.ohasd指令碼執行在後臺,初始化資源層中所有資源均未啟動。

ps -ef | grep -E 'ohasd|agent|gpnp|gipc|mdns' | grep -v grep
root     1332    1  0 20:53 ?   00:00:00 /bin/sh /etc/init.d/init.ohasd run

對於olr檔案丟失,只需要通過備份的olr檔案還原即可。

 

4. OLR檔案的備份與恢復

OLR檔案會在GI軟體安裝之後或者GI升級之後自動進行一次備份,OLR檔案並不會像OCR一樣自動進行備份,如果初始化資源層面的資源出現變動,建議手工備份OLR檔案。

  • 手動備份OLR
ocrconfig -local -manualbackup
  • 檢視OLR檔案的備份
ocrconfig -local -showbackup
  • 恢復OLR檔案
ocrconfig -local -restore <olr備份>

恢復時確保ohasd.bin未啟動,如果ohasd.bin仍在執行,請使用crsctl stop crs停止GI。

恢復OLR過程中如果出現PROTL-16:Internal Error錯誤,導致恢復失敗,可能是由於olr.loc檔案丟失導致。olr檔案還原時會讀取olr.loc檔案,將olr檔案恢復到olr.loc指定的位置。

ocrconfig -local -restore /u01/app/11.2.0/grid/cdata/rac1/backup_20180221_045700.olr
PROTL-16: Internal Error

可以嘗試建立虛擬OLR,設定正確的所有權和許可權,然後重試還原命令:

cd <OLR location> 
touch <hostname> .olr 
chmod 600 <hostname> .olr 
chown <grid>:<oinstall> <hostname> .olr

 

5. 驗證OLR檔案的完整性

可以使用Oracle提供的CVU進行OLR檔案的完整性驗證,但這裡的驗證並不檢查OLR檔案內容的邏輯完整性。如果需要同時驗證邏輯完整性,需使用ocrcheck -local進行驗證。

cluvfy comp olr
#輸出
Verifying OLR integrity 
Checking OLR integrity...
Checking OLR config file...
OLR config file check successful
Checking OLR file attributes...
OLR file check successful

WARNING: 
This check does not verify the integrity of the OLR contents. Execute 'ocrcheck -local' as a privileged user to verify the contents of OLR.

OLR integrity check passed
Verification of OLR integrity was successful. 

 

6. OLR檔案的自動備份

在12.2.0.1以上版本中,OLR檔案的自動備份功能作為BUG的一部分提供(BUG 26493466)

在18.1以及GI RU 12.2.0.1.180116中已包含OLR自動備份功能。

 

四、套接字檔案

套接字檔案是程式與程式之間雙向通訊的端點,是程式間通訊的一種約定。Oracle叢集在啟動時,首先讀取OLR檔案進行初始化資源層的啟動,並逐步實現叢集的啟動,在此過程中會在/var/tmp/.oracle目錄中建立相關叢集程式需要的套接字檔案。

套接字檔案是叢集執行過程中必不可少的檔案,在叢集執行過程中請不要刪除相關套接字檔案,如果套接字檔案丟失會導致一些不可預知的問題。

如下測試是在叢集執行過程,手工刪除/var/tmp/.oracle中的所有檔案後,通過crsctl檢查叢集狀態,輸出CRS-4535與CRS-4000以及CRS-4639,第一感覺是叢集未啟動,但實際情況是叢集與資料庫均執行正常。

crsctl stat res -t
#輸出
CRS-4535: Cannot communicate with Cluster Ready Services
CRS-4000: Command Status failed, or completed with errors.

crsctl check crs
#輸出
CRS-4639: Could not contact Oracle High Availability Services

ps -ef | grep -E 'ohasd|agent|mdns|gpnp|gipc|pmon' | grep -v grep
#輸出
root   1332 1  0 Jan20 ?  00:00:00 /bin/sh /etc/init.d/init.ohasd run
root   3829 1  0 Jan20 ?  00:01:19 /u01/app/11.2.0/grid/bin/ohasd.bin reboot
grid   3951 1  0 Jan20 ?  00:01:10 /u01/app/11.2.0/grid/bin/oraagent.bin
grid   3962 1  0 Jan20 ?  00:00:00 /u01/app/11.2.0/grid/bin/mdnsd.bin
grid   3973 1  0 Jan20 ?  00:00:11 /u01/app/11.2.0/grid/bin/gpnpd.bin
grid   3984 1  0 Jan20 ?  00:01:43 /u01/app/11.2.0/grid/bin/gipcd.bin
root   3986 1  0 Jan20 ?  00:02:18 /u01/app/11.2.0/grid/bin/orarootagent.bin
root   4030 1  0 Jan20 ?  00:00:16 /u01/app/11.2.0/grid/bin/cssdagent
grid   4390 1  0 Jan20 ?  00:00:05 asm_pmon_+ASM1
grid   4559 1  0 Jan20 ?  00:02:03 /u01/app/11.2.0/grid/bin/oraagent.bin
root   4567 1  0 Jan20 ?  00:02:17 /u01/app/11.2.0/grid/bin/orarootagent.bin
oracle 4769 1  0 Jan20 ?  00:01:44 /u01/app/11.2.0/grid/bin/oraagent.bin
oracle 4832 1  0 Jan20 ?  00:00:07 ora_pmon_oraapp1

對於套接字檔案丟失導致叢集執行不正常以及其他問題,最簡單的辦法就是重新啟動叢集,叢集在啟動時會重新建立需要的套接字檔案。

相關文章