解讀IBM DB2容災備份方案
我們要講述的就是某省級體彩中心下轄投注站數(shù)據(jù)遺失及補救的案例，該投注站由于數(shù)據(jù)遺失對于日常業(yè)務產(chǎn)生了很大的影響，迫切需要一套解決方案。彩票的業(yè)務模式是將散落的數(shù)據(jù)“集中”到省級中心的數(shù)據(jù)庫中，并上傳國家級數(shù)據(jù)備份中心，這是一個典型異地、異構數(shù)據(jù)備份系統(tǒng)。主要特點體現(xiàn)在：
- 營業(yè)終端條件差，僅就硬件方面考慮，服務器被盜、火災 、硬盤整體損壞、其他物理損傷都會造成數(shù)據(jù)的丟失。
- 地域分布廣，受終端投入的局限，僅能借助窄帶寬跨互聯(lián)網(wǎng)進行實時環(huán)境下的數(shù)據(jù)庫復制，得以容災。
- 依據(jù)業(yè)務數(shù)據(jù)承載量的不同，省級中心和各級投注站使用的數(shù)據(jù)庫不同——中心使用DB2，投注站或縣級中心有的采用Oracle，有的Sybase，或直接就是SQL Server。
- 業(yè)務的不可中斷性要求數(shù)據(jù)實現(xiàn)分鐘級的實時同步。并將歷史數(shù)據(jù)放在獨立數(shù)據(jù)庫，使得讀、寫分別指向不同的數(shù)據(jù)庫提升性能。
我們講述故事中，所幸的是丟的僅是個別“羊”只——個別投注站上傳數(shù)據(jù)丟失、利用較窄帶寬傳輸數(shù)據(jù)“失真”——局部號段錯位、丟失，等等，好在還沒有丟失“羊群”，但這個警鐘已敲響，彩票在投注站打印出來就形成了合同關系，如中獎數(shù)據(jù)丟失還需給付獎金造成的損失都是由省體彩中心“買單”的。
究其上述某省級體彩中心數(shù)據(jù)丟失災難的原因是因為存在手工上傳數(shù)據(jù)時低帶寬環(huán)境的信號延時、不同數(shù)據(jù)庫類型間轉(zhuǎn)換數(shù)據(jù)等潛在的漏洞，這些漏洞更需“補牢”，而且這次“補牢”需要一個徹底的解決方案——實現(xiàn)數(shù)據(jù)庫異構備份：各投注站與省級中心間、各省級中心與國家中心間都要建立跨平臺的“N+1”模式容災。 縱觀各路數(shù)據(jù)庫備份產(chǎn)品中，能夠?qū)崿F(xiàn)異構備份者已是鳳毛麟角。再論性能優(yōu)劣、技術前瞻性、客戶口碑，IBM TSM(Tivoli Storage Manager)備份管理工具實為最佳選擇。
IBM TSM全面支持主流平臺和主流廠商的數(shù)據(jù)庫系統(tǒng)，包括Oracle、DB2、Informix、SQL Server、Sybase等。對于異構數(shù)據(jù)庫(以Oracle為例)，使用TSM的數(shù)據(jù)庫保護模塊TSM for Database/Oracle能夠很好的對其進行全面的保護——使用數(shù)據(jù)庫的備份接口，以透明化的方式提供數(shù)據(jù)庫管理員一種進行數(shù)據(jù)備份的方法。基本原理是：
- 捕捉：在源數(shù)據(jù)庫實時讀取交易日志捕捉數(shù)據(jù)變化并可實現(xiàn)過濾 。
- 隊列文件：暫存數(shù)據(jù)變化。
- 傳輸： 數(shù)據(jù)經(jīng)過壓縮和加密傳送到目的地。
- 執(zhí)行所需的數(shù)據(jù)變化，然后將數(shù)據(jù)變化提交到目的庫。
仍以Oracle為例，備份Oracle數(shù)據(jù)庫需要TSM for Database/Oracle，它利用ORACLE數(shù)據(jù)庫提供的備份接口RMAN來對數(shù)據(jù)庫進行備份。Oracle備份工具RMAN能夠生成需要備份的數(shù)據(jù)文件，并能夠保證數(shù)據(jù)庫的一致性，所有的熱備和邏輯備份都通過Oracle RMAN唯一接口進行。Tivoli可以利用這些工具實現(xiàn)對Oracle數(shù)據(jù)庫的各種對象進行在線/離線備份，另外通過RMAN增量備份的機制，TSM可以實現(xiàn)對Oracle數(shù)據(jù)庫的增量備份。而在被備份數(shù)據(jù)的輸出上采用了和TSM結合的方式，TSM就是一個雙向管道，一方面利用數(shù)據(jù)庫的API和數(shù)據(jù)庫備份軟件連接，另一方面利用TSM的API和TSM連接，將數(shù)據(jù)庫備份軟件的輸出傳送到TSM管理的備份介質(zhì)中。在Oracle中，直接設置了和TSM的連接，只需要在Oracle的相關配置中設置TSM服務器的名稱和IP地址即可。為了減少DB主機壓力和減少備份時間，對于Oracle數(shù)據(jù)庫，同時能夠提供數(shù)據(jù)庫的增量備份，僅僅備份包括自從上次備份過程以后被改變過的data files的data blocks。這些數(shù)據(jù)可以和上面談到的文件備份分開，存在不同的存儲池中，通過不同的存儲策略來進行管理。
恢復同樣可以根據(jù)發(fā)生故障的種類，在數(shù)據(jù)庫管理員的判斷下，靈活的針對數(shù)據(jù)庫的任意一個部件進行。如果業(yè)務數(shù)據(jù)量較大，建議對數(shù)據(jù)庫的全備份每天或每兩天做一次，而每隔一段時間備份數(shù)據(jù)量較小的Transaction Log。當發(fā)生數(shù)據(jù)損壞或丟失時，先恢復最近備份的數(shù)據(jù)庫和Transaction Log，再用Transaction Log進行Forward Recovery，從而將數(shù)據(jù)庫恢復到最近一次備份Transaction Log時的狀態(tài)。在這種備份策略下，最壞情況會丟失一段時間的數(shù)據(jù)。通過將備份Transaction Log的時間間隔減小，例如減小到每小時備份一次(這一備份時間間隔應根據(jù)Log數(shù)據(jù)量和網(wǎng)絡帶寬情況制定)，能夠最大限度地減少數(shù)據(jù)丟失;對于 master database的數(shù)據(jù)，由于數(shù)據(jù)量不會太大，而且數(shù)據(jù)變化相對較小，所以建議每周做一次全備份。
綜上所述，使用TSM能夠靈活的對用戶的異構數(shù)據(jù)庫自動化的定時進行備份的工作，已達到容災的效果——應用到上述省級彩票中心的案例中，在全省方位內(nèi)沒有對終端數(shù)據(jù)庫進行改造的前提下，可以將各投注站或縣市級體彩中心數(shù)據(jù)“整齊劃一”，也徹底消滅了數(shù)據(jù)丟失!而且與主要競爭對手的備份方案各方面對比，詳見下表，均有優(yōu)勢。通過上述技術性能的闡述，TSM作為當今面臨數(shù)據(jù)爆炸式增長環(huán)境中，企業(yè)成功管理和控制 “信息浪潮”的利器，應該被人信服的。唯一有所忌憚的是先期成本的投入，誠然TSM這樣優(yōu)秀產(chǎn)品是有代價的。但“補牢”后，不僅不會再丟羊，而且羊兒會更強壯!——有助于提高IT操作的效率， 幫助削減與存儲管理相關的成本，特別是數(shù)據(jù)災難的“沉沒成本”。
【編輯推薦】
