有關oracle高可靠性的一些討論和想法(1)

有關RAC的工作日誌：
12月16日到12月23日做RAC的試驗。12月24日把伺服器交給QYC做DataGuard.
QYC做完DataGuard試驗之後，1月4日我重新開始做RAC的試驗。

當初說是要做XX集團的雙機熱備,因為我應用oracle的時間非常短，對oracle並不熟悉，所以我這段時間就蒐集了
一些相關的資訊和資料，以供大家參考。
XX集團的應用我分析了一下，應該是不要求24*7連續工作的，只要能夠及時恢復訪問即可，而且資料量不是太大。
而且我原來讓XX方面做了NAT, 我們在這裡就可以進行遠端的控制，控制到XX集團內部的Intranet的個別伺服器。


我在網上所能搜到的資訊是高可用性解決方案分為4種，
一種是oracle提供的被用方法,Standby (=9i DataGuard)
一種是AR (高階複製Advanced Replication，在以前版本叫快照snapshot)
一種是oracle 並行伺服器8i的OPS (9i RAC,Real Application Cluster)
一種是第三方HA解決方案 （如Rose HA，故障切換時間是幾分鐘)

oracle公司的牛人著的裡也是
把這4種方法做為高可用方案的組成。

這幾種方案從原理上來講都很容易理解，但是實際上有相當多的細節和問題。

另外還有一種是大家都不太熟悉的是oracle 的 failsafe。
failsafe 採用的是SHARE NOTHING結構，即採用若干臺伺服器組成叢集，共同連線到一個共享磁碟系統，
在同一時刻，只有一臺伺服器能夠訪問共享磁碟，能夠對外提供服務.這與第3方HA方案的概念基本一樣。
但是 failsafe系統侷限於WINDOWS(winnt,win2k...)平臺，必須配合MSCS(microsoft cluster server).

我在網上找到現成的雙機熱備的文件 就是講在 oracle8i上如何做standby. 其保證了始終有一臺備用的
資料庫能夠在很短時間內透過人工，恢復正常的訪問，並保證資料一致。這是不要求24*7連續工作時所考慮的方案。

我們所能做試驗的就是前三種方案，因為人手有限，所以就做了9i的DataGuard 和RAC 兩種方案的試驗。
高階複製據說lwd在很久以前做過。我打電話問oracle公司，他說AR對資料庫的效能影響太大。
高階複製也分為兩種情況
1.主動／被動策略: node1處於主動模式，資料庫可讀寫，node2處於被動模式，資料庫只讀。
2.主動／主動策略: node1和node2 都處於主動模式，資料庫都可讀寫。這種對資料庫的效能影響特別大。


在講述DataGuard和RAC這兩種方案之前，我先補充一點關於oracle Client 如何能夠不修改本機配置就能
訪問兩臺oracles資料庫的方法。
也就是修改本機的tnsname.ora
一個通常的tnsname.ora 如下：
RACDB =
(DESCRIPTION =
(LOAD_BALANCE = off)
(failover = on)
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 211.68.29.61)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = 211.68.29.62)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = racdb)
)
)
在 ADDRESS_LIST 中 寫了兩個地址，client 透過oracle net 在訪問時，如果訪問不通第一個ip,就會訪問第2個ip.
這個特性是早就有了的。load_balance 特性也是有的。但是在兩臺資料庫內容不一致的情況下是沒有任何意義的。
不過，在oracle9i 的官方pdf中，load_balance 特性是不推薦使用的。

RAC 的試驗我昨天已經做成了，雖然遇到了一些不大不小的Bug和不穩定現象。
環境是oracle9.2.0.1.0 , 2* RedHatAdvanceServer 2.1 和一個磁碟陣列, 採用的是裸裝置。
RAC 是share everything 模式，兩個資料庫例項同時共享同一套資料檔案，控制檔案，日誌檔案。
客戶端可以同時訪問這兩臺資料庫得到的資料都是一致的，它的重點是高效能,可擴充套件性。但是可靠性是不如DataGuard的。
因為首先在物理上是連線在一起的，是沒法容災的。
其次，instance1 死掉的話，可能可能影響instance2。
(Oracle 公司的電話支援說的， 以及網上的論壇中有相關的例子，一個例項down機拖累另一臺不能正常工作,
我在做RAC試驗的時候，也出現了node1 重起，造成node2也重起的個別現象)
當然了，與單機的oracle相比，可用性肯定是高的。

另外網上我所能找得到的RAC成功案例(論壇oracle版主之類實施)，無一例外都是oracle經過認證的伺服器硬體和軟體.
例如HP,DELL PowerEdge伺服器。DELL/EMC fiber-channel storage array 等等。
另外，因為沒有多餘交換機，4塊網路卡中的進行內部通訊用的兩塊網路卡我採用的是直接級聯
(新聚思公司的oracle支援說這樣不穩定，但是為什麼不穩定也沒有說原因)

