天天看點

深度幹貨 | 如何借助雲原生搞定Oracle備份快速恢複?

Oracle備份面臨的挑戰

在傳統企業裡,經常會用Oracle資料庫去承載業務重要核心資料,同時Oracle針對不同的恢複場景提供了靈活多樣的恢複操作方法,靈活的設計給備份和恢複帶來了更多的複雜性,是以Oracle的備份管理相比于MySQL而言,對DBA在專業性上有更高的要求。

比如說,Oracle環境有多種:Standalone,Standalone+DataGuard,RAC,RAC+DataGuard,雙機Oracle等,其中DataGuard還有多種運作模式,不同的Oracle環境的備份有一些細微差别,一個備份腳本很難同時滿足這些場景,如果業務系統有多套Oracle環境,備份将會非常複雜,例如如何確定全量備份集總是有效的(可恢複的)等等。我們現在以一個具體的案例來說明這個問題:一緻性全量備份。

  • 一緻性全量備份

何為一緻性全量備份

在我們這篇文章裡"一緻性全量備份"的定義如下:

條件1:備份集中存在一個連續完整的歸檔日志序列,其開始SCN和結束SCN能夠覆寫備份開始時的最小的資料檔案checkpoint SCN和備份結束時最大資料檔案SCN(隻讀和離線資料檔案除外)。

條件2:備份集中包含恢複所用的全部資料檔案,控制檔案和參數檔案。

條件3:備份集中包含盡可能新的歸檔日志。

條件1和2確定全量備份集的完整性,使得備份集可以獨立的被恢複(恢複出一緻的狀态)。條件3可以確定全量備份集始終是最新的,不會出現“丢資料”的場景。滿足上述條件的備份集叫做一緻性全量備份集。

  • 一緻性全量備份的好處

一緻性全量備份集有哪些好處呢?

  • 友善轉儲:通常一個備份集是一個存儲目錄,簡單的打包就可以轉儲到錄音帶,異地轉儲。
  • 簡化恢複:恢複時不依賴其他備份集,例如定時歸檔日志備份産生的備份集失效了不會影響全量備份集的有效性,一緻性全量備份集總是可以獨立的恢複。

一緻性全量備份的難點

深度幹貨 | 如何借助雲原生搞定Oracle備份快速恢複?

圖1 一緻性全量備份

下面我們看一下在哪些場景中,我們有可能得不到一緻性全量備份集,圖1 中的case2-case5就是典型的非一緻性全量備份。

在【case2】中缺失了部分的歸檔日志,違反了【條件1】中連續完整的歸檔日志序列這個條件。如 圖2 所示,如果Primary和Standby之間網絡出現了異常,此時主庫可以正常地生成新的歸檔日志,但是Standby上将無法生成新的歸檔日志,當網絡恢複後,DataGuard會從Primary上自動同步最新的歸檔日志,同時也會同步這部分缺失的歸檔日志,但是如果在執行全量備份期間,缺失的歸檔日志還沒有被同步到Standby上,那麼此時的全量備份集中的歸檔日志将會包含空洞,導緻無法恢複。

在【case3】中歸檔日志的的最小SCN和資料檔案最小SCN之間存在gap。圖2 中的所有運作模式都有可能出現這個問題,例如使用者在清理Standby上的歸檔日志時執行了delete force就會導緻RMAN将那些還沒有被應用的歸檔日志删除掉。

在【case4】中最新的歸檔日志SCN和最大的資料檔案SCN存在gap。圖2 中的【模式三】有可能出現這個問題,因為它是先同步redo到Standby的redo log file中,當主庫執行Switch log之後,Standby上才會将redo log file歸檔到歸檔日志。如果Primary和Standby之間網絡出現了問題,那麼Primary依然能夠正常生成歸檔日志,但是備庫卻不能執行redo log file的切換,不能生成新的歸檔日志,導緻歸檔日志的SCN小于資料檔案的最大SCN。相反,【模式一】和【模式二】則一定不會出現這種case,因為他們是先産生歸檔日志,然後再應用歸檔日志到資料檔案,是以其歸檔日志最大SCN一定是大于等于資料檔案最大SCN的。

在【case5】中備份集中丢失了部分的資料檔案,例如,使用者開啟了(backup optimization)配置,此時RMAN會開啟備份優化功能,如果某些檔案或者歸檔日志被其他人備份過了,那麼将不會再次備份。

