Oracle Golden Gate體系架構詳解(轉載)

標籤：

摘自ITEYE czmmiao  http://czmmiao.iteye.com/blog/1550877 

GoldenGate簡介 
Oracle Golden Gate軟體是一種基於日誌的結構化資料複本備份軟體，它通過解析來源資料庫線上日誌或歸檔日誌獲得資料的增量變化，再將這些變化應用到目標資料庫，從而實現來源資料庫與目標資料庫同步。Oracle Golden Gate可以在異構的IT基礎結構（包括幾乎所有常用作業系統平台和資料庫平台）之間實現大量資料亞秒一級的即時複製,從而在可以在應急系統、線上報表、 即時資料倉庫供應、交易跟蹤、資料同步、集中/分發、容災、資料庫升級和移植、雙業務中心等多個情境下應用。同時，Oracle Golden Gate可以實現一對一、廣播(一對多)、彙總(多對一)、雙向、點對點、級聯等多種靈活的拓撲結構。

 

GoldenGate技術架構 
和傳統的邏輯複製一樣，Oracle GoldenGate實現原理是通過抽取源端的redo log或者archive log，然後通過TCP/IP投遞到目標端，最後解析還原應用到目標端，使目標端實現同源端資料同步。以下是OracleGoldenGate的技術架構：  

Manager進程 
Manager進程是GoldenGate的控制進程，運行在源端和目標端上。它主要作用有以下幾個方面：啟動、監控、重啟Goldengate的其他進程，報告錯誤及事件，分配資料存放區空間，發布閥值報告等。在目標端和源端有且只有一個manager進程，其運行狀態為running好stopped。 在windows系統上，manager進程作為一個服務來啟動，二在Linux/Unix系統上則是一個系統進程。
Extract進程 
Extract運行在資料庫源端，負責從源端資料表或者日誌中捕獲資料。Extract的作用可以按照表來時間來劃分：
初始時間裝載階段：在初始資料裝載階段，Extract進程直接從源端的資料表中抽取資料。

同步變化捕獲階段：初始資料同步完成以後，Extract進程負責捕獲源端資料的變化(DML和DDL)
GoldenGate並不是對所有的資料庫都支援ddl操作 
Extract進程會捕獲所有已配置的需要同步的對象變化，但只會將已提交的事務發送到遠端trail檔案用於同步。當事務提交時，所有和該事務相關的 日誌記錄被以事務為單元順序的記錄到trail檔案中。Extract進程利用其內在的checkpoint機制，周期性的記錄其讀寫的位置，這種機制是 為了保證Extract進程終止或作業系統當機，重新啟動Extract後，GoldenGate可以恢複到之前的狀態，從上一個斷點繼續往下運行。通過 上面的兩個機制，就可以保證資料的完整性了。

多 個Extract 進程可以同時對不同對象進行操作。例如，可以在一個extract進程抽取並向目標端發生交易資料的同時，利用另一個extract進程抽取的資料做報 表。或者，兩個extract進程可以利用兩個trail檔案，同時抽取並並行傳輸給兩個replicat進程以減少資料同步的延時。
在進行初始化轉載，或者批量同步資料時， GoldenGate會產生extract檔案來儲存資料而不是trail檔案。預設情況下， 只會產生一個 extract檔案，但如果出於作業系統對單個檔案大小限制或者其他因素的考慮，也可以通過配置產生多個 extract檔案。 extract檔案不記錄檢查點。

Extract進程的狀態包括Stopped(正常停止),Starting(正在啟動)，Running(正在運行)，Abended(Abnomal End的縮寫，標示異常結束)。
Pump進程 
pump進程運行在資料庫源端，其作用是將源端產生的本地trail檔案，把trail以資料區塊的形式通過TCP/IP 協議發送到目標端，這通常也是推薦的方式。pump進程本質是extract進程的一種特殊形式，如果不使用trail檔案，那麼extract進程在抽取完資料以後，直接投遞到目標端，產生遠程trail檔案。
與 Pump進程對應 的叫Server Collector進程，這個進程不需要引起我的關注清單，因為在實際操作過程中，無需我們對其進行任何配置，所以對我們來說它是透明的。它運行在目標端，其 任務就是把Extract/Pump投遞過來的資料重新組裝成遠程ttrail檔案。 

