作者介紹

自從阿里喊出“去IOE”的口號，又經(jīng)過2013年棱鏡門事件，政府也將數(shù)據(jù)安全視為重中之重，逐漸在加強管控軟、硬件的國產(chǎn)化之路。好吧，這跟我們今天要說的數(shù)據(jù)分發(fā)有什么關(guān)系呢？

眾所周知，“去IOE”中的I和E相對比較容易被替代，而Oracle的替代則是一條漫長、艱辛的摸索之路。某省運營商的數(shù)據(jù)分發(fā)需求也是在此大背景下不得不選擇的一條轉(zhuǎn)型之路。在此之前，集團數(shù)據(jù)下發(fā)是通過小型機的存儲底層復(fù)制技術(shù)，將整個生產(chǎn)庫每天同步到異機啟動，再通過創(chuàng)建一系列的對象和授權(quán)，從而將生產(chǎn)庫的數(shù)據(jù)下發(fā)給地市查詢使用。小型機停止使用之后，X86環(huán)境無法實現(xiàn)，則有了通過OGG來實現(xiàn)多源端數(shù)據(jù)庫的數(shù)據(jù)集中分發(fā)方式。

如圖所示，源端有多個數(shù)據(jù)庫，基于存儲、網(wǎng)絡(luò)的限制，無法做到打通所有源端到目標端的網(wǎng)絡(luò)，源端也無法保證每個數(shù)據(jù)庫服務(wù)器都能有足夠大的容量來存放隊列文件。

因此我們設(shè)立了一個大容量的分發(fā)中心，用于統(tǒng)一網(wǎng)絡(luò)傳輸路徑，并集中管理OGG產(chǎn)生的隊列文件，使之能保存較長時間，并將源端的隊列文件統(tǒng)一中轉(zhuǎn)后傳遞至目標端，最后在目標端應(yīng)用，從而實現(xiàn)數(shù)據(jù)的多源端到統(tǒng)一目標端的分發(fā)。

雖然知道讀者們基本都是運維界的老鳥，不過也可能有不熟悉的朋友，下面介紹一下OGG的基本工作原理。以下摘自網(wǎng)絡(luò)：

GoldenGate軟件是一種基于日志的結(jié)構(gòu)化數(shù)據(jù)復(fù)制軟件，它通過解析源數(shù)據(jù)庫在線日志或歸檔日志獲得數(shù)據(jù)的增刪改變化，再將這些變化應(yīng)用到目標數(shù)據(jù)庫，實現(xiàn)源數(shù)據(jù)庫與目標數(shù)據(jù)庫實時同步。

GoldenGate軟件可以在異構(gòu)的IT基礎(chǔ)結(jié)構(gòu)（包括幾乎所有常用操作系統(tǒng)平臺和數(shù)據(jù)庫平臺）之間實現(xiàn)大量數(shù)據(jù)亞秒一級的實時復(fù)制，其復(fù)制過程簡圖如下：

如上圖所示，GoldenGate的數(shù)據(jù)復(fù)制過程如下：

利用捕捉進程（Capture Process）在源系統(tǒng)端讀取Online Redo Log或Archive Log，然后進行解析，只提取其中數(shù)據(jù)的變化如增、刪、改操作，并將相關(guān)信息轉(zhuǎn)換為GoldenGate自定義的中間格式存放在隊列文件（trail）中。

再利用傳送進程將隊列文件通過TCP/IP傳送到目標系統(tǒng)。捕捉進程在每次讀完log中的數(shù)據(jù)變化并在數(shù)據(jù)傳送到目標系統(tǒng)后，會寫檢查點（checkpoint），記錄當前完成捕捉的log位置，檢查點的存在可以使捕捉進程在中止并恢復(fù)后可從檢查點位置繼續(xù)復(fù)制。

說白了OGG就是讀取日志，然后轉(zhuǎn)換成特定格式的文件，最后在目標端回放源端的操作，支持類似“斷點續(xù)傳”。

目前我們這邊源端的數(shù)據(jù)庫版本較多，以11.2.0.4的版本為主，分發(fā)中心OGG軟件版本為當時的最新版12.2。整體環(huán)境已經(jīng)運行了2年多，總體來說，運行較為平穩(wěn)（這句話是假的，其實是踩坑踩過來的），現(xiàn)在已完全替代之前底層復(fù)制的方式來供各個地市查詢數(shù)據(jù)。相比于底層復(fù)制技術(shù)，OGG無法做到像前者那樣，將整個庫都給復(fù)制過來，并且能保證數(shù)據(jù)的準確性；但OGG也有其優(yōu)勢，就是時效性以及對主庫極小的壓力。

Oracle數(shù)據(jù)庫的數(shù)據(jù)類型那么多，OGG只能支持其中常用的一部分，雖然這么說看上去確實有兼容性方面的問題，不過我相信實際應(yīng)用中，這“常用的一部分”數(shù)據(jù)類型已經(jīng)基本覆蓋了OLTP系統(tǒng)應(yīng)用的需要，所以不需要太擔心，如果真的有，可以嘗試一部分特殊表用特殊方式來處理。

