基于Goldengate的數據庫異地災備實現

宓正宇

（中國電信股份有限公司上海分公司，上海 200120）

1 引言

中國電信股份有限公司上海分公司（以下簡稱上海電信）業務平臺建設從一開始的分散建設模式到現在的集中化建設模式，實現了業務平臺的集約化運營與管理。業務平臺的集中化建設可以減少運營商對硬件的投資，減少運營的維護成本，便于集約化運營管理等。但由此帶來的安全隱患也不能忽視，例如火災、地震等不可抗拒因素，用戶數據和業務數據集中存放的單點故障會對公司造成不可預計的損失。因此上海電信統籌安排了臨港新城電信機房作為公司IT系統的新建EDC機房，以實現電子化數據異地高速備份，提升IT系統的數據備份能力，并為后續進一步的應用級容災做好準備。同時異地災備的數據庫還可以分散主節點數據庫的系統訪問壓力，擴展了數據文件的實時讀寫能力。

本文探討了基于Oracle的Goldengate技術實現對電信IBP系統用戶及業務數據進行異地備份，同時考慮到公眾客戶售中管控模塊的上線會對現有IBP生產數據庫系統產生影響，建議該管控模塊所需的IBP相關數據從IBP復制庫獲取；同時以后ODS的數據抽取也將從IBP復制庫獲取，減少生產系統的壓力。

2 Goldengate災備系統技術

2.1 災備技術

災備技術應用主要源于對數據的保護，其核心的技術思想是在異地創建副本。縱觀業界的災備產品都是基于以下幾個數據保護與同步復制技術，包括基于傳統備份的災備技術、基于鏡像的災備技術、基于復制的災備技術。其中，基于復制的災備技術又可以分為基于數據庫的復制技術、基于存儲的復制技術、基于存儲交換層的復制技術、基于主機軟件的復制技術。本文主要涉及的是基于數據庫的復制技術，因為基于數據庫的復制技術總體投資規模較小，而且不要求數據集中存儲，對網絡帶寬要求較低，但是實施難度大，技術成熟度也一般[1]。

2.2 Goldengate技術

Goldengate軟件是一個實現異構數據環境間數據復制的綜合軟件分組，它通過分析源數據庫的在線日志或歸檔日志記錄數據的增/刪/改變化，然后將這些增/刪/改的操作同步到目標數據庫，最終實現目標數據庫與源數據庫的雙活和同步。另外該軟件提供異構環境下交易數據的捕捉、轉換和接收，可以滿足異構數據庫環境下的變化數據同步，而且即使是異構操作系統或異構數據庫都可以實現大量數據亞秒級的同步。Goldentate能實現一對一、一對多、多對一、雙向和點對點等靈活的拓撲結構并應用到計費系統、報表系統、供應鏈系統等多個場景，滿足跟蹤、同步、分發和備份容災的要求[2]。

（1）單向數據復制

單向數據復制簡單的說就是利用extract抓取進程在源數據庫捕獲在線日志或者歸檔日志并在extract隊列中記錄源數據庫增/刪/改等操作，然后通過deliver傳輸進程接收這些變化量，最后通過replicate入庫進程創建復制或者同步的SQL語句，最終在目標數據庫中進行執行操作。單向數據復制過程的示意如圖1所示。

圖1 單向數據復制示意

（2）雙向數據復制

雙向數據復制的原理與單向數據復制的原理基本一致，只是說兩端的源數據/目標數據互相作為復制對象，并且源數據庫和目標數據庫同時為雙活狀態。

但是雙向數據復制存在一個問題，那就是如果不采取有效的機制，剛被復制進目標數據庫的變化數據馬上會被目標數據庫的抓取進程復制回源數據庫，為了避免這種死循環狀態，Goldengate采用了一種非常有效的判斷機制來識別哪些數據可以用來被抓取。也可以這樣理解，這種判斷機制其實就是在抓取進程中使用了跟蹤表機制，當復制進程和應用程序同時更新同一個對象表的時候，抓取進程就開始啟用跟蹤表機制，在進行雙向數據復制中，抓取進程就通過命令行向源數據庫和目標數據庫中分別加入跟蹤表，一旦抓取進程發現跟蹤表有數據更新，就判斷為復制進程所產生，并忽略掉該操作；反之，如果更新表沒有數據更新，那么抓取進程就判斷為由應用程序產生，并將更新操作抓取出來。雙向數據復制的過程示意如圖2所示。

（3）其他復制方式