在【條件2】中, 如果Primary上的歸檔日志或者Redo長時間無法同步到Standby上,此時可能能夠得到滿足【case1】的全量備份,既此時的備份是成功的,也能夠獨立的恢複,但是該全量備份沒有包含主庫最新的歸檔日志,導緻我們的備份不是最新有效的全量備份。

深度幹貨 | 如何借助雲原生搞定Oracle備份快速恢複?

圖2 DataGuard運作模式

由于Primary和Standby的運作原理不一樣,在實際業務實作時,會遇到更多的穩定性問題,實作一緻性全量備份需要解決如下幾個問題:

  • 如何防止Standby上的備份擷取不到最新的Primary的Redo日志。
  • 當Primary和Standby之間網絡延遲較大或者出現網絡分區,導緻Redo傳輸太慢或者長時間無法傳輸時,備份如何解決。
  • 如何發現Primary或者Standby上的歸檔日志出現了gap,以及如何解決gap。
  • 如何避免備份的資料檔案或者歸檔日志出現損壞的資料塊。

    此外,在備份的過程中,您可能還要考慮如下一些問題:

  • 定時的清理已經備份過的歸檔日志。
  • 防止備份資料中毒/惡意删除,確定任何時候都至少有一個可用的備份集用來做恢複。
  • 為了滿足監管要求,實作備份資料的多地域存儲。

DBS Oracle 備份

上述的兩個舉例展示了Oracle備份的複雜性和較高的技術難度。而對于以上提出的問題,DBS結合阿裡巴巴之前多年的Oracle生産和運維經驗通過完全自主研發,打造了DBS Oracle備份産品,幫助阿裡雲客戶友善低成本地備份和保護Oracle資料資産。

深度幹貨 | 如何借助雲原生搞定Oracle備份快速恢複?

圖3 DBS Oracle備份示意圖

如圖3,DBS Oracle 備份與恢複采用 Oracle 内置的 RMAN 技術,實作 Oracle 資料庫的熱備份和恢複。備份管理者在 DBS控制台 簡單配置備份政策,系統會根據使用者配置的備份政策自動地建立資料備份任務,DBS系統向Oracle主控端DBS備份用戶端發送備份指令,DBS備份用戶端執行RMAN備份腳本,流式無入侵地讀取備份資料,并對資料執行壓縮/加密等處理,最後将備份資料寫入到雲上加密的備份存儲。整個備份過程不侵占使用者本地磁盤空間和IO,對資料庫完全無入侵。而對于資料恢複任務,備份管理者在 DBS控制台 點選發起恢複任務,此時DBS排程會向在Oracle主控端上的 DBS備份用戶端 發送恢複指令,DBS備份用戶端 執行對應的RMAN腳本進行資料恢複。

基礎能力

它在目前版本具備的技術特點如下:

  • 完全自研:阿裡巴巴之前是Oracle的使用大戶,結合之前阿裡集團對Oracle生産運維的經驗完全自研打造Oracle備份恢複産品,以幫助使用者實作低成本探索資料庫及資料庫備份國産化演進路徑。
  • 相容的平台:支援Linux平台下的Oracle保護。
  • 支援的資料庫版本:10g/11g/12c/18c/19c。
  • 支援的備份類型:全量備份和事務日志備份。
  • 支援的備份粒度:執行個體。
  • 備份對象:日志檔案,控制檔案,參數檔案,資料檔案。
  • 加密情況:傳輸過程支援HTTPS加密,存儲支援AES256,BYOK加密
  • 支援的恢複粒度:Oracle單機恢複粒度包括:資料庫執行個體(全庫恢複)。
  • 支援的恢複方式:支援原機異執行個體,異機原位置的指定任意時間點的恢複。
  • RAC 恢複到單機:當 Oracle RAC 環境損壞時,支援将 Oracle RAC 恢複到單機環境中。
  • 歸檔日志删除政策:基于備份成功次數,支援自動删除指定時間段内已備份的Oracle 歸檔日志,避免因歸檔日志過滿影響資料庫運作。
  • 多通道:開啟多通道備份可提高備份效率。使用者可為根據資料檔案和日志檔案的存儲量以及業務壓力情況分别自定義通道數量,并行讀取傳輸資料,進而充分利用磁盤 I/O。
  • 資料庫進階壓縮:開啟資料庫進階壓縮後,可以在備份過程中對備份資料進行壓縮, 節省磁盤空間,提升傳輸效率。
  • 無入侵:整個備份恢複過程,對源庫無入侵,不依賴本地磁盤做中轉。

    它還在持續疊代中,歡迎持續關注。

