Oracle 數(shù)據(jù)庫遷移至 MySQL、PG 等分布式數(shù)據(jù)庫難點(diǎn)交流

面對互聯(lián)網(wǎng)業(yè)務(wù)的不斷深化以及業(yè)務(wù)量的爆發(fā)式增長，傳統(tǒng)數(shù)據(jù)庫架構(gòu)迎來了前所未有的挑戰(zhàn)和變革。在傳統(tǒng)數(shù)據(jù)庫領(lǐng)域，Oracle一直占據(jù)了很大的市場份額，很多企業(yè)的業(yè)務(wù)系統(tǒng)基于此實(shí)現(xiàn)OLTP交易場景。近年來，隨著分布式技術(shù)的發(fā)展，分布式數(shù)據(jù)庫逐漸占據(jù)了OLTP領(lǐng)域較大的市場，尤其在互聯(lián)網(wǎng)領(lǐng)域，MYSQL、PG等分布式數(shù)據(jù)庫的應(yīng)用非常廣泛。隨著軟件國產(chǎn)化、自主可控戰(zhàn)略的提出，去“Oracle”逐漸被提上日程，非互聯(lián)網(wǎng)企業(yè)也開始考慮數(shù)據(jù)庫轉(zhuǎn)型，其中，分布式數(shù)據(jù)庫即是一個重要轉(zhuǎn)型方向。

不同于Oracle數(shù)據(jù)庫的集中式、主從式架構(gòu)，分布式數(shù)據(jù)庫將位于不同地點(diǎn)的多個服務(wù)器通過網(wǎng)絡(luò)互相連接，共同組成一個完整的、全局的大型數(shù)據(jù)庫，它在邏輯上集中、物理上分布；在數(shù)據(jù)存儲上，分布式數(shù)據(jù)庫將數(shù)據(jù)打散存儲在不同服務(wù)器上，故而將數(shù)據(jù)庫壓力分散到不同服務(wù)器上。故而使得分布式數(shù)據(jù)庫具備了可擴(kuò)展性、高并發(fā)性、高可用性等特點(diǎn)。

很多企業(yè)原本都是傳統(tǒng)數(shù)據(jù)庫一體化解決方案，在進(jìn)行Oracle向分布式數(shù)據(jù)庫遷移時會遇到很多難點(diǎn)，傳統(tǒng)數(shù)據(jù)庫設(shè)計與運(yùn)維經(jīng)驗(yàn)不一定完全適合分布式數(shù)據(jù)庫。那么，從Oracle遷移至MYSQL、PG等分布式數(shù)據(jù)庫會遇到哪些障礙？這些障礙是否能順利解決？

（1）不同數(shù)據(jù)庫之間的異構(gòu)數(shù)據(jù)如何做到無損遷移？Oracle存量數(shù)據(jù)如何成功遷移至MYSQL、PG等分布式數(shù)據(jù)庫？

（2）Oracle數(shù)據(jù)庫遷移至MYSQL、PG等分布式數(shù)據(jù)庫過程中如何保障系統(tǒng)穩(wěn)定性？如何設(shè)置異構(gòu)數(shù)據(jù)庫并行過渡期？

（3）Oracle數(shù)據(jù)庫往往和應(yīng)用耦合度較高，遷移過程還會涉及到應(yīng)用遷移和改造，特別是存儲過程、觸發(fā)器、自定義函數(shù)等方面的改造，將業(yè)務(wù)邏輯實(shí)現(xiàn)方從數(shù)據(jù)庫上移至應(yīng)用，那么如何評估改造量和改造難度？兼容性如何保障？

（4）數(shù)據(jù)庫遷移完成后如何成功建轉(zhuǎn)運(yùn)？或者說，在數(shù)據(jù)庫設(shè)計階段如何設(shè)計運(yùn)維方案？除了分布式數(shù)據(jù)庫的高可用、負(fù)載均衡設(shè)計，傳統(tǒng)運(yùn)維方案中的網(wǎng)絡(luò)、存儲、監(jiān)控告警、備份恢復(fù)等等應(yīng)該如何規(guī)劃？