有關共享檔案系統的一些問題：
採用裸裝置無法進行日常管理，也沒有辦法進行檔案系統級的備份。
開始我第一次在Mandrake8.1的時候，對陣列進行分割槽，而fdisk在linux下只能分16個分割槽，我只好採用
lvm（logical volume manager，支援256個)對裸裝置進行管理。後來在dbca建立資料庫的最後階段無法建立，只好作罷。
第二次用RedHat AS2.1，oracle網站新推出了針對ocfs，我將其2003-1-3 更新的有關ocfs的所有rpm包(只適用
於AS2.1）安裝上，但是卻發現無法正常載入ocfs module, 我查了好久，估計這與我們所用的世紀曙光硬體有關，
採用的AMD雙Athlon MP 1800+ 以及相關主機硬體，RedHat AS 2.1 無法正常認出，從而造成ocfs modules也無法
正常載入，因為ocfs modules與kernel是相關的。或許換成intel 的雙cpu, 或換成單cpu ，然後重灌系統就可以解決。
因為rhAS2.1的核心不支援 lvm, 需要重新編譯核心才能支援，我只好 將磁碟陣列分成2個drive,分別進行了
分割槽，跳過了fdisk分割槽數量限制，給oracle提供了足夠多的裸分割槽。
當初做方案時買的vertris 的冷備份軟體(大概10萬元)是隻能在oracle停機時透過smb來copy 檔案進行備份到磁帶裡的。
而裸裝置是沒有辦法copy 的。

客戶端在tnsname.ora配好address_list後，
當nodeA 停機時，是可以不用修改配置訪問到nodeB 的。
但是這也分很多種情況
nodeA down,
listenerA down,
InstanceA down,
InstanceA in indeterminate state,
session die等等。
並非每種情況都能實現自動轉到node2上。


第三方HA軟體是靠自己的agent軟體檢測模組按照自己的故障判斷標準進行強制轉換的。第一臺肯定不會被訪問到，
在幾分鐘之後所有的訪問都會訪問到第二臺剛剛起來的資料庫上。
oracle 要想實現與第三方HA軟體一樣的功能，只能與microsoft cluster server一起 在windows平臺
上實現failover.
除此之外，oracle本身的幾種High Available 方案是不提供與此類似的自動failover功能的。
RAC提供並行；
standby/dataguard提供熱備份伺服器(需要人工維護切換)；
AR 可以基本實時提供兩臺資料一致的資料庫，但是資料庫效能受影響。而且客戶端能否在各種各樣的情況下都自動
切換到第二臺資料庫上我也不知道。(例如listener running, instance down時無法切換到第二臺)
主資料庫發生災難，無法訪問的情況下應該是能夠切換的，但是有些情況下，只需要修改
tnsname.ora或者停掉node1的listener即可。


以前曾經有人在職成網做過 RoseHA+oracle817+Turbolinux的整合方案, 據說效果也非常差。我所看到我們這裡的人去職成網
進行維護N多次。(N非常大) 所以在整合方案中如果用到了oracle資料庫，就準備好有人長期進行維護，主資料庫
在萬一情況下發生災難，只要有一臺熱的備用資料庫能夠在比較短(電話通知之後1天之內)的時間內繼續投入使用
就達到了可用性的目的，不至於主資料庫損壞，重新進行安裝恢復佔用星期級的時間。
要想達到failover自動切換，無需人的參予是一種理想化狀態，在unix平臺上無法實現，windows平臺上的oracle failover
我不太清楚，應該是能實現這個想法的。

standby備用資料庫 是在oracle7.x才開始提供的一項功能，到了oracle8i才能提供read only模式，
到了9i 才使日誌應用等實現了自動化，但是這個自動化不是故障切換自動化，而是隻為了實現熱備份資料庫的功能完善而
增加的一些自動化。 歸根到底，oracle公司開發這麼久，還沒有開發完善這些高可用方案，只是一直處於完善階段。
RAC的並行提供服務我從一些oracle技術支援那裡聽來的說法也是最好一臺用來做讀寫，另一臺專門提供只讀操作的查詢，
不然仍然影響效能。用來做我們這種failover應用的倒不多。
很容易理解的一些稍微複雜的原理，要想在實際中應用是需要大量時間的，裡面所涉及到的眾多細節如日誌增量等等很麻煩。
就連oracle9.0.0.1在linux下的OUI(oracle univesal installer) 安裝程式在它認證的linux上執行也是一堆Bug.
也就是它的jre有毛病，所以我當初在mandrake8.1上建立資料庫出現了問題，無法進行下去。
特定的環境，特定的問題，很多都是沒有解釋的。這是網上的一個DBA的原話。
網上也有oracle81700升級到81740就出故障的案例。



使用DataGuard(standby) 是不能實現故障的自動切換的，因為據oracle公司的人說無從判斷究竟算什麼樣的故障才開始進行轉移，
這個已經超出oracle軟體本身的範圍了。或許可以透過自己編寫程式來按照自己的標準來進行判斷和轉移。
但是DataGuard做到了始終有一臺資料庫與主資料庫保持一致。在加上客戶端的tnsname.ora的addresslist在一定程度上
是可以實現部分的故障切換的。
備資料庫平時只能處於read only或 recovery manage 模式。
read only 不能應用主資料庫傳來的重作日誌，recovery manage 可以進行資料恢復，但是不能被客戶端訪問。
備用資料庫經常處於修復狀態，因此不能被終端使用者使用，這從管理角度是一種浪費(所以8i開始提供了read only模式)。

我的想法是
1. 主資料庫發生災難，被迫關閉，XX方面打電話通知過來，我們透過遠端由人工啟用備用的資料庫即可。也就是敲幾行sql命令即可。
完全可以寫成指令碼，隨便找一個人執行一下即可。

2. 備資料庫白天處於read only 模式，可供webserver(也就是客戶端)查詢，晚上12點到1點透過cron 執行在recover managed模式，
將白天主資料庫的更改應用到備資料庫上。

3. 透過cron將備資料庫白天處於 primary 模式，可讀可寫，晚上透過指令碼改回standby模式，並且應用主資料庫的更新。
這樣當主資料庫down機，客戶端會立刻連到第二臺資料庫上，同時也能夠進行讀寫。資料分歧只有一天，並且達到了無人
切換狀態。

這3種方法，第1種是最好的。
第2種是可行的，是oracle官方認可的，有資料分歧，和只讀的侷限性。
第3種有資料分歧並且有或大或小的細節問題沒有考慮，只是我的一個臨時想法。


在RAC 和 DataGuard 這兩種方案中，
RAC對硬體和作業系統要求都比較高，維護也非常複雜，我們買的vertas 備份軟體也沒有辦法使用冷備的檔案。
對人員的素質要求也很高。
隨便舉個例子，RedHat AS 2.1 如果認不出SCSI driver，就沒法做了。因為oracle9.2i只能用這個作業系統。
( webmail沒有用mandrake8.1而是用mandrake8.2就是這個原因)
不確定因素太多。
在做系統整合方案和買硬體時都要仔細考慮，買什麼樣的伺服器，陣列，網路卡，幾個交換機，linuxAS21能否裝上等等。
而不是隨便寫個雙機熱備，買兩個伺服器，一個交換機就行了。

不過這個方案可以用在我們自己的機房裡，提供高效能的oracle資料庫服務。(但是需要比較多的時間來準備和除錯）。
我現在只能做到把oracle92i裝起來，具體平時的管理還要靠有資料庫使用經驗的其他同事來做。
安裝文件我放在附件裡了。
如果要應用到XX集團方案中，人員的出差以及硬體，所消耗時間等都需要考慮，我沒有把握能再成功裝一遍。


DataGuard對條件的要求就很低了，只要隨便兩臺一模一樣的資料庫就行，不用管作業系統和硬體，網路只需要聯通即可。
在主資料出問題時，可以迅速恢復到第二臺上。也就是oracle8i裡俗稱的雙機熱備。(實際上不止1臺熱備機，可以一個主資料庫
帶多個備資料庫）
我們在XX處實施時，只需要在這裡裝好，然後將兩個資料庫打包透過ftp 傳到XX處，然後展開即可執行，也不需要重新安裝作業系統和
更改硬體。
網速很快，我原來傳過一些上G的檔案，也就是幾個小時。

要想達到比較理想化的狀態，在客戶端能夠自動避開有故障的資料庫訪問沒有問題的資料庫的話，
比較接近這種想法的方案就是AR高階複製的雙主動模式，但是oracle公司的技術支援不推薦使用。
我們這裡可以找人試一下。lwd用資料庫很久了，他以前做過。


實際上如果主資料庫癱瘓，是需要人遠端干預的， 而oracle的客戶端只有2個webserver，修改不修改本機的tnsname.ora都無所謂，
都能夠實現正常的訪問，修改webserver 本機的tnsname.ora的時間也是不用考慮的。應用程式也是無需修改的。
另外，oracle 提供的TAF(Transparent Application failover)在實際用途中是意義不大的。[@more@]