[[431099]]

今天和同事聊起了一個問題，主要背景是有2個數(shù)據(jù)庫需要數(shù)據(jù)流轉(zhuǎn)至數(shù)倉系統(tǒng)，雖然數(shù)據(jù)庫的存儲容量很大，但是需要流轉(zhuǎn)的數(shù)據(jù)量不大，舉個例子，比如源數(shù)據(jù)庫有100張表占用800G，但是數(shù)據(jù)流轉(zhuǎn)只需要10張表，占用30G, 所以在構(gòu)建數(shù)據(jù)源集市的時候，我們就選擇了多源復(fù)制的模式，把兩個數(shù)據(jù)庫合在一起對外交付，本質(zhì)上還是基于主從復(fù)制的模式，只是更加靈活而已。

近期有個新需求，打破了這種平靜，現(xiàn)在需要新增幾張數(shù)據(jù)表流轉(zhuǎn)至數(shù)倉系統(tǒng)，尷尬的是這幾張表因?yàn)闅v史原因沒有分表，單表的數(shù)據(jù)量在幾億，如果采用邏輯導(dǎo)出導(dǎo)入的方式，需要差不多5個小時左右，而且最關(guān)鍵的是，還帶來了一系列問題：

1）這種數(shù)據(jù)導(dǎo)出導(dǎo)入的模式，數(shù)據(jù)導(dǎo)入完成后的數(shù)據(jù)補(bǔ)齊工作很難，因?yàn)閿?shù)據(jù)是從主庫復(fù)制，所以這個中間節(jié)點(diǎn)上面始終是一種動態(tài)的數(shù)據(jù)處理過程，從理論上來說，是沒有辦法追齊數(shù)據(jù)的

2）數(shù)據(jù)復(fù)制基于GTID，什么時候該做取舍也是個難題，比如其他的10張表在實(shí)時復(fù)制，而新增的表會產(chǎn)生新的GTID,在數(shù)據(jù)沒有應(yīng)用過來之前，會有一系列的GTID無法自動修復(fù)。

如果把這個圖畫的更全面一些，其實(shí)是這樣的結(jié)構(gòu)，默認(rèn)是有數(shù)據(jù)的容災(zāi)節(jié)點(diǎn)的，中間節(jié)點(diǎn)是直接從主庫進(jìn)行數(shù)據(jù)復(fù)制的。

要解決現(xiàn)在的這個問題，導(dǎo)出導(dǎo)入5個小時顯然是不合理的，而相對來說理想的方式便是基于物理數(shù)據(jù)的處理模式。

一種是傳輸表空間，直接把ibd文件拷貝到中間節(jié)點(diǎn)，然后修復(fù)數(shù)據(jù)的差異，這個時候有兩種修復(fù)差值的模式，一種是基于表中的增量時間來處理，相對不夠通用，第二種則是更嚴(yán)謹(jǐn)?shù)哪Ｊ?，則是修改數(shù)據(jù)的復(fù)制鏈路，基于從庫級聯(lián)復(fù)制即可。

這里的關(guān)鍵便是在開啟傳輸表空間前就停止slave復(fù)制，讓整個系統(tǒng)處于靜止?fàn)顟B(tài)，這樣能夠保證數(shù)據(jù)的完整性，這個過程如果是復(fù)制ibd文件，30G左右的文件大概30分鐘就能搞定。

復(fù)制完成后，可以根據(jù)需求是繼續(xù)保留基于從庫復(fù)制還是重新調(diào)整GTID綁定到主庫端去。

最終的變更狀態(tài)和原來基本保持一致。

第二種處理模式簡單直接，即需要尋找數(shù)據(jù)問題的根因，比如源庫有100張表占用800G，但是需要流轉(zhuǎn)10張表占用30G，那么我們是不是可以直接基于數(shù)據(jù)庫級，實(shí)例級進(jìn)行數(shù)據(jù)復(fù)制，等數(shù)據(jù)復(fù)制狀態(tài)正常后我們把那90張表都清理掉，在處理過程中，對于一些可能出現(xiàn)的復(fù)制異常編碼進(jìn)行統(tǒng)一的過濾處理。這樣我們的數(shù)據(jù)始終是實(shí)時更新的狀態(tài)，無論是狀態(tài)性數(shù)據(jù)實(shí)時更新還是日志型數(shù)據(jù)實(shí)時更新都可以靈活的適配。

同時在這個時候我們對于多源復(fù)制也可以做一些取舍，在這種場景下我覺得使用的意義就不是很大了。

綜上，數(shù)據(jù)復(fù)制是一個很好的數(shù)據(jù)開關(guān)，能夠靈活的適配和處理很多偏向于業(yè)務(wù)需求的數(shù)據(jù)邏輯，在這個過程中，基于系統(tǒng)層，物理的處理模式要遠(yuǎn)比邏輯處理要高效的多。