以下是基于Tier 1銀行的真實(shí)情況。我們使用的是Sybase 工具，例如ASE和Replication Server，但是這個案例也非常適用于其他的引擎，如帶有數(shù)據(jù)防護(hù)(Data Guard)的Oracle等。

我去年在一家大銀行工作，我們有一段損失慘重的經(jīng)歷，最后由復(fù)制挽救了我們。現(xiàn)在，我深信任何的基于硬件的解決方案，例如集群，無論如何也比不上基于軟件的解決方案，例如復(fù)制。只要你稍微具有一點(diǎn)靈活性和思想就能獲得同樣的效果的時候，為什么花費(fèi)大量的金錢在硬件集群上呢?我會在以下的內(nèi)容中闡述我的觀點(diǎn)。

Peter Thawley 的一篇名為《互聯(lián)網(wǎng)時代的高可用性》("High Availability in the Internet Age")的文章中的觀點(diǎn)非常吸引我。這篇文章發(fā)表在國際Sybase用戶組織(ISUG)雜志的1999 第三版上。作者提出，eBay所遇到的不能正常運(yùn)行的時間就是硬件錯誤導(dǎo)致的Oracle數(shù)據(jù)庫錯誤引起的。裝載Oracle數(shù)據(jù)庫花了大約24小時，與此同時，公司損失了大量收入。不論是什么引起了這次的故障時間，其中有一個就可能是體系結(jié)構(gòu)和為此錯誤承擔(dān)責(zé)任的數(shù)據(jù)庫管理員。雖然錯誤是由于硬件的問題，很少是由于冗余(redundancy)和鏡像(mirroring)，但是它們確實(shí)可能會引起這種情況。

我所工作的銀行有一個交易系統(tǒng)，已經(jīng)運(yùn)行了兩年。它具有較大的數(shù)據(jù)庫，大概有70GB，使用的是Solaris 2.7 and Sybase 11.9.2 (按照今天的標(biāo)準(zhǔn)就是石器時代了)。他們非常努力地為這個數(shù)據(jù)庫去創(chuàng)建一個合適的防范業(yè)務(wù)風(fēng)險機(jī)制(business contingency，BC)。關(guān)鍵問題就是一個交易必須要寫入數(shù)據(jù)庫并且使用者界面要在3秒鐘內(nèi)顯示出來交易條目的確認(rèn)信息。這個系統(tǒng)必須具有處理每小時6萬個交易輸入復(fù)制的能力，并且從產(chǎn)品到BC的交易傳遞必須要以能夠最小化或者消除所有的交易損失的方式進(jìn)行設(shè)計。系統(tǒng)還必須機(jī)有支持300個在線交易人的能力。

在網(wǎng)站的兩個星期里面，我們使用Sybase復(fù)制創(chuàng)建了業(yè)務(wù)持續(xù)性系統(tǒng)，具有處理以上關(guān)鍵問題的能力。到了11月的中期，我們將系統(tǒng)投入產(chǎn)品和客戶端在周末做了一些初始化的測試，確認(rèn)了復(fù)制間斷性的工作以及交易傳遞到BC站點(diǎn)上。有趣的就是這個故事剩下的部分。

在一個決定性的工作日的下午，災(zāi)難來臨了，數(shù)據(jù)服務(wù)器的硬件出現(xiàn)了問題。Sybase錯誤日志開始發(fā)送如下的信息:

00:00000:00000:2003/xx/xx xx:xx:xx.xx kernel sddone: write error on virtual
disk 2 block 8601952:
00:00000:00000:2003/xx/xx xx:xx:xx.xx kernel sddone: I/O error
09:00000:00757:2003/xx/xx xx:xx:xx.xx server Error: 694, Severity: 24,
State: 10
09:00000:00757:2003/xx/xx xx:xx:xx.xx server An attempt was made to read
logical page '11311459', virtpage '42156387' from virtual d
evice '2' for object '1723869208' in database '5'. The page was not read
successfully. You may have a device problem or an operating
system problem.
00:00000:00006:2003/xx/xx xx:xx:xx.xx server Error: 823, Severity: 24,
State: 2
00:00000:00006:2003/xx/xx xx:xx:xx.xx server I/O error detected during wait
for BUF pointer = '0xb8b3d5a0', MASS pointer = '0xb8b3d5
a0', (Buf#: '0'), page ptr = '0x9801c000', dbid = '5', Mass virtpage =
'42156384', Buffer page = '11311456', Mass status = '0x4689110
0', Buffer status = '0x1', size = '16384', cache (id: 0) = 'default data
cache'.
09:00000:00757:2003/xx/xx xx:xx:xx.xx kernel

ASE運(yùn)行在E4500 服務(wù)器上，有兩臺Sun A5200陣列用于數(shù)據(jù)存儲。問題就是一個完全的陣列由于一個磁盤的錯誤而是去了控制!你可以對找個原因進(jìn)行爭辯。然而，它看上去就像是這個類型的陣列的內(nèi)在設(shè)計問題。(在A5200的三個特定的磁盤插槽上，你需要插入磁盤。這些磁盤習(xí)慣重復(fù)發(fā)送“fcal”信號，并且其中的一個錯誤和fcal信號沒有達(dá)到的時候，陣列就會出現(xiàn)問題。)因?yàn)槲覀冇袃蓚€陣列，我們期望鏡像陣列可以挽救我們。不幸的是，這種情況沒有出現(xiàn)。