注意：無論是否使用pump進程，在目標端都會產生trail檔案 
pump進程可以線上或者大量設定，他可以進行資料過濾，映射和轉換，同時他還可以配置為“直通模式”，這樣資料被傳輸到目標端時就可以直接產生所需的格式，無需另外操作。 直通模式提高了data pump的效率，因為產生後的對象 不需要繼續進行檢索。
在大多數情況下，oracle都建議採用data pump，原因如下: 
1、為目標端或網路問題提供保障 ：如果只在目標端配置trail檔案，由於源端會將extract進程抽取的內容不斷的儲存在記憶體中，並及時的發送到目標端。當網路或者目標端出現故障時， 由於extract進程無法及時的將資料發送到目標， extract進程將耗盡記憶體然後異常終止。 如果在源端配置了data pump進程，捕獲的資料會被轉移到硬碟上，預防了 異常終止的情況。當損毀修復，源端和目標端 恢複連通性時，data pump進程發送源端的trail檔案到目標端。
2、 可以支援複雜的資料過濾或者轉換： 當使用資料過濾或者轉換時，可以先配置一個data pump進程在目標端或者源端進行第一步的轉換，利用另一個data pump進程或者 Replicat組進行第二部的轉換。

3、有效規劃儲存資源 ：當從多個資料來源同步到一個資料中心時，採用data pump的方式，可以在源端儲存抽取的資料，目標端儲存trail檔案，從而節約儲存空間。
4、解決單資料來源向多個目標端傳輸資料的單點故障： 當從一個資料來源發送資料到多個目標端時，可以為每個目標端分別配置不同的data pump進程。這樣如果某個目標端失效或者網路故障時，其他的目標端不會受到影響可以繼續同步資料。 
Replicat進程 
Replicat進程，通常我們也把它叫做應用進程。運行在目標端，是資料傳遞的最後一站，負責讀取目標端trail檔案中的內容，並將其解析為DML或 DDL語句，然後應用到目標資料庫中。
和Extract進程一樣，Replicat也有其內部的checkpoint機制，保證重啟後可以從上次記錄的位置開始恢複而無資料損失的風險。
Replicat 進程的狀態包括Stopped(正常停止),Starting(正在啟動)，Running(正在運行)，Abended(Abnomal End的縮寫，標示異常結束)。 
Trail檔案 
為了更有效、更安全的把資料庫事務資訊從源端投遞到目標端。GoldenGate引進trail檔案的概念。前面提到extract抽取完資料以後 Goldengate會將抽取的事務資訊轉化為一種GoldenGate專有格式的檔案。然後pump負責把源端的trail檔案投遞到目標端，所以源、 目標兩端都會存在這種檔案。 trail檔案存在的目的旨在防止單點故障，將事務資訊持久化，並且使用checkpoint機制來記錄其讀寫位置，如果故障發生，則資料可以根據checkpoint記錄的位置來重傳 。 當然，也可以通過extract通過TCP/IP協議直接發送到目標端，產生遠程trail檔案。但這種方式可能造成資料丟失，前面已經提到過了，這裡不再贅述。
Trail檔案預設為10MB，以兩個字元開始加上000000~999999的數字作為檔案名稱。如c:\directory/tr000001.預設情況下儲存在GoldenGate的dirdat子目錄中。可以為不同應用或者對象建立不同的trail檔案。同一時刻，只會有一個extract進程處理一個trail檔案。

10.0版本以後的GoldenGate，會在trail檔案頭部儲存包含trail檔案資訊的記錄，而10.0之前的版本不會儲存該資訊。每個trail檔案中的資料記錄包含了資料頭地區和資料區域。在 資料頭地區中包含事務資訊，資料區域包含實際抽取的資料  

進程如何寫trail檔案

為了減小系統的I/O負載，抽取的資料通過大位元組塊的方式儲存到trail檔案中。同時為了提高相容性，儲存在trail檔案中的資料以通用資料模式(一種可以在異構資料庫之間進行快速而準確轉換的模式)儲存。 當然，根據不同應用的需求，資料也可以儲存為不同的模式。