除了單向復制和雙向復制方式以外，Goldengate還提供了其他的復制方案，利用靈活的技術架構可以滿足用戶不同的復制需求。例如廣播復制、集中復制和多層復制等。

2.2.1 關鍵特性

Goldengate的配置方式十分靈活，包括單向數據復制、雙向數據復制和多層次數據復制。可以滿足用戶本地駐地網或者城域網中的不同場景和需求。

該同步軟件有以下3個關鍵特性。

（1）實時訪問實時信息

Goldengate提供異構系統間數據庫事務的實時捕獲、轉換、路由和交付。該軟件在確保事務完整性的同時讓更多數據庫和平臺實現了高性能、低影響的亞秒級數據移動。它采用一個基于組件的體系結構，可幫助企業系統所需的持續可用性和實時集成。

（2）保持關鍵系統的持續可用

Goldengate可以幫助系統恢復因意外或者計劃造成的終端停機，并提高系統性能和可伸縮性。該軟件可以支持下列情形，包括災難恢復、數據保護、零停機運營、數據分布和查詢卸載等。

（3）穩定的模塊化體系結構

Goldengate軟件體系包括3個主要組件：抓取、跟蹤隊列和交付。這種模塊化方式讓每個組件可以獨立運行，從而加快數據復制并確保數據完整性[3]。

圖2 雙向數據復制示意

2.2.2 特性和優勢

Goldengate軟件具備很多特性和優勢，可以在平臺系統間快速移動事務數據。包括以下幾點。

（1）實時數據

立即捕獲、轉換事務數據并將其交付給其他系統，延遲不到1 s，可以讓系統業務平臺均可獲得及時、準確的信息，改善組織決策。

（2）異構支持

利用異構數據庫和平臺提高IT部門的靈活性。從現有的IT資源中提取數據，在統一所有企業用戶業務數據的同時降低了成本。

（3）可靠性

將所有提交的記錄交付給目標系統，即使在網絡中斷時，也無需中斷系統。

（4）高性能、低影響

每秒移動上千個事務，且不會影響源系統或目標系統。實時訪問關鍵信息，且不影響生產系統。

（5）事務完整性

在源系統和目標系統間移動數據時，保持數據提交邊界的一致性、隔離性、持久性等屬性，確保備份系統和報表數據庫間數據的一致性和應用的完整性。

2.2.3 Goldengate與其他備份方式比較

基于數據庫備份的軟件還有Dataguard和Stream等，表1對3種實現方式進行了詳細的比較。

表1 3種備份實現方式的比較

基于Goldengate軟件與存儲遠程鏡像的比較見表2。

表2 基于Goldengate軟件與存儲遠程鏡像的比較

因此基于上述原因綜合評估后，下面主要通過具體案例探討基于Goldengate技術實現IBP業務平臺的數據庫備份及數據庫同步以解決業務模塊增加訪問IBP系統數據庫壓力的方案。

3 案例

3.1 IBP（服務開通）系統

目前上海本地的IBP系統已經綜合了SDH和基于SDH的多業務傳送平臺MSTP業務，因此上海本地的SDH業務和MSTP業務都是由IBP系統統一管控的，IBP系統承受的壓力可想而知。

3.2 IBP系統現狀

業務開通流程的系統支撐現狀如圖3所示。

圖3 業務開通流程的系統支撐現狀

上海電信IBP系統自2008年上線后，系統壓力不斷上升；除了要承受系統本身的新產品和新業務的壓力外，還要滿足很多外來系統的業務發展需求，具體如下。

· ODS系統每天從IBP抽取數據。

· 公眾客戶售中管控模塊對服務開通跨系統流程的關鍵環節進行實時監測要求。

· 公眾客戶售中管控模塊對服務開通跨系統流程的系統銜接環節進行實時監測要求。考慮到公眾客戶售中管控模塊的上線會對現有IBP生產數據庫系統產生影響，因此該管控模塊所需的 IBP相關數據從 IBP復制庫獲取；同時以后ODS的數據抽取也將從IBP復制庫獲取，減少生產系統的壓力。于是就有了本文中基于Goldengate來同步生產IBP數據庫數據到IBP復制庫的方法。

3.2.1 系統網絡拓撲

系統網絡拓撲如圖4所示。

3.2.2 數據庫服務器性能與日志

數據庫服務器如圖5所示。

圖4 系統網絡拓撲

圖5 數據庫服務器性能

固網數據庫日志產生量每天約224 GB。