差異點

為什麼要備份上雲?

DBS Oracle備份是雲技術和備份技術的結合,它不僅實作了傳統的Oracle備份的能力(如上所述),而且在使用DBS雲備份時:

  • 天然實作6個9的備份存儲穩定性:備份資料存儲在阿裡雲OSS對象存儲上,SLA達到6個9
  • 天然實作同地域多機房容災:備份資料按照多機房高可用容災
  • 低成本實作異地備份:
  • 網絡帶寬:阿裡雲内部網絡更高的帶寬,更低的網絡延遲,費用更低,可以實作更低的異地災備RPO
  • 恢複機器:相比于傳統的資料備份保護方案,需要提前額外購買恢複用的機器資源。在DBS隻需要在恢複時隻需要按量付費通過DBS一鍵恢複到RDS,或者是通過DBS沙箱執行個體秒級拉齊臨時恢複執行個體即可。

雲備份帶來更多

上雲之後,DBS和雲上衆多雲産品深度結合,提供了以下等能力,幫使用者盤活沉寂的備份資料,降低使用者TCO:

  • 資料湖分析:相比于傳統備份備份資料隻能在恢複時使用而言,DBS與雲上産品DLA(資料湖分析)深度結合,無需恢複則能提供邏輯備份資料的資料湖分析能力;
  • 副本資料管理CDM:DBS與DAS、DMS,RDS等資料庫産品深度整合,對 備份資料 提供 CDM(副本資料管理)能力,可以實作對實體備份秒級恢複,可以讓使用者基于備份資料實作devops及分析能力,大大提高資料資産的使用效率,降低TCO。

Oracle副本資料管理(CDM)

傳統的資料恢複時間主要取決于資料的下載下傳時間以及歸檔日志應用時間。恢複時間通常在小時級别。DBS Oracle 備份利用DBS存儲的快照克隆挂載等技術,以及雲執行個體的彈性生産能力,可以實作Oracle副本資料管理,讓使用者可以在幾秒鐘之内恢複出一個1TB的Oracle執行個體,幫助使用者快速實作應急容災,恢複演練,DevOps等需求。

為實作Oracle CDM能力,需要以下的技術能力,如圖4:

全量備份+鏡像複制:DBS用流式挂載備份的方式,結合RMAN Image Copy備份方式實作byte by byte的資料檔案無入侵拷貝。在恢複時,通過流式挂載恢複的方式,可以直接用這份備份資料拉起Oracle資料庫,無需再做大量的資料拷貝。

快照+克隆:DBS備份存儲的快速打快照的能力,幫助使用者打造不同時間點的Oracle備份資料的黃金副本。基于這些黃金副本以及對黃金副本的秒級克隆能力,可以幫助使用者在非常短的時間内(秒級)建立同一個時間點的Oracle沙箱執行個體,不同沙箱執行個體之間無幹擾,幫助使用者實作DevOps,比如在Oracle沙箱執行個體上實作業務變更驗證,業務壓測,業務釋出測試等等。

深度幹貨 | 如何借助雲原生搞定Oracle備份快速恢複?

圖4 DBS Oracle副本複制管理

總結

DBS Oracle備份産品是阿裡雲自研的,結合阿裡集團之前多年Oracle資料庫的生産使用經驗打造的雲備份産品。它不僅提供了傳統備份所提供的Oracle備份能力外,還實作了無入侵流式備份能力,同時和雲以及衆多雲産品深度結合,在備份資料上提供資料湖分析,并通過副本資料管理(CDM)技術提供Oracle秒級恢複及devops能力。現DBS Oracle備份已經上線,歡迎大家來試用:

https://help.aliyun.com/document_detail/149339.html
深度幹貨 | 如何借助雲原生搞定Oracle備份快速恢複?

11月18日 14:00-15:00邀您一起見證

雲原生資料庫備份DBS新版本釋出

掃描下圖二維碼預約觀看直播釋出會

深度幹貨 | 如何借助雲原生搞定Oracle備份快速恢複?