預設情況下，extract進程以追加的方式寫入trail檔案。當extract進程異常終止時，trail檔案會被標記為需要恢複。當extract重新啟動時會追加checkpoint之後的資料追加到該trail檔案中。在 GoldenGate 10.0之前的版本， extract進程採用的是覆蓋模式。即當 extract進程異常終止，則會將至上次完整寫入的交易資料之後的資料覆蓋現有trail檔案中的內容。

這裡是筆者理解不是很透徹，原文如下，望讀者給予建議

By default, Extract operates in append mode, where if there is a process failure, a recovery  marker is written to the trail and Extract appends recovery data to the file so that a history  of all prior data is retained for recovery purposes. 

In append mode, the Extract initialization determines the identity of the last complete  transaction that was written to the trail at startup time. With that information, Extract  ends recovery when the commit record for that transaction is encountered in the data  source; then it begins new data capture with the next committed transaction that qualifies  for extraction and begins appending the new data to the trail. A data pump or Replicat  starts reading again from that recovery point. 

Overwrite mode is another version of Extract recovery that was used in versions of  GoldenGate prior to version 10.0. In these versions, Extract overwrites the existing  transaction data in the trail after the last write-checkpoint position, instead of appending  the new data. The first transaction that is written is the first one that qualifies for  extraction after the last read checkpoint position in the data source. 

checkpoint  

checkpoint用於抽取或複製失敗後（如系統宕機、網路故障燈），抽取、複製進程重新置放抽取或者複製的起點。在進階的同步配置中，可以通過配置checkpoint另多個extract或者replicat進程讀取同個trail檔案集。

extract進程在資料來源和trail檔案中都會標識checkpoint，Replicat只會在trail檔案中標示checkpoint。

在批處理模式中，extract和replicat進程都不會記錄checkpoint。如果批處理失敗，則整改批處理會重新進行。

checkpoint資訊會預設儲存在goldengate的子目錄dirchk中。在目標端除了checkpoint檔案外，我們也可以通過配置通過額外checkpoint table來儲存replicat的checkpoint資訊。

Group 
我們可以通過為不同的extract和replicat進程進行分組來去區分不同進程之間的作用。例如，當需要並行的複製不同的資料集時，我們則可以建立兩個或者多個複製進程。
進程組中包含進程，進程檔案，checkpoint檔案和其他與進程相關的檔案。對於replicat進程來說，如果配置了checkpoint table，則不同組的都會包含checkpoint table。
組的命名規則如下

GGSCI 
GGSCI是GoldenGate Software Command Interface 的縮寫，它提供了十分豐富的命令來對Goldengate進行各種操作，如建立、修改、監控GoldenGate進程等等。
Commit Sequence Number
前文已經多次提到，Goldengate是以事務為單位來保證資料的完整性的，那麼 GoldenGate又是怎麼識別事務的呢？ 這裡用到的是Commit Sequence Number(CSN)。CSN儲存在交易記錄中和trail檔案中 ，用於資料的抽取和複製。CSN作為事務開始的標誌被記錄在trail檔案中，可以通過@GETENV欄位轉換函式或者logdump工具來查看。不同的資料庫平台的CSN顯示如下

GoldenGate對不同資料庫的支援情況

 

 

*只能作為目標端，不能作為源端。但Goldengate可以從mysql直接裝載的原表中抽取資料。（由於筆者不瞭解mysql，這裡只是在字面意思翻譯，原文如下
the exception being that GoldenGate can extract records from MySQL source tables as part of a GoldenGate direct load.
** GoldenGate進行交易資料管理的API工具
*** 只支援鏡像複製，不支援資料操作、過濾，欄位對應等。 

參考至：《Oracle GoldenGate Administrator Guide》
           《企業級IT營運寶典之GoldenGate實戰_第1章》聯動北方著
出處：http://czmmiao.iteye.com/blog/1550877

czmmiao

Oracle Golden Gate體系架構詳解(轉載)