在時效性方面，OGG通常情況下不會讓人覺得有什么延遲，幾乎都是秒級或者官方吹牛的亞秒級同步。不過這種說法也僅限于通常情況，在某省運營商每個月出賬后的時間，OGG的部分復(fù)制進程同步延遲經(jīng)常達到十幾個小時，這還是在目標端拆分了大量復(fù)制進程以后的情況。

畢竟不是所有的表都有主鍵，雖然Oracle宣稱沒有主鍵也可以，會將所有列合起來當成唯一約束或者主鍵，但實際應(yīng)用中大批量Delete操作的性能問題確實令人難以忍受，而且一旦存在重復(fù)行的情況，OGG對于Update、Delete操作的同步可能還會有隨機的不確定性（目前來說數(shù)據(jù)的準確性還是比較能保證）。

不過其實想想也正常，出賬期間，物理備庫基于數(shù)據(jù)塊的同步都有延遲，更別說基于SQL同步的OGG了，再高的并行回放，依然不能與主庫的高并發(fā)寫相提并論。

由于OGG的抽取進程所做的僅是讀取日志，并生成相應(yīng)的隊列文件，可能還有一部分寫B(tài)R文件的操作，所以只需要很少的IO即可完成，這點IO對數(shù)據(jù)庫的性能影響微乎及微。而存儲底層復(fù)制的情況下，需要在2-3小時內(nèi)完成20~30T存儲的復(fù)制，這對網(wǎng)絡(luò)、IO的壓力可想而知。

不過雖然說OGG對IO的需求較少，但也不代表完全沒有需求，本地環(huán)境中，一部分源端是在物理備庫上使用ALO(archived log only)模式抽取，并且關(guān)閉了BR功能，否則每晚日賬期間，OGG進程必定僵死，Oracle原廠也無法解釋清楚問題原因。

我認為主要還是OGG軟件對備庫的支持不好，同樣條件下，主庫就沒有這樣的問題。除了僵死問題，備庫抽取所能支持的抽取模式也僅有經(jīng)典模式，這在Exadata一體機上是致命問題，所以除非逼不得已，不建議在備庫抽取。

前面吐槽了這么多，那么實際應(yīng)用反饋如何呢？答案是基本滿足地市查詢需求，僅部分表需特殊處理，偶爾有需要新增同步的表。

源端的所有數(shù)據(jù)庫加起來，少說有10W張表，其中大部分為歷史數(shù)據(jù)表，數(shù)據(jù)基本不變，主要查詢的基礎(chǔ)配置表和年月表都能正常同步，僅部分表因為應(yīng)用會有頻繁的DDL操作導(dǎo)致無法正常同步。對于這類無法正常同步的表，我們通過自動化的expdp/impdp腳本，每天將這部分表同步到目標端即可。

因為地市查詢的具體需求也不要求這類表做到實時同步，之前底層存儲復(fù)制的方式，數(shù)據(jù)也有一天的延遲，所以完全可以滿足需求。如果有新增表同步的需求，也會有標準化的操作流程，對已同步的表不會造成大的影響。

對于SQL的性能，我們也做了一部分測試，大部分情況下的查詢，因為目標端存儲采用了閃存，查詢速度都會比原有減配的小型機環(huán)境更快，但也有部分復(fù)雜SQL的執(zhí)行計劃變更，查詢速度變慢，這屬于性能優(yōu)化的范疇了，在此不做討論。

總之，OGG并不完美，但采用什么構(gòu)架、技術(shù)也總是在現(xiàn)有的資源、環(huán)境、需求下做的妥協(xié)選擇，至少做到滿足當前需求，它還是做到了。

OGG軟件是向下兼容的，但實際使用過程中，我們發(fā)現(xiàn)在源端-中轉(zhuǎn)端-目標端的傳遞鏈路上，需要源端的軟件版本等于或低于中轉(zhuǎn)端的版本，否則一旦源端的OGG抽取或投遞進程狀態(tài)有變更，就會導(dǎo)致中轉(zhuǎn)端的投遞進程abend，并且重啟無法解決，需手工生成新的隊列文件。

這一問題有待后續(xù)升級構(gòu)架方案嘗試解決，但目前我們只能采取OGG版本一致的策略。但這也帶來了新的問題，那就是源端總是會有數(shù)據(jù)庫遷移、升級的吧?那數(shù)據(jù)庫上了18C、19C，OGG也必須使用新版本才能支持，這怎么辦呢？

首當其沖想到的是中轉(zhuǎn)端隨之升級OGG版本，那中轉(zhuǎn)端升級，目標端肯定也要升級啊，但是這需要充分的升級測試，目前來說，還沒有十足的把握來保證升級成功，一旦升級失敗，這上百T數(shù)據(jù)量的重新初始化真的夠我們喝好幾壺了……其實源端已經(jīng)有了一套數(shù)據(jù)庫上了18C，當前只能采取繞過中轉(zhuǎn)端的方式，無奈之舉。

