部署Oracle 12c集群排障

數(shù)據(jù)庫作為生產(chǎn)系統(tǒng)的核心基礎(chǔ)，關(guān)于穩(wěn)定、可靠的要求從來都不會少，采用雙節(jié)點(diǎn)的高可用集群是非常普遍的解決方案，各種安裝部署的文檔也非常容易獲得。然而，實(shí)際環(huán)境的差異又帶來安裝過程中經(jīng)驗(yàn)之外的各種情況，需要各個(gè)擊破。

配置環(huán)境

本例的環(huán)境兩臺雙路物理服務(wù)器，操作系統(tǒng)采用rhel6.5x64安裝在服務(wù)器本地磁盤，共享磁盤連接到FCSAN存儲，劃分了2TB數(shù)據(jù)、3個(gè)50GB仲裁、2TB歸檔共5個(gè)卷，多路徑采用系統(tǒng)自帶multipath，分別設(shè)置兩個(gè)服務(wù)器啟動iptables防火墻相互放行集群中分配的所有IP和端口。

與11g比較preinstall操作的差異

RAC集群的安裝需要Grid用戶的ssh互信，在11g時(shí)代需要手工完成，即集群節(jié)點(diǎn)需要分別創(chuàng)建用于ssh的rsa密鑰對，并將自己的公鑰傳遞給其他節(jié)點(diǎn)的authorized_keys。理解和操作雖然不難，但步驟還是相對麻煩。在12c的Grid安裝向?qū)е校讶豢梢悦馊ナ止?chuàng)建，能夠在ui界面自動完成這一操作，大大方便了安裝前準(zhǔn)備。與此同時(shí)，Oracle用戶在database安裝時(shí)也需要配置ssh互信，這是11g所不需要的，同樣在ui界面上輕松完成。

limits.conf文 件 是LinuxPAM插入式認(rèn)證模塊（Pluggable Authentication Modules） 中 pam_limits.so的配置文件，它用于突破系統(tǒng)的默認(rèn)限制，對系統(tǒng)訪問資源有一定保護(hù)作用，需要分別設(shè)置Oracle和Grid兩個(gè)用戶的軟硬限制，通過oracle-rdbms-server-12cR1-preinstall這 個(gè)rpm包只添加了Oracle用戶的配置項(xiàng)，還需要手工補(bǔ)充Grid用戶配置項(xiàng)，并且Oracle用戶的配置寫到/etc/security/limits.d/oracle-rdbms-server-12cR1-preinstall.conf文件，Grid安裝ui的修復(fù)選項(xiàng)則是將配置項(xiàng)添加到/etc/sysconfig/limits.conf，在檢查配置時(shí)容易造成混淆。

除此之外，12c比11g還多出memlock配置，且要根據(jù)hugememory是否開啟而不同，memlock的大小依據(jù)free -t的total*0.9而定，多配或少配都會導(dǎo)致檢查警告。12c的文檔并沒有明顯說明/dev/shm的大小，但與11g中一致，仍需要設(shè)置和物理內(nèi)存一樣大，否則Grid自檢不通過。

自檢提示device checks for asm問題

Grid安裝ui自檢遇到device checks for asm問題，搜索后確認(rèn)是oracleasm configure -i初始化時(shí)沒有正確設(shè)置Grid用戶和asmdba用戶組導(dǎo)致的，而當(dāng)前創(chuàng)建的asm盤都是oracle:dba的權(quán)限，需要刪除磁盤調(diào)整。然而，在第一個(gè)節(jié)點(diǎn)始終無法刪除已創(chuàng)建的asm盤，即使用命令service oracleasm stop停止服務(wù)也不行，不過直接用真實(shí)路徑卻能夠順利刪除。

刪除檢查兩個(gè)節(jié)點(diǎn)的asm共享盤均已消失，重啟asm服務(wù)后重新添加。然而grid安裝的ui自檢仍提示相同的錯(cuò)誤，只是報(bào)錯(cuò)內(nèi)容已變成multipath相關(guān)，系多路徑聚合后的磁盤權(quán)限問題，當(dāng)前共享卷的在文件系統(tǒng)上的虛擬設(shè)備權(quán)限均為root:root，為asm能正確利用，也需要設(shè)置為grid:asmadmin權(quán)限。