CDMA網數據庫日志產生量每天約139 GB。

3.3 基于Goldengate復制數據庫

Goldengate數據復制軟件當前采用基于LOG的方法獲取數據變化，可以在相同或不同的Oracle數據庫版本進行復制，或者可以從 Oracle數據庫復制數據到其他類型的數據庫（異構復制）。目前，Goldengate只配置了DML復制，對于所有DDL操作均不予以復制[4]。

3.3.1 Goldengate支持類型及操作

（1）數據支持類型

支持numeric（數字類型），包括number、binary float、binary double。暫不支持 binary_integer和PLS_integer。

支持所有character（字符類型），包括char、varchar2、long、nchar、nvarchar2。

支持大對象，包括 clob、nclob、blob。但不支持bfile。

支持binary（二進制類型），包括raw和long raw。

支持 date及 timestamp類型。支持除了timezone_region和 timezone_abbr類型的所有timestamp類型。

暫不支持多字節的XML類型。

支持用戶自定義類型（UDT），源端的 UDT與目標端的UDT必須相同。

其他支持的數據類型，包括rowid、varray、interval day、interval year。

Goldengate暫不支持的其他數據類型：anydata 和 anydataset、anytype、mlslabel、uritype和urowid。

（2）特殊對象支持

Goldengate支持對于常規表的數據復制，對于一些特殊對象支持如下所示。

有條件支持物化視圖（materialized view），在以下有條件限制中支持：

· 源表必須有唯一主鍵；

· Goldengate不支持物化視圖使用“with rowid”來創建，但當物化視圖LOG（不是物化視圖自己）用“with rowid”來創建時，Goldengate是支持的；

· 物化視圖必須是使用單個表，而不能包含joins生成的表；

· Goldengate不支持truncates物化視圖，但支持使用“delete from”來替代。

· 索引組織表（index organized table）通過物化視圖復制：

· 對于Goldengate基于LOG的復制方式，IoT表無法直接從日志中抽取，但是可以為IoT表建立物化視圖，通過復制該物化視圖的變化實現IoT數據變化的復制。

（3）不支持的特殊操作

以下特殊操作由于不寫日志，Goldengate無法予以復制。

· direct-path table load（由于不進行寫LOG操作）

Oracle插入數據有兩種方式：常規插入和direct-path插入。常規插入，重新使用table中的自由空間，在已有數據中插入新數據，維護引用完整性約束。direct-path插入，在表中已有數據之后插入新數據；數據直接插入數據文件，繞過緩存；已有數據中的自由空間沒有被重新利用；忽略了引用完整性約束。direct-path會寫較少的 redo log和undo log，導致Goldengate無法通過日志獲取足夠信息捕捉數據變化。

常見的 direct path 插入包括：Insert/*+ APPEND */ into table1 as selecttable2; create table 1as select table2。

· 并行DML模式下缺省為direct-path

如：ALTER SESSION { ENABLE | FORCE }PARALLEL DML。

· 使用SQL *loader并且設置direct=y

如果遇到上述操作，一般這些表數據不是原生數據，可以在復制中排除掉這些表并通過定時備份等方式予以復制。

如果在應用中使用該 hint，并且表被設置為nologging，則不會寫足夠日志，Goldengate無法復制。

如果在應用中使用該 hint，則不會寫足夠日志，Goldengate無法復制。

· 不支持truncate操作

因為在數據庫維護的時候 truncate操作是不去寫數據庫日志的。

3.3.2 復制數據庫

（1）復制內容和數據量

本次復制的內容只需針對IBP系統中的3個模塊，分別見表3。

表3 IBP系統中的3個模塊

通過調研CDMA網和固網數據庫里的用戶，本次復制的數據量見表4。

以未來一年數據量的等比增長，需要復制的數據量為：

（2）軟硬件環境

本次復制工具使用的是 Oracle公司的Goldengate，鑒于Goldengate是通過將主庫所有的變化信息應用到復制庫的方式，所需的主機性能建議和生產庫的性能相當，同時由于 I/O的性能直接影響了復制的效果，建議存儲使用高端存儲，所配置容量與生成庫相當。根據筆者的實際實施經驗，目標庫的機器性能建議和生產庫相當，但可以略微低一點。

表4 CDMA網和固網數據庫里的數據量

在主機配置方面，鑒于生產環境數據庫內部的SCHEMA的名稱又相同，建議建立各自單獨的復制庫，建議配置見表5。