謝天謝地，當前我們除了碰到壓縮表不支持之外，幾乎沒有碰到其他類型的表不支持問題，而壓縮表也基本都是很老的歷史表，幾乎無變更。所以對我們來說這點倒是不頭疼。

BR的設(shè)計理念確實很好，可以防止OGG進程在異常后重復(fù)讀取日志，并且僅需很小的IO和存儲。奈何備庫抽取的條件下，開了BR就會在段時間內(nèi)事務(wù)量巨大的情況下導(dǎo)致進程僵死，遂在備庫上均關(guān)閉BR，主庫抽取時開啟。

OGG其實是可以支持DDL復(fù)制的，但經(jīng)典抽取模式需要開啟全庫級別的觸發(fā)器，這對于生產(chǎn)庫的性能影響肉眼可見，肯定是不建議使用的。目前我們碰到最多的是源端的表MOVE和rename，這也是前文所說的部分表無法正常同步的主要原因。集成模式倒是可以在不部署觸發(fā)器的情況下同步DDL操作，這也是后續(xù)我們升級時重點測試項目之一。 

正常情況下，OGG進程僅需很小的內(nèi)存，但我們也碰到在一個服務(wù)器上，OGG抽取進程占用了上限的64G內(nèi)存，導(dǎo)致服務(wù)器內(nèi)存不足，我們只好加上限制內(nèi)存的參數(shù)，防止OGG進程內(nèi)存占用過大。

前文有提到，OGG軟件對于備庫的支持不好，所以如果抽取進程部署在備庫，最好讓抽取進程僅從歸檔抽取，就是下面這個參數(shù)：

隨之帶來的問題就是，數(shù)據(jù)同步的時間永遠會差一個歸檔的時間，就是必須得等源端的redo log寫入歸檔并且傳輸?shù)絺鋷炝?，OGG進程才能開始讀取。不過我想在時效性和可用性之間，應(yīng)該都會選擇可用性吧。

前面還提到過，每月出賬時間，可能會有十幾個小時的延遲，就算是物理備庫，也經(jīng)常會出現(xiàn)幾個小時的延遲。主庫可以配置歸檔的備份刪除策略，讓歸檔未在備庫應(yīng)用時不被刪除，但OGG不行啊。所以我們改造了NBU的備份腳本，每次歸檔備份時，讀取OGG進程當前讀取到的歸檔sequence號，僅備份刪除此sequence號之前的日志。

實際運維中，遇到的問題不僅僅是這些，篇幅問題，就不一一列舉了，歡迎感興趣的朋友可以在評論區(qū)留言交流OGG運維中的坑。

雖然目前的構(gòu)架、方案可以滿足應(yīng)用的需要，但技術(shù)更新、版本迭代不可避免，隨著數(shù)據(jù)庫版本的不斷升級，當前環(huán)境勢必會在日后會不滿足需求，需要我們提供更好，更完善，更便于維護的方案。

目前我們思考的升級方式是使用OGG Integrated Mode（downstream方式），建立一個mining database統(tǒng)一接收多源端的歸檔日志，并創(chuàng)建相對應(yīng)的抽取進程，使之獲得與在主庫部署的集成模式（Integrated Mode）抽取進程一樣的支持。

同時，mining database可以創(chuàng)建RAC，避免單點故障。這種構(gòu)架還能解決一個非常棘手的問題，那就是源端的主備庫切換。在現(xiàn)有構(gòu)架中，源端一旦發(fā)生主備庫切換，就有可能帶來數(shù)據(jù)不一致的風(fēng)險，而且必須要人工干預(yù)，有可能還會需要對部分表做重新初始化，這都是額外的工作量。

而使用downstream方式則不會有此問題，因為mining database只是接收源端的歸檔，至于抽取進程里配置的連接主庫的TNS問題，通過域名就可以解決。我猜想最多在發(fā)生主備切換時，重啟一下mining database上的抽取進程就可以了，那就高枕無憂了！當然，有待我們后續(xù)的測試驗證，這點我也很期待……

好了，有了新的構(gòu)架，我們還是繞不開源端數(shù)據(jù)庫版本升級的問題，但至少我們把需要升級的服務(wù)器從“N源端+1中轉(zhuǎn)+1目標端”減少為了“1 mining database+1目標端”，至少風(fēng)險點看上去是減少了。但具體的實現(xiàn)，我們還需大量的測試驗證，比如如果mining database的數(shù)據(jù)庫版本高于源端，OGG還能不能正常工作，這就是測試的重中之重。

最后，放一張官方的構(gòu)架圖：

在做這個項目的過程當中，雖然碰到過不少莫名其妙的坑，但也確實收獲了很多經(jīng)驗教訓(xùn)，讓我對OGG的實施運維有了很多新的認識。但是技術(shù)總是會不斷更新，我們總得不斷嘗試，才能有所得，與諸君共勉。

特別推薦一個分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關(guān)注的小伙伴，可以長按關(guān)注一下：
長按訂閱更多精彩▼
如有收獲，點個在看，誠摯感謝