先通過multipath –ll和/sbin/scsi_id -g -u /dev/sdx命令確認(rèn)每個(gè)共享盤的scsi_id和/dev/sdx對應(yīng)關(guān)系，然后以udev規(guī)則設(shè)定共享卷權(quán)限：

重啟操作系統(tǒng)后，再次執(zhí)行g(shù)rid安裝不再出現(xiàn)報(bào)錯(cuò)和警告。

節(jié)點(diǎn)二執(zhí)行root.sh失敗

Grid安裝進(jìn)行到末尾，需要分別在節(jié)點(diǎn)上執(zhí)行腳本，11g是需要人工執(zhí)行的，而12c則可勾選自動執(zhí)行節(jié)點(diǎn)上的腳本，為了偷懶勾選了自動執(zhí)行。第一個(gè)節(jié)點(diǎn)上腳本執(zhí)行順利無誤，在第二個(gè)節(jié)點(diǎn)執(zhí)行時(shí)遇到報(bào)錯(cuò)[INS-32148] Execution of ‘GI Install’ script failed on nodes: [rac2]。查看日志詳細(xì)信息，描述在第一個(gè)節(jié)點(diǎn)成功執(zhí)行完，而節(jié)點(diǎn)二無法在3600秒內(nèi)以root身份執(zhí)行，腳本在/u01/app/12.1.0/grid_1/crs/install/crsutils.pm的第3681行掛死掉。

上網(wǎng)搜索資料，有描述是multipath權(quán)限問題，有描述是安裝介質(zhì)存在Bug，需要在安裝過程中修補(bǔ)一個(gè)編號為18456643的補(bǔ)丁，官網(wǎng)的metalink對這一問題的解答也并不集中。由于介質(zhì)是成功安裝過rac的，故而暫時(shí)排除介質(zhì)問題，先從其他方面入手。

首先摸排腳本的執(zhí)行，通過命令/u01/app/12.1.0/grid_1/crs/install/rootcrs.pl -verbose-deconfig -force反向配置已執(zhí)行的腳本，然后重新執(zhí)行rootcrs.pl腳本。雖然順利通過了上述中斷的位置，但和心里預(yù)想的結(jié)果一樣，如果這樣能夠成功早就安裝成功了。為了排除腳本反復(fù)執(zhí)行的殘留等影響，決定先對兩個(gè)節(jié)點(diǎn)已安裝的Grid進(jìn)行卸載。

根據(jù)官方文檔，卸載當(dāng)前的Grid需要分別在兩個(gè)節(jié)點(diǎn)調(diào)用安裝介質(zhì)的腳本，命 令 為 ：runInstaller-deinstall -home /u01/app/12.1.0/grid_1/

兩個(gè)節(jié)點(diǎn)的腳本執(zhí)行都遇到無法刪除的對象，存在一些報(bào)錯(cuò)，但卸載總體認(rèn)為成功。重啟Linux并手工刪除/u01/app/grid/目錄下未自動清理的文件。

再次安裝Grid軟件，在自檢時(shí)又出現(xiàn)device checks for asm的 問題，這次報(bào)的還是/etc/multipath.conf權(quán)限問題。在兩個(gè)節(jié)點(diǎn)上都報(bào)相同的PRVG-5150錯(cuò)誤代碼，描述的是“無法確定路徑/dev/oracleasm/disks/OCRVOTE1是否在所有節(jié)點(diǎn)上都為有效路徑”。搜索官方文檔指向該問題是一個(gè)編號為18824041的Bug造成的，官方文檔的建議是忽略即可。雖然總覺得安裝過程有任何報(bào)錯(cuò)或警告都可能影響未來穩(wěn)定運(yùn)行，但既然官方文檔都這么說明了，暫時(shí)放下心中的糾結(jié)。安裝進(jìn)行到腳本執(zhí)行，這次手動分別在兩個(gè)節(jié)點(diǎn)執(zhí)行，節(jié)點(diǎn)一依然無任何報(bào)錯(cuò)，節(jié)點(diǎn)二卻又在腳本的914行出現(xiàn)了報(bào)錯(cuò)，主要為 CLSRSC-330、LSRSC-363、CRS-2883、CRS-4000等報(bào)錯(cuò)代碼。將這些報(bào)錯(cuò)代碼放到metalink檢索也未找到較為貼近的解答，只是從一個(gè)帖子的線索中觀察到當(dāng)前IP地址初始化在兩個(gè)節(jié)點(diǎn)上有一定差異，還無法確認(rèn)這個(gè)差異會產(chǎn)生什么樣的影響。

