作者介紹

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

因?yàn)榈厥胁樵兊木唧w需求也不要求這類表做到實(shí)時(shí)同步，之前底層存儲(chǔ)復(fù)制的方式，數(shù)據(jù)也有一天的延遲，所以完全可以滿足需求。如果有新增表同步的需求，也會(huì)有標(biāo)準(zhǔn)化的操作流程，對(duì)已同步的表不會(huì)造成大的影響。

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

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

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

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

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

謝天謝地，當(dāng)前我們除了碰到壓縮表不支持之外，幾乎沒(méi)有碰到其他類型的表不支持問(wèn)題，而壓縮表也基本都是很老的歷史表，幾乎無(wú)變更。所以對(duì)我們來(lái)說(shuō)這點(diǎn)倒是不頭疼。

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

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

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

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

隨之帶來(lái)的問(wèn)題就是，數(shù)據(jù)同步的時(shí)間永遠(yuǎn)會(huì)差一個(gè)歸檔的時(shí)間，就是必須得等源端的redo log寫(xiě)入歸檔并且傳輸?shù)絺鋷?kù)了，OGG進(jìn)程才能開(kāi)始讀取。不過(guò)我想在時(shí)效性和可用性之間，應(yīng)該都會(huì)選擇可用性吧。

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

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

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

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

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

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

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

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

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

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