文章詳情頁
DB2的高可用性和災(zāi)難恢復(fù)概述
瀏覽:6日期:2023-11-10 18:58:17
【導(dǎo)讀】數(shù)據(jù)的高可用性和災(zāi)難恢復(fù)的能力是對(duì)要害數(shù)據(jù)庫系統(tǒng)的主要需求。本文概述了 DB2 UDB 的特性,這些特性提供了這些能力,并且讓您知道它們的優(yōu)缺點(diǎn),這樣您就可以判定哪種方法最適合您。簡介高可用性和災(zāi)難恢復(fù)是要害數(shù)據(jù)庫應(yīng)用程序的重要需求。IBM DB2 通用數(shù)據(jù)庫(DB2)提供了許多特性來滿足這些需求。假如您還不熟悉分布式平臺(tái)上的 DB2,或者即使您已用了一段時(shí)間,您也許仍會(huì)覺得處理可用性和恢復(fù)的許多特性令人感到迷惑。您何時(shí)使用哪一種特性,當(dāng)您使用它時(shí),您可以希望完成什么?本文旨在概述這些特性,并指導(dǎo)您理解如何使用 DB2 技術(shù)來構(gòu)建高度可用和可恢復(fù)的數(shù)據(jù)庫系統(tǒng)。此外,每種解決方案都有其成本以及獨(dú)有的優(yōu)點(diǎn),因此我們將討論它們的優(yōu)缺點(diǎn)。在開始之前,讓我們先研究術(shù)語高可用性(high availability,HA)和災(zāi)難恢復(fù)(disaster recovery,DR)。在運(yùn)用 HA 和 DR 的技術(shù)中,它們經(jīng)常有相交的地方,但它們有兩個(gè)不同的用途。高可用性是這樣一種需求:每當(dāng)需要時(shí),數(shù)據(jù)就可用于從屬應(yīng)用程序。其目的是消除或最小化停機(jī)時(shí)間。災(zāi)難恢復(fù)防止由于毀滅性的故障而導(dǎo)致數(shù)據(jù)丟失。這類故障意味著由于不可恢復(fù)的情況而丟失數(shù)據(jù)。術(shù)語和客戶機(jī)/服務(wù)器數(shù)據(jù)庫體系結(jié)構(gòu)我們將首先討論一些術(shù)語和概念,當(dāng)討論高可用性和災(zāi)難恢復(fù)時(shí),應(yīng)該要理解這些術(shù)語和概念。在數(shù)據(jù)庫體系結(jié)構(gòu)討論中經(jīng)常會(huì)用到術(shù)語 群集(cluster)。有兩種類型的 DB2 數(shù)據(jù)庫群集: 高可用性和 高可伸縮性(high scalability)。雖然在一個(gè)解決方案中可以結(jié)合這兩種群集,但應(yīng)該將它們看作是互斥的實(shí)體。高可伸縮性群集(也稱作數(shù)據(jù)庫分區(qū))結(jié)合了多臺(tái)服務(wù)器的聚集能力以產(chǎn)生高性能解決方案。該技術(shù)通常用于構(gòu)建數(shù)據(jù)倉庫或大型事務(wù)系統(tǒng),而在這樣的數(shù)據(jù)倉庫或系統(tǒng)中,單個(gè)服務(wù)器是無法實(shí)現(xiàn)性能目標(biāo)的。高可用性群集產(chǎn)生一個(gè)能最大化數(shù)據(jù)庫正常運(yùn)行時(shí)間的系統(tǒng)。在本文中,術(shù)語“群集僅指高可用性群集。HA 數(shù)據(jù)庫解決方案有三個(gè)部分:用戶應(yīng)用程序客戶機(jī)軟件數(shù)據(jù)庫引擎當(dāng)設(shè)計(jì) HA 解決方案時(shí),應(yīng)該考慮所有這三個(gè)方面。僅使數(shù)據(jù)庫引擎成為高度可用并不一定能創(chuàng)建出 HA 解決方案。本文的重點(diǎn)是數(shù)據(jù)庫引擎正常運(yùn)行時(shí)間,但您應(yīng)該將這一問題看作只是整體解決方案的一部分。數(shù)據(jù)庫應(yīng)用程序是基于客戶機(jī)/服務(wù)器的。應(yīng)用程序依靠數(shù)據(jù)庫軟件的完整性來產(chǎn)生一致的結(jié)果。雖然這看起來似乎相當(dāng)明顯,但當(dāng)選擇和設(shè)計(jì)解決方案時(shí)理解如何實(shí)現(xiàn)這一點(diǎn)非常重要。當(dāng)應(yīng)用程序提交 SQL 事務(wù)時(shí),在可以假設(shè)事務(wù)完成之前它必須接收返回碼。應(yīng)用程序并不與數(shù)據(jù)庫引擎直接交互。事務(wù)經(jīng)由客戶機(jī)軟件傳遞到引擎。由客戶機(jī)軟件將響應(yīng)返回給應(yīng)用程序。正的返回碼表示成功的情況,而負(fù)的返回碼表示失敗。應(yīng)用程序如何處理這些情況對(duì)于整體 HA 解決方案很重要。通過包含返回碼邏輯,尤其是關(guān)于事務(wù)失敗的,應(yīng)用程序可以使 HA 解決方案對(duì)于最終用戶顯得更加天衣無縫。數(shù)據(jù)庫引擎通過實(shí)現(xiàn)事務(wù)日志來確保完整性,事務(wù)日志存儲(chǔ)了所有插入、更新和刪除活動(dòng)。事務(wù)日志確保了數(shù)據(jù)庫更改只在應(yīng)用程序發(fā)出提交語句后接收到正的返回碼時(shí)才算完成。事務(wù)日志是 HA 和 DR 解決方案的基礎(chǔ)部分。在可以提交 SQL 事務(wù)之前,必須建立到數(shù)據(jù)庫的連接。CONNECT 語句用于建立數(shù)據(jù)庫連接,但有一些基本特性會(huì)影響連接被路由到哪里。客戶機(jī)軟件有兩個(gè)目錄告訴它如何路由數(shù)據(jù)庫連接嘗試:節(jié)點(diǎn)目錄(node directory)列出了服務(wù)器的位置(服務(wù)器的 IP 地址或主機(jī)名)和數(shù)據(jù)庫服務(wù)器用于偵聽數(shù)據(jù)庫連接嘗試的端口。數(shù)據(jù)庫目錄(database directory)列出了數(shù)據(jù)庫名稱、數(shù)據(jù)庫別名和節(jié)點(diǎn)目錄中用于建立連接的對(duì)應(yīng)項(xiàng)。當(dāng)應(yīng)用程序發(fā)出 CONNECT 語句時(shí),會(huì)搜索數(shù)據(jù)庫目錄來查看是否存在這個(gè)數(shù)據(jù)庫名或數(shù)據(jù)庫別名。假如這一項(xiàng)的類型是“indirect,那么數(shù)據(jù)庫是本地的,并通過共享存儲(chǔ)段建立該連接。假如這一項(xiàng)的類型是“remote,那么節(jié)點(diǎn)名用于指向節(jié)點(diǎn)目錄中的正確項(xiàng)。節(jié)點(diǎn)目錄信息答應(yīng)客戶機(jī)軟件正確路由連接嘗試。通過了解客戶機(jī)如何通過目錄結(jié)構(gòu)建立數(shù)據(jù)庫連接,在您規(guī)劃 HA 解決方案時(shí)就可以規(guī)劃資源移動(dòng)。高可用性選擇高可用性解決方案很大程度上取決于客戶的業(yè)務(wù)需求。有兩種類型的高可用性可供選擇: 持續(xù)可用性(continuous availability)和 故障轉(zhuǎn)移可用性(failover availability)。持續(xù)可用性持續(xù)可用性要求數(shù)據(jù)庫引擎可隨時(shí)用于處理 SQL 事務(wù)。這類可用性通常只在最要害的應(yīng)用程序中實(shí)現(xiàn)。要實(shí)現(xiàn)這個(gè)目標(biāo),要求百分之百的冗余。那意味著您必須有兩個(gè)完全互相獨(dú)立(包括在硬件和軟件方面)的系統(tǒng)。基本上,SQL 事務(wù)在這兩個(gè)系統(tǒng)上發(fā)生。一個(gè)系統(tǒng)發(fā)生故障不會(huì)造成其伙伴系統(tǒng)上事務(wù)的處理發(fā)生中斷。要使這成為現(xiàn)實(shí),應(yīng)用程序必須知道這兩個(gè)系統(tǒng),并且將每個(gè)事務(wù)實(shí)現(xiàn)為跨兩個(gè)系統(tǒng)的 分布式工作單元(distributed unit of work,DUOW)。DUOW 是作為在系統(tǒng)之間協(xié)調(diào)的一個(gè)事務(wù)而執(zhí)行的一系列 SQL 語句。應(yīng)用程序?qū)⑹聞?wù)提交給這兩個(gè)系統(tǒng),并從這兩個(gè)系統(tǒng)接收關(guān)于成功或失敗的返回碼。然后應(yīng)用程序可以繼續(xù)處理另一個(gè) DUOW 或執(zhí)行另一種操作。假如發(fā)生故障,其中一個(gè)數(shù)據(jù)庫系統(tǒng)不能再為應(yīng)用程序提供服務(wù),則應(yīng)用程序(被編碼為可以捕捉該錯(cuò)誤)可以利用另一個(gè)系統(tǒng)繼續(xù)處理它的工作負(fù)載,而不會(huì)發(fā)生中斷。要實(shí)現(xiàn) DUOW 需要類型 2 數(shù)據(jù)庫連接和事務(wù)監(jiān)視器。類型 2 數(shù)據(jù)庫連接建立了適合于 DUOW 的環(huán)境。事務(wù)監(jiān)視器負(fù)責(zé)實(shí)現(xiàn) DUOW 并確保完成或回滾 DUOW 中的事務(wù)。DB2 可以充當(dāng)事務(wù)監(jiān)視器或者您可以使用另一家軟件供給商(如 Microsoft 或 BEA)的事務(wù)監(jiān)視器。圖 1說明了通過使用 DUOW 提供的持續(xù)可用性解決方案。圖 1. 分布式工作單元
表 1. 持續(xù)可用性解決方案的優(yōu)缺點(diǎn)優(yōu)點(diǎn): 缺點(diǎn): 100% 正常運(yùn)行時(shí)間需要重復(fù)的硬件需要額外的應(yīng)用程序編碼現(xiàn)在,我們將轉(zhuǎn)到下一個(gè)高可用性解決方案。故障轉(zhuǎn)移可用性故障轉(zhuǎn)移可用性與持續(xù)可用性的區(qū)別在于:數(shù)據(jù)庫引擎會(huì)有一段時(shí)間(盡管時(shí)間很短暫)無法用于事務(wù)處理。這種解決方案的基本元素有:主系統(tǒng)和輔助系統(tǒng)故障檢測(cè)數(shù)據(jù)源移動(dòng)兩個(gè)系統(tǒng)都有數(shù)據(jù)庫數(shù)據(jù)的副本,當(dāng)檢測(cè)到故障時(shí),就會(huì)發(fā)生 故障轉(zhuǎn)移。在故障轉(zhuǎn)移過程中,數(shù)據(jù)源從主系統(tǒng)移到輔助系統(tǒng)。有兩種故障轉(zhuǎn)移可用性: 同步(synchronous)和 異步(asynchronous)。同步可用性保證了主系統(tǒng)和輔助系統(tǒng)上的數(shù)據(jù)源是一致的,而且在故障轉(zhuǎn)移之后維持完整的連續(xù)性。異步可用性不保證主系統(tǒng)和輔助系統(tǒng)數(shù)據(jù)庫是完全同步的。將數(shù)據(jù)庫更改從主系統(tǒng)移到輔助系統(tǒng)的方法會(huì)不同,但這個(gè)過程會(huì)生成一個(gè)時(shí)間窗口,在這段時(shí)間內(nèi)數(shù)據(jù)還沒有從一個(gè)系統(tǒng)遷移到另一個(gè)系統(tǒng)。數(shù)據(jù)量也許會(huì)非常小,時(shí)間窗口可能會(huì)非常短,但您在決定解決方案時(shí)必須要考慮這一點(diǎn)。讓我們研究可以向您提供同步或異步故障轉(zhuǎn)移可用性的選項(xiàng)。專用的 HA 軟件選項(xiàng)同步方法涉及數(shù)據(jù)庫軟件與專用 HA 軟件的緊密集成以產(chǎn)生 HA 群集。HA 軟件支持由于操作系統(tǒng)平臺(tái)的不同而不同。常用的 HA 解決方案有:High Availability Cluster Multiprocessing(HACMP — AIX)Microsoft Cluster Server(MSCS)— WindowsSun Cluster — SunSteeleye 的 Lifekeeper — Linux 和 Windows這些是我列出的針對(duì)各平臺(tái)的最常見選項(xiàng)。還有其它一些 HA 軟件解決方案,也可以使用它們。所有這些解決方案的工作方式基本相同。假如有故障,數(shù)據(jù)庫服務(wù)器可以從一臺(tái)機(jī)器移到備份系統(tǒng)上。要完成該任務(wù),HA 軟件會(huì)將所有必需的資源移到輔助系統(tǒng)。這些資源包括物理數(shù)據(jù)庫的磁盤資源、網(wǎng)絡(luò)資源和數(shù)據(jù)庫服務(wù)器資源。在 HA 群集解決方案中,單個(gè)物理數(shù)據(jù)庫副本存儲(chǔ)在共享存儲(chǔ)系統(tǒng)上。在 DB2 環(huán)境中,一次只能有一個(gè)系統(tǒng)“擁有存儲(chǔ)器陣列。當(dāng)檢測(cè)到故障時(shí),存儲(chǔ)器的所有權(quán)就會(huì)從主系統(tǒng)轉(zhuǎn)移到輔助系統(tǒng)。同時(shí)也會(huì)轉(zhuǎn)移網(wǎng)絡(luò)資源。最后,在輔助系統(tǒng)上啟動(dòng)數(shù)據(jù)庫服務(wù)器資源,使數(shù)據(jù)庫變?yōu)榭捎谩9收系臋z測(cè)由服務(wù)器之間的“心跳連接執(zhí)行。這個(gè)“心跳是 HA 軟件的一個(gè)功能,它可以察覺硬件和軟件故障。由于只有一個(gè)數(shù)據(jù)庫的副本,所以它始終是同步的。數(shù)據(jù)庫引擎的故障轉(zhuǎn)移和重新啟動(dòng)的時(shí)間取決于以下因素:檢測(cè)故障所需的時(shí)間移動(dòng)數(shù)據(jù)庫資源相關(guān)資源(存儲(chǔ)陣列和聯(lián)網(wǎng)資源等)所必需的時(shí)間長度DB2 引擎執(zhí)行崩潰恢復(fù)所需的時(shí)間當(dāng)數(shù)據(jù)庫沒有正確關(guān)閉時(shí),DB2 總是會(huì)執(zhí)行崩潰恢復(fù)。崩潰恢復(fù)是日志文件的處理,從而確保將所有已提交的事務(wù)都寫到磁盤并且回滾未提交的事務(wù)。執(zhí)行該操作所需的時(shí)間取決于發(fā)生故障時(shí)數(shù)據(jù)庫日志中“打開工作的量。整個(gè)故障轉(zhuǎn)移可能只需要幾秒鐘,假如要從日志文件中處理的工作量很大,可能會(huì)需要更長時(shí)間。這種可用性解決方案的一個(gè)優(yōu)點(diǎn)是它不需要對(duì)應(yīng)用程序或客戶機(jī)配置目錄做任何更改。HA 軟件為數(shù)據(jù)庫連接提供了一個(gè)虛擬的 IP 地址資源。當(dāng)檢測(cè)到故障時(shí),該 IP 地址就會(huì)進(jìn)行故障轉(zhuǎn)移,應(yīng)用程序可以使用它以前使用的同一條連接語句。發(fā)生故障轉(zhuǎn)移時(shí),所有應(yīng)用程序都會(huì)斷開連接,客戶機(jī)會(huì)將通信錯(cuò)誤情況返回給應(yīng)用程序。一旦數(shù)據(jù)庫服務(wù)器在輔助系統(tǒng)上運(yùn)行之后,應(yīng)用程序只要重新發(fā)出連接語句,就可以象以前一樣繼續(xù)處理工作了。這也稱作 熱備用(hot standby)配置。但是,在等待故障轉(zhuǎn)移時(shí),輔助系統(tǒng)并不一直空閑。也可以以 相互接管(mutual takeover)配置來配置系統(tǒng),在該配置中,這兩個(gè)服務(wù)器都主動(dòng)地主管不同的數(shù)據(jù)庫。每臺(tái)機(jī)器都預(yù)備在發(fā)生故障時(shí)接管其伙伴的工作負(fù)載。圖 2. 專用的 HA 軟件選項(xiàng)表 2. 專用 HA 軟件選項(xiàng)的優(yōu)缺點(diǎn)優(yōu)點(diǎn): 缺點(diǎn): 數(shù)據(jù)庫始終是同步的需要額外的軟件來創(chuàng)建和配置解決方案不需要更改應(yīng)用程序或客戶機(jī)沒有復(fù)制數(shù)據(jù),因此提供較少的冗余不需要用戶交互來檢測(cè)和初始化故障轉(zhuǎn)移需要必須符合一些 HA 標(biāo)準(zhǔn)的外部存儲(chǔ)器性能不受額外工作負(fù)載的干擾由于硬件需求,限制了服務(wù)器之間的距離數(shù)據(jù)復(fù)制選項(xiàng)DB2 UDB 包含了集成復(fù)制能力。DB2 的復(fù)制實(shí)現(xiàn)包括兩部分: Capture(捕捉)和 Apply(應(yīng)用)。復(fù)制治理員指定表中要復(fù)制的復(fù)制源,然后通過使用前一步中的復(fù)制源作為其來源,在目標(biāo)數(shù)據(jù)庫(輔助系統(tǒng))上創(chuàng)建復(fù)制預(yù)訂。Capture 進(jìn)程監(jiān)控事務(wù)日志以獲取對(duì)復(fù)制源表的所有更改,然后將對(duì)這些表的任何更改放到登臺(tái)表中。Apply 程序定期讀取登臺(tái)表并將更改轉(zhuǎn)移到預(yù)訂目標(biāo)。數(shù)據(jù)復(fù)制是一個(gè)異步過程。在已更改的數(shù)據(jù)還沒有放到登臺(tái)表中或者 Apply 程序還沒有將更改復(fù)制到目標(biāo)系統(tǒng)期間,這兩個(gè)數(shù)據(jù)庫不是同步的。這不一定是一段很長的時(shí)間或很大的數(shù)據(jù)量,但必須考慮這一可能性。復(fù)制有幾個(gè)好的特性。它答應(yīng):假如不需要整個(gè)副本,可以只復(fù)制數(shù)據(jù)的子集。只要有足夠的網(wǎng)絡(luò)帶寬滿足用戶的需要,距離就不是問題。復(fù)制還答應(yīng)在使用 IBM 的 Information Integrator 產(chǎn)品的情況下,可以在一個(gè)獨(dú)立的平臺(tái)或不同的數(shù)據(jù)庫治理系統(tǒng)上托管輔助系統(tǒng)。這兩個(gè)系統(tǒng)都是“活動(dòng)的,因此可以完成獨(dú)立的工作。例如,一個(gè)系統(tǒng)可以用于處理事務(wù),而輔助系統(tǒng)可以用于創(chuàng)建報(bào)告或運(yùn)行備份。復(fù)制只捕捉對(duì)源表的更改。它不會(huì)捕捉對(duì)系統(tǒng)目錄的更改。例如,必須在兩個(gè)系統(tǒng)上都執(zhí)行對(duì)表許可權(quán)的更改,因?yàn)閺?fù)制無法復(fù)制這項(xiàng)更改。此外,故障轉(zhuǎn)移過程不是自動(dòng)的。發(fā)生故障后,系統(tǒng)治理員必須在客戶機(jī)上進(jìn)行更改,這樣他們才可以針對(duì)輔助系統(tǒng)工作;或者在輔助系統(tǒng)上做更改,使它可以模擬主系統(tǒng)。這將答應(yīng)應(yīng)用程序按以前那樣繼續(xù)工作,而不必更改應(yīng)用程序編碼。一個(gè)替代方法是使用諸如 IBM 的 Edge Server 之類的產(chǎn)品來治理服務(wù)器連接。假如應(yīng)用程序是用戶應(yīng)用程序,那么用戶只要連接到輔助數(shù)據(jù)庫,而不必對(duì)客戶機(jī)配置或數(shù)據(jù)庫服務(wù)器做任何實(shí)際的更改。運(yùn)行復(fù)制有一些開銷。額外的工作量取決于對(duì)源表的插入、更新和刪除活動(dòng)的量。不需要對(duì)基本表進(jìn)行額外的鎖定,因?yàn)閺?fù)制只分析日志文件,而不會(huì)分析基本表。但登臺(tái)表(更改表)的填充和這些事務(wù)的日志記錄需要數(shù)據(jù)庫資源。圖 3說明了用于高可用性的復(fù)制選項(xiàng)。圖 3. 復(fù)制表 3. 復(fù)制解決方案的優(yōu)缺點(diǎn)優(yōu)點(diǎn): 缺點(diǎn): 集成能力,不需要額外的軟件過程是異步的,可能會(huì)因故障而丟失數(shù)據(jù)在兩個(gè)地方復(fù)制數(shù)據(jù),冗余更大不會(huì)自動(dòng)進(jìn)行故障轉(zhuǎn)移,需要手工處理(或使用 Websphere Edge Server)靈活的體系結(jié)構(gòu)不能復(fù)制所有數(shù)據(jù)庫更改距離限制較少主系統(tǒng)上有額外的工作負(fù)載輔助系統(tǒng)可以執(zhí)行第二份工作負(fù)載日志傳送選項(xiàng)所有數(shù)據(jù)庫更改(插入、更新或刪除)都記錄在 DB2 事務(wù)日志中。事務(wù)日志主要用于崩潰恢復(fù)和在故障之后恢復(fù)系統(tǒng)。正如我們已經(jīng)討論的,它們?cè)趶?fù)制中發(fā)揮作用。此外,它們還可用于另一個(gè)高可用性解決方案 日志傳送(log shipping)。該 HA 方案類似于數(shù)據(jù)復(fù)制選項(xiàng)。它要求輔助系統(tǒng)預(yù)備好在主系統(tǒng)發(fā)生故障時(shí)進(jìn)行接管。治理員通過恢復(fù)主系統(tǒng)數(shù)據(jù)庫的備份來創(chuàng)建這個(gè)輔助系統(tǒng)。通過恢復(fù)主系統(tǒng)的數(shù)據(jù)庫備份,備份系統(tǒng)將處于前滾暫掛狀態(tài)。事務(wù)日志從主系統(tǒng)轉(zhuǎn)移到輔助系統(tǒng),并用于使數(shù)據(jù)庫前滾以完成事務(wù)。假如發(fā)生故障,治理員應(yīng)停止前滾過程,并且使數(shù)據(jù)庫聯(lián)機(jī)。可以用幾種方式完成轉(zhuǎn)移日志文件的過程。主要方法是使用 DB2 的 用戶出口(user exit)工具。用戶出口是當(dāng)事務(wù)日志已滿并預(yù)備歸檔時(shí)調(diào)用的可執(zhí)行應(yīng)用程序。數(shù)據(jù)庫引擎將日志文件傳遞給用戶出口,用戶出口邏輯將執(zhí)行所有必需的工作。用戶出口可以制作日志的副本、將它發(fā)送到磁帶設(shè)備、調(diào)用另一個(gè)程序或執(zhí)行它被編碼來處理的任何例程。一個(gè)可能的選項(xiàng)是將日志文件復(fù)制到輔助系統(tǒng)可以讀取日志并應(yīng)用日志中包含的事務(wù)的位置。與復(fù)制選項(xiàng)相同,日志傳送是一個(gè)異步過程。只要主系統(tǒng)上有活動(dòng)日志文件并且還有未應(yīng)用且未完成的日志文件,輔助系統(tǒng)就處于不同步狀態(tài)。DB2 確實(shí)有執(zhí)行雙日志記錄的能力。這答應(yīng)數(shù)據(jù)庫在不同卷上創(chuàng)建復(fù)制日志文件,從而增加冗余。此外,該方法不會(huì)在數(shù)據(jù)庫服務(wù)器上產(chǎn)生額外的開銷。與使用復(fù)制不同,該方法不會(huì)創(chuàng)建兩個(gè)活動(dòng)的系統(tǒng),因?yàn)閭浞菹到y(tǒng)在被治理員停止前滾暫掛狀態(tài)之前一直處于不可用狀態(tài)。圖 4說明了日志傳送過程。圖 4. 日志傳送表 4. 日志傳送的優(yōu)缺點(diǎn)優(yōu)點(diǎn): 缺點(diǎn): 集成能力,不需要額外的軟件過程是異步的,可能會(huì)因故障而丟失數(shù)據(jù)在兩個(gè)地方復(fù)制數(shù)據(jù),冗余更大不會(huì)自動(dòng)進(jìn)行故障轉(zhuǎn)移,需要手工處理距離限制較少輔助系統(tǒng)是被動(dòng)的,只提供備份能力活動(dòng)系統(tǒng)上沒有額外工作負(fù)載高級(jí)存儲(chǔ)選項(xiàng)現(xiàn)代的存儲(chǔ)子系統(tǒng)提供了許多高級(jí)特性。DB2 已經(jīng)能夠利用這些高級(jí)特性來創(chuàng)建高可用性和災(zāi)難恢復(fù)系統(tǒng)。雖然這些技術(shù)可能會(huì)不同,但高級(jí)存儲(chǔ)選項(xiàng)的基本要素就是能夠快速創(chuàng)建磁盤卷的相同副本。然后可以將這些卷安裝到輔助系統(tǒng)上。輔助系統(tǒng)可以充當(dāng)備份系統(tǒng)或執(zhí)行其它一些類型的工作負(fù)載。答應(yīng)實(shí)現(xiàn)這一功能的 DB2 特性叫作 暫掛 I/O(suspended I/O)。暫掛 I/O 這項(xiàng)技術(shù)答應(yīng)數(shù)據(jù)庫引擎使數(shù)據(jù)庫處于一致狀態(tài),同時(shí)又保持聯(lián)機(jī)。暫掛 I/O 狀態(tài)暫掛寫 I/O 操作,以防止對(duì)數(shù)據(jù)表空間和日志的寫操作。在數(shù)據(jù)庫離開暫掛 I/O 狀態(tài)之前,該數(shù)據(jù)庫仍可用于所有應(yīng)用程序,處理只讀語句和延遲寫語句(插入、更新和刪除)。通過 SET WRITE SUSPEND 命令將數(shù)據(jù)庫置為暫掛狀態(tài)。暫掛數(shù)據(jù)庫之后,就可以制作數(shù)據(jù)庫的物理文件的副本。將需要數(shù)據(jù)庫目錄、日志文件和數(shù)據(jù)庫容器的副本。存儲(chǔ)硬件和軟件通過分割鏡像卷或其它高級(jí)復(fù)制技術(shù),可以非常快地創(chuàng)建大量數(shù)據(jù)的副本。然后,所復(fù)制的卷可以用于創(chuàng)建備份系統(tǒng)。制作了副本之后,可以使用 SET WRITE RESUME 命令來繼續(xù)處理主系統(tǒng)上的所有事務(wù)。所復(fù)制的卷可以與 DB2INIDB 實(shí)用程序一起用來創(chuàng)建輔助系統(tǒng)。該實(shí)用程序有三個(gè)實(shí)現(xiàn):SNAPSHOT、STANDBY 和 MIRROR:SNAPSHOT 實(shí)現(xiàn)只答應(yīng)數(shù)據(jù)庫執(zhí)行崩潰恢復(fù)。創(chuàng)建了一個(gè)復(fù)制的數(shù)據(jù)庫,但在恢復(fù)期間不回滾任何事務(wù)。該方法適用于創(chuàng)建測(cè)試環(huán)境或報(bào)告機(jī)器。它不提供用于數(shù)據(jù)庫恢復(fù)的方法,因此不應(yīng)用作 HA 選項(xiàng)。STANDBY 和 MIRROR 方法答應(yīng)創(chuàng)建恢復(fù)實(shí)現(xiàn)。在這兩種情況下,DB2INIDB 工具使數(shù)據(jù)庫處于前滾暫掛狀態(tài)。然后可以將主系統(tǒng)中的日志文件應(yīng)用到備份系統(tǒng)。假如主系統(tǒng)發(fā)生故障,那么輔助系統(tǒng)將離開前滾暫掛狀態(tài)并聯(lián)機(jī),預(yù)備處理事務(wù)。用 STANDBY 還是用 MIRROR 方法取決于如何應(yīng)用日志以及如何使數(shù)據(jù)庫恢復(fù)聯(lián)機(jī)。STANDBY 方法使數(shù)據(jù)庫在獨(dú)立于主系統(tǒng)的位置恢復(fù)聯(lián)機(jī),并答應(yīng)在主系統(tǒng)處于暫掛狀態(tài)時(shí),在輔助系統(tǒng)上進(jìn)行數(shù)據(jù)庫備份。MIRROR 方法用所復(fù)制的卷替換原來的卷,而處理將在相同的位置中發(fā)生。如我在日志傳送部分所提到的,DB2 能夠生成雙日志。通過將日志放在不同的卷上,該能力可以與高級(jí)存儲(chǔ)選項(xiàng)一起使用來確保日志的完整性。DB2 用戶出口程序可以用于存儲(chǔ)和檢索日志文件,并治理已歸檔日志文件的位置。可以對(duì)用戶出口進(jìn)行編碼,以將日志放到輔助系統(tǒng)或另一個(gè)可用位置上。圖 5顯示了高級(jí)存儲(chǔ)選項(xiàng)。圖 5. 高級(jí)存儲(chǔ)表 5. 高級(jí)存儲(chǔ)的優(yōu)缺點(diǎn)優(yōu)點(diǎn): 缺點(diǎn): 集成能力,不需要額外的軟件過程是異步的,可能會(huì)因故障而丟失數(shù)據(jù)(這可以用雙日志記錄來彌補(bǔ))在兩個(gè)地方復(fù)制數(shù)據(jù),冗余更大不會(huì)自動(dòng)進(jìn)行故障轉(zhuǎn)移,需要手工處理能夠迅速地復(fù)制大量數(shù)據(jù)輔助系統(tǒng)處于前滾暫掛狀態(tài),不可用捕捉所有數(shù)據(jù)庫更改需要高級(jí)硬件災(zāi)難恢復(fù)建立災(zāi)難恢復(fù)計(jì)劃對(duì)于現(xiàn)代企業(yè)至關(guān)重要。企業(yè)數(shù)據(jù)庫中的信息對(duì)于進(jìn)行業(yè)務(wù)活動(dòng)是極其重要的。保護(hù)該數(shù)據(jù)以及在災(zāi)難之后確保其“生命是很重要的活動(dòng)。當(dāng)構(gòu)建 DR 計(jì)劃時(shí),有三個(gè)要害問題:需要防止的故障級(jí)別可接受的數(shù)據(jù)丟失量答應(yīng)用于恢復(fù)的時(shí)間量。要防止的故障級(jí)別通常是近似性問題。原始數(shù)據(jù)與其備份之間在物理上有多緊密?備份數(shù)據(jù)可以在不同的驅(qū)動(dòng)器上、在獨(dú)立的機(jī)器上、在獨(dú)立的樓層上或在不同的建筑物里。不可能猜測(cè)所有可能的災(zāi)難。火災(zāi)、水災(zāi)或甚至用戶的惡作劇都可能是企業(yè)必須面對(duì)的問題。解決方案的設(shè)計(jì)應(yīng)該包括公司希望防止最壞情況的方案。所有企業(yè)都不希望在故障之后丟失任何數(shù)據(jù)。雖然不丟失數(shù)據(jù)是可能的,但由于可能需要的復(fù)雜性和費(fèi)用(尤其是假如所防止的故障級(jí)別非常高),這通常是不實(shí)際的。可接受的數(shù)據(jù)丟失量取決于數(shù)據(jù)對(duì)公司有多重要以及有什么資源可用于確保其生命。恢復(fù)所需的時(shí)間量類似于高可用性的目標(biāo)。它與高可用性解決方案之間的差異在于所防止的故障類型以及通常認(rèn)為合理的時(shí)間長度。HA 故障轉(zhuǎn)移通常以秒和分鐘來衡量,而災(zāi)難恢復(fù)則可能以小時(shí)和天來進(jìn)行衡量。不過并非總是這樣,但這個(gè)差異區(qū)分了對(duì)這些解決方案的相對(duì)期望。備份和恢復(fù)數(shù)據(jù)庫備份創(chuàng)建了數(shù)據(jù)庫的時(shí)間點(diǎn)映象,它是災(zāi)難恢復(fù)解決方案的基本組件。DB2 提供了幾種備份,包括脫機(jī)備份、聯(lián)機(jī)備份和增量備份。從備份恢復(fù)所需的時(shí)間取決于數(shù)據(jù)庫的大小和可用于執(zhí)行恢復(fù)的硬件資源。由于數(shù)據(jù)庫備份只捕捉時(shí)間點(diǎn)的數(shù)據(jù),因此無法通過一個(gè)簡單恢復(fù)來恢復(fù)備份之后發(fā)生的任何數(shù)據(jù)更改。要恢復(fù)備份之后完成的事務(wù),就需要應(yīng)用日志文件。可以從備份和日志文件(通過在日志文件中進(jìn)行“前滾來應(yīng)用)來恢復(fù)數(shù)據(jù)庫。這答應(yīng)恢復(fù)到某個(gè)時(shí)間點(diǎn)或恢復(fù)到日志文件結(jié)束。因此,假如 DR 解決方案必須恢復(fù)自上次備份以來的事務(wù),那么保留日志文件是非常要害的。有兩個(gè)提高日志保留的 DB2 特性:雙日志記錄和用戶出口工具,已在關(guān)于數(shù)據(jù)庫復(fù)制 HA 選項(xiàng)的部分中進(jìn)行了討論。災(zāi)難恢復(fù)方案災(zāi)難恢復(fù)方案可以分成三類:簡單備份備份和日志保留高級(jí)存儲(chǔ)備份雖然不是每個(gè)解決方案都清楚地被劃入這三類中的某一類,但它們確實(shí)為您理解災(zāi)難恢復(fù)選項(xiàng)提供了合理的框架。簡單備份只創(chuàng)建數(shù)據(jù)庫備份確實(shí)創(chuàng)建了一個(gè) DR 解決方案。它也許是非常有限的,這取決于您的環(huán)境。通過從“活動(dòng)的系統(tǒng)上移走所創(chuàng)建的備份,可以提高保護(hù)的級(jí)別。增加數(shù)據(jù)庫備份的頻率也降低了數(shù)據(jù)丟失的風(fēng)險(xiǎn)。備份軟件對(duì)于創(chuàng)建和維護(hù) DB2 備份可能非常有幫助。例如,IBM 的 Tivoli Storage Manager 和 Veritas 的 Net Backup® 都提供了答應(yīng)在其軟件控制的設(shè)備上直接備份和維護(hù) DB2 數(shù)據(jù)庫的解決方案。這些設(shè)備可以是磁帶庫或另一種存儲(chǔ)設(shè)備。簡單備份適合于只讀數(shù)據(jù)庫或由能輕松重新創(chuàng)建的批處理作業(yè)填充的數(shù)據(jù)庫,或者在備份之間不必維護(hù)數(shù)據(jù)庫更改的情況下。表 6. 簡單備份的優(yōu)缺點(diǎn)優(yōu)點(diǎn): 缺點(diǎn): 保護(hù)級(jí)別: 數(shù)據(jù)庫備份可以轉(zhuǎn)移到外部位置,以提高保護(hù)級(jí)別數(shù)據(jù)丟失的風(fēng)險(xiǎn): 備份之間的數(shù)據(jù)更改可能會(huì)丟失(運(yùn)行增量備份來降低風(fēng)險(xiǎn)的影響)恢復(fù)所需的時(shí)間: 數(shù)據(jù)庫恢復(fù)需要很長時(shí)間備份和日志保留保留數(shù)據(jù)庫日志文件與數(shù)據(jù)庫備份一起創(chuàng)建了更完善的 DR 解決方案。日志文件答應(yīng)恢復(fù)備份之間發(fā)生的數(shù)據(jù)更改。該解決方案的真正復(fù)雜性在于保護(hù)日志文件以確保它們?cè)诨謴?fù)期間的可用性。假如選擇實(shí)現(xiàn)雙日志記錄,DB2 可以將日志文件放在不同的位置,假如確保這些位置在不同的存儲(chǔ)器陣列上,那么保護(hù)級(jí)別就會(huì)得到提高。但是,日志文件仍面臨存儲(chǔ)子系統(tǒng)故障。如在高可用性的日志傳送選項(xiàng)中所提到的,用戶出口程序可以提供重定位日志文件的替代方法。用戶出口可以將已關(guān)閉的日志文件移到當(dāng)前系統(tǒng)可用存儲(chǔ)陣列之外的位置,從而提高保護(hù)級(jí)別。這里的告誡是它只移動(dòng)已關(guān)閉的日志文件。即使已實(shí)現(xiàn)了雙日志記錄,包含活動(dòng)事務(wù)的日志文件仍面臨因陣列丟失或存儲(chǔ)設(shè)備故障而產(chǎn)生的丟失。該解決方案適合于大多數(shù)面向商業(yè)事務(wù)的環(huán)境。它均衡了最小化數(shù)據(jù)丟失風(fēng)險(xiǎn)的需要和維護(hù) DR 解決方案所需的成本。表 7. 備份加日志保留的優(yōu)缺點(diǎn)優(yōu)點(diǎn): 缺點(diǎn): 保護(hù)級(jí)別: 數(shù)據(jù)庫備份可以轉(zhuǎn)移到外部位置,以提高保護(hù)級(jí)別數(shù)據(jù)丟失的風(fēng)險(xiǎn): 假如使用適當(dāng)?shù)牟襟E來維護(hù)日志文件,會(huì)大大降低數(shù)據(jù)丟失的風(fēng)險(xiǎn)恢復(fù)所需的時(shí)間: 數(shù)據(jù)庫恢復(fù)需要時(shí)間,應(yīng)用日志文件將增加恢復(fù)時(shí)間高級(jí)存儲(chǔ)備份我們?cè)诟呖捎眯韵碌母呒?jí)存儲(chǔ)選項(xiàng)部分中討論過這個(gè)主題,相同的原則在這里也適用。正如在那部分中所見的,STANDBY 方法答應(yīng)當(dāng)數(shù)據(jù)庫副本處于暫掛狀態(tài)時(shí)在輔助系統(tǒng)上執(zhí)行數(shù)據(jù)庫備份。創(chuàng)建數(shù)據(jù)庫副本已經(jīng)創(chuàng)建了 DR 解決方案的一部分。備份副本提高了保護(hù)級(jí)別。假如用雙日志記錄和用戶出口程序正確實(shí)現(xiàn)了這個(gè)高級(jí)存儲(chǔ)備份,那么它就為核心企業(yè)數(shù)據(jù)庫生成了最好的 DR 解決方案。該解決方案最適合處于企業(yè)活動(dòng)核心的數(shù)據(jù)庫系統(tǒng)。示例可能包含了供給鏈治理和在線代理系統(tǒng)。表 8. 用于災(zāi)難恢復(fù)的高級(jí)存儲(chǔ)備份優(yōu)缺點(diǎn)優(yōu)點(diǎn): 缺點(diǎn): 保護(hù)級(jí)別: 保護(hù)級(jí)別本來就很高,而且可以通過耦合存儲(chǔ)子系統(tǒng)來提高保護(hù)級(jí)別。數(shù)據(jù)丟失的風(fēng)險(xiǎn): 假如采用雙日志記錄和用戶出口程序,會(huì)大大降低數(shù)據(jù)丟失的風(fēng)險(xiǎn)恢復(fù)所需的時(shí)間: 恢復(fù)所需的時(shí)間非常短。結(jié)束語DB2 為構(gòu)建高可用性和災(zāi)難恢復(fù)解決方案提供了出色的技術(shù)。您應(yīng)該根據(jù)您的業(yè)務(wù)需求、可用選項(xiàng)和解決方案需求來做出選擇。本文中討論的這些要點(diǎn)為進(jìn)一步研究和評(píng)估提供了一個(gè)很好的框架。

標(biāo)簽:
DB2
數(shù)據(jù)庫
排行榜