在存儲配置方面，根據式（1）、式（2）中以一年為基礎估算的存儲數據量為：

CDMA網復制庫：6.4 TB；

固網復制庫：2.4 TB。

（3）Goldengate部署及測試

本案例Goldengate的基本步驟如下所示。

· 整理需要復制的表的相關信息。包括：表的屬主、表結構、索引、主外鍵、表的大小、表的用途、表所在的表空間和表采用的復制方式。

· 安裝主機和操作系統，配置網絡，安裝數據庫軟件。包括：操作系統的安裝、主機命名、IP地址分配、文件系統的劃分。存儲的劃分和分配，數據庫軟件的規劃和安裝及配置。

· 安裝 Goldengate軟件及測試。包括Goldengate軟件在生產庫和復制主機之間的安裝、部署。復制腳本的編寫和測試，復制程序的壓力測試。

· 系統割接前的復制內容全備份。

· 系統割接前的生產庫和復制庫的同步。

· 系統割接時的生產庫和復制庫的同步。

· 系統割接后的生產庫和復制庫的同步檢測。

· 系統割接后的生產庫和復制庫的主機性能檢測。

· 系統割接后的生產庫應用測試。

· 系統割接后的復制庫應用測試。

表5 建議配置

4 使用Goldengate的要求及注意事項

4.1 時鐘同步

對于RAC環境，Goldengate要求所有節點必須保持時鐘同步，同時必須保持所有RAC節點和運行的抽取進程的節點保持時鐘同步。因為Goldengate會比較本地的系統時間和commit的時間戳。所以不能忽略這個設置。否則可能導致數據復制的紊亂，因此 RAC環境下務必使用 NTP（網絡時間協議）進行時間同步[5]。

4.2 共享存儲

在使用Goldengate數據同步的時候，Goldengate的相關軟件和工作目錄建議最好配置在共享存儲環境中，從而保證對所有節點都是可用的，從任何一個節點都可以啟動Goldengate的進程，當其中一個節點出現異常時，可以在剩余的節點啟動而無須修改任何配置參數。否則如果運行在單個節點上的話，需要將剩余節點中的歸檔日志通過NFS文件共享的方式加載到Goldengate運行節點。

4.3 定期清理歸檔

開啟數據庫歸檔后，需要部署清理歸檔日志的定時任務，以防磁盤空間被占滿導致數據庫無法啟動的故障，包括主節點和容災節點都要定時清理歸檔。

5 結束語

業務平臺集中建設和集約化運營管理的發展是大勢所趨，越來越多的業務平臺走向集中，特別是隨著中國電信移動業務的蓬勃發展，各業務或產品的基地化建設和運營，各種用戶數據，業務數據的集中存放是否安全，各種重要的業務平臺是否有切實可行的容災措施，是目前急需解決的問題。本文通過探討基于Oracle的Goldengate技術實現業務平臺數據庫的異地備份，通過復制IBP數據庫系統的案例很大程度上說明復制庫為緩解生產庫的壓力起到了很明顯的效果，總之希望Goldengate能對現網業務平臺的數據庫級容災備份提供有效的幫助。

參考文獻：

[1] 羅圣美, 李明, 葉郁文.大數據容災備份技術挑戰和增量備份解決方案[J].大數據, 2015, 1(3)： 106-112.LUO S M, LI M, YE Y W.Challenge and solution of big data backup and recovery[J].Big Data Research, 2015, 1(3)：106-112.

[2] Oracle Goldengate administrator’s guide[R].2012.

[3] 曲波, 鄧旭東, 姜峰.Oracle Goldengate數據同步機制研究與應用[J].微型電腦應用, 2014, 30(6)： 55-58.QU B, DENG X D, JIANG F, et al.Research and application of Oracle Goldengatedata synchronization mechanism[J].Microcomputer Applications, 2014, 30(6)： 55-58.

[4] 李鵬, 于洪濤, 徐靜波.七號信令監測系統中基于 Oracle 的數據同步方案研究[J].電信科學, 2010, 26(2)： 60-64.LI P, YU H T, XU J B.Research on the scheme of Oracle-based data synchronization in the SS7 monitoring system[J].Telecommunications Science, 2010, 26(2)： 60-64.

[5] 佟敏, 李方村.關于 BOSS異地容災系統建設的討論[J].電信科學, 2004, 20(7)： 66-69.TONG M, LI F C.Discussion on the construction of BOSS disaster recovery system[J].Telecommunications Science, 2004,20(7)： 66-69.