經(jīng)過了上述嘗試，問題的線索似乎越來越模糊，為避免不必要的糾纏，立即重新下載官網(wǎng)的安裝介質(zhì)，并對當(dāng)前環(huán)境進(jìn)行卸載。

采用新下載的Grid介質(zhì)在自檢時(shí)仍報(bào)device checks for asm警告，忽略該警告，當(dāng)出現(xiàn)手工執(zhí)行腳本的提示界面時(shí)，與上一個(gè)介質(zhì)有了明顯區(qū)別，說明確實(shí)存在介質(zhì)上的差異。執(zhí)行節(jié)點(diǎn)二的腳本，還是出現(xiàn)了報(bào)錯(cuò)，只是報(bào)錯(cuò)行與第一次碰到的一樣，問題回到了原點(diǎn)。

仔細(xì)回憶了一遍針對此問題所搜索過的資料，基本相信并確認(rèn)這一問題是Bug造成，需要打補(bǔ)丁。

下載完補(bǔ)丁18456643，直接在當(dāng)前腳本執(zhí)行中斷的情況下應(yīng)用補(bǔ)丁，不斷遇到無法調(diào)用、無法刪除、權(quán)限不夠等報(bào)錯(cuò)信息。雖然補(bǔ)丁最后顯示應(yīng)用成功，但卻并不能讓自己信服，于是再次卸載Grid軟件并重新安裝。

這次安裝進(jìn)行到彈出腳本執(zhí)行的提示，暫不執(zhí)行腳本，而先在兩個(gè)節(jié)點(diǎn)分別應(yīng)用補(bǔ)丁，相比前面的各種問題，補(bǔ)丁的應(yīng)用出奇的順利，似乎看到成功的曙光。打完補(bǔ)丁繼續(xù)執(zhí)行腳本，然而節(jié)點(diǎn)二還是報(bào)錯(cuò)，并且還是在前面遇到過的914行。介質(zhì)更換了，補(bǔ)丁也打成功了，自己也開始懷疑為何沒有突破，總是在同一個(gè)故障點(diǎn)繞圈圈。

針對當(dāng)前的/u01/app/12.1.0/grid_1/crs/install/crsinstall.pm終止在914行的報(bào)錯(cuò)，搜索的資料中再次出現(xiàn)了關(guān)于169.254.0.0的私有IP的信息，對此私有IP的獲取我是一直存疑的，按說所有物理接口都設(shè)置了靜態(tài)IP，不應(yīng)該再獲取該私有IP，同時(shí)該私有IP用于鏈路本地的端到端連接，想到這，忽然想是不是因?yàn)樵撍接蠭P參與通信，卻被防火墻攔截而導(dǎo)致問題呢？立即在兩個(gè)節(jié)點(diǎn)的iptables防火墻上放行這一地址段，重新執(zhí)行腳本，居然就順利執(zhí)行成功了。

為確保整個(gè)部署過程的可靠，再次卸載Grid并重裝驗(yàn)證，除了忽略device checks for asm警告，其余過程終于都完美無報(bào)錯(cuò)，這是為集群穩(wěn)定運(yùn)行奠定了基礎(chǔ)。

經(jīng)驗(yàn)總結(jié)

回顧上述處理過程，本質(zhì)問題集中在介質(zhì)和鏈路本地地址這兩個(gè)部分，都是出乎預(yù)料的，對于官網(wǎng)下載的介質(zhì)存在明顯的Bug在一開始都不太確信，對于防火墻則是一直以來的堅(jiān)持，做到節(jié)點(diǎn)間IP相互放行，禁止其他傳入的連接則能起到較好的防護(hù)效果，也能讓管理員更清楚集群節(jié)點(diǎn)在網(wǎng)絡(luò)中的傳入連接。