問題是雖然存儲陣列中的一個已經(jīng)失去了控制，Sybase設(shè)備被重新安置在一個卷上，在這個卷上含有損壞的磁盤和它的鏡像在同一個陣列中。依次追蹤到了幾個月之前在一個陣列中做了熱交換的Veritas ，這就是最初收到影響的磁盤。由于人的錯誤，這個問題一直沒有檢測出來或者是被忽略了。所以當(dāng)單個陣列在寫入數(shù)據(jù)的過程中失敗的時候，交易數(shù)據(jù)庫中就出現(xiàn)了一個洞。

我想要指出的一點(diǎn)是有關(guān)我們進(jìn)行恢復(fù)的速度。我們檢測了BC數(shù)據(jù)庫以及在崩潰之前2分鐘寫入數(shù)據(jù)庫的最后的交易條目。計數(shù)器顯示這個交易條目確實(shí)是最后已過進(jìn)入交易系統(tǒng)的交易。在這個情況下，我們能做的就是交換接口文件并請求用戶重新開啟他們的應(yīng)用程序。當(dāng)我們對BC數(shù)據(jù)庫進(jìn)行完整的測試，系統(tǒng)又顯示良好了，所以這個信號又關(guān)閉了!

最根本的問題就是是否以硬件級別的磁盤鏡像形式出現(xiàn)的硬件冗余可以對數(shù)據(jù)庫提供完善的保護(hù)。許多組織都傾向于使用局域(傳統(tǒng)的磁盤鏡像)或者廣域(存儲區(qū)域網(wǎng)絡(luò))硬件鏡像來創(chuàng)建冗余和彈性。例如，EMC的SRDF就是一個硬件層次上對距離進(jìn)行了擴(kuò)展的冗余解決方案。作為一個選項(xiàng)，軟件復(fù)制可以被采用。我將在下面解釋我為什么傾向于軟件解決方案。

作為一名從業(yè)人員，我一直認(rèn)為以數(shù)據(jù)復(fù)制的方式(雖然在某種程度上是異步的)完成的軟件高可用性(HA)解決方案優(yōu)于基于硬件的磁盤到磁盤景象。下面我提出的論據(jù)是基于如下的公理，即雖然數(shù)據(jù)庫是構(gòu)建在文件系統(tǒng)或者原始分區(qū)上，他們的根本行為是以純粹的文件系統(tǒng)不同的方式進(jìn)行。實(shí)際上，假設(shè)磁盤到磁盤、比特到比特的鏡像會對你的數(shù)據(jù)提供充分的保護(hù)的觀點(diǎn)是過于簡單化了。

高可用性磁盤到磁盤鏡像最常見的形式就是為了從基本磁盤到鏡像磁盤的比特到比特的數(shù)據(jù)拷貝設(shè)計的。只要兩個磁盤所處位置之間的距離不是太大，并且在兩個站點(diǎn)之間由GB級別的快速連接存在，寫入就幾乎是同時發(fā)生的。第一眼看過去，這樣的解決方案看起來是完美的;他們幾乎可以是可以立即產(chǎn)生效果的。在本地或者遠(yuǎn)程聚簇上面應(yīng)用這樣的解決方案，我們可以得到數(shù)據(jù)的高可用性。

在實(shí)際中，數(shù)據(jù)庫比一個單純的逐個比特拷貝要復(fù)雜得多。數(shù)據(jù)庫引擎在基于進(jìn)程的RDBMSZ，例如Oracle中，通過后臺進(jìn)程，或者在基于線程模型的數(shù)據(jù)庫，例如Sybase中，通過內(nèi)部進(jìn)程執(zhí)行了許多任務(wù)。這些進(jìn)程執(zhí)行例行任務(wù)，例如檢測點(diǎn)和那些維護(hù)數(shù)據(jù)庫必需的事務(wù)日志和數(shù)據(jù)的沖洗，但是實(shí)際上這些都與數(shù)據(jù)的可用性沒有關(guān)系。換句話說，大多數(shù)此類形式的數(shù)據(jù)都不需要被拷貝或者復(fù)制。比較而言，在基于數(shù)據(jù)復(fù)制的高可用性設(shè)計中，這些多余的數(shù)據(jù)永遠(yuǎn)不會被復(fù)制，因?yàn)槿藗冋J(rèn)為它對于BC數(shù)據(jù)庫而言實(shí)際上并不需要。這就給我們指出了軟件復(fù)制是如何與硬件鏡像區(qū)別開來的。

復(fù)制的形式通常是在表級別上的事務(wù)(插入、更新和刪除)，從一個源數(shù)據(jù)庫到一個或多個目標(biāo)數(shù)據(jù)庫。比起硬件鏡像，它基本上要么是全部要么是一點(diǎn)也不，但復(fù)制:

將數(shù)據(jù)從一個源移動到另一個。

只將一部分?jǐn)?shù)據(jù)子集從源移動到目標(biāo)。所以你可以描述數(shù)據(jù)的子集;例如，復(fù)制被選中的表。

在從源移動到目標(biāo)的過程中，允許處理/轉(zhuǎn)換數(shù)據(jù)。

這指出了使用復(fù)制技術(shù)獲得可用性的另一個好處。通常客戶們使用磁盤鏡像和磁盤快照技術(shù)來維護(hù)熱數(shù)據(jù)庫，通常付出較高的成本。這些技術(shù)在實(shí)際問題方面，例如磁盤上的壞扇區(qū)，效果良好。然而，如果有I/O設(shè)備或者數(shù)據(jù)庫管理軟件層上由于軟件錯誤發(fā)生的數(shù)據(jù)損壞，這個損壞只會簡單地傳播到遠(yuǎn)端的設(shè)備上!由于Sybase Replication Server 是在邏輯層通過將事務(wù)轉(zhuǎn)換為復(fù)制服務(wù)器上面的SQL 操作進(jìn)行處理，那么這個風(fēng)險就被完全避免了。