為了對(duì)核心技術(shù)擁有更多的自主控制能力，為了解決數(shù)據(jù)庫的線性擴(kuò)展問題，為了盡量減少對(duì)商業(yè)軟件的依賴，為了擺脫對(duì)高端硬件的依賴，為了…基于以上多種原因，2年前，我們計(jì)劃將公司某核心應(yīng)用平臺(tái)進(jìn)行大手術(shù)：數(shù)據(jù)庫平臺(tái)從軟件到硬件全部重構(gòu)。當(dāng)然，這其中應(yīng)用架構(gòu)的改造也不可避免的進(jìn)行了大換血。

　　這個(gè)項(xiàng)目無論是從技術(shù)角度還是是業(yè)務(wù)角度來說，都對(duì)我們有著非常大的價(jià)值，也必定會(huì)帶來非常深遠(yuǎn)的影響。項(xiàng)目歷時(shí)2年多，分4個(gè)階段才完成：

• 應(yīng)用接口統(tǒng)一

這一階段主要是為了后面真正遷移的時(shí)候做準(zhǔn)備工作，將該核心應(yīng)用系統(tǒng)的所有數(shù)據(jù)訪問入口統(tǒng)一到一起，全部以服務(wù)化的接口方式呈現(xiàn)給其他有需要的系統(tǒng)，一來方便后續(xù)變更的控制，二來也推進(jìn)了服務(wù)化的進(jìn)程。

• Oracle數(shù)據(jù)庫中拆分（1拆16）

這個(gè)階段本不是必要的，但是由于項(xiàng)目啟動(dòng)稍微晚了點(diǎn)，數(shù)據(jù)出現(xiàn)了爆發(fā)性增長(zhǎng)，導(dǎo)致該系統(tǒng)的數(shù)據(jù)表太大（單表不帶索引過500GB），原 Oracle 數(shù)據(jù)庫已經(jīng)快撐不住了。為了安全起見，先在 Oracle 中從一個(gè)主表以會(huì)員ID進(jìn)行 hash 運(yùn)算后再進(jìn)行水平拆分，從1個(gè)表分拆成了16個(gè)。附表由于訪問量稍小，而且全部是根據(jù)主鍵訪問，暫時(shí)保留原樣。

當(dāng)然，這樣的水平拆分，必然會(huì)帶來數(shù)據(jù)訪問路由以及數(shù)據(jù)合并的問題。我們專門為此開發(fā)了具有分布式數(shù)據(jù)庫路由/數(shù)據(jù)合并，數(shù)據(jù)庫讀寫分離，數(shù)據(jù)庫鏈接管理等功能的數(shù)據(jù)訪問中間層，專門解決拆分后給應(yīng)用服務(wù)器帶來的影響，使得應(yīng)用服務(wù)器完全感受不到后端數(shù)據(jù)庫的變化。

這個(gè)數(shù)據(jù)訪問中間層，對(duì)前端應(yīng)用服務(wù)器來說，就是一個(gè)完整的數(shù)據(jù)庫，所有數(shù)據(jù)請(qǐng)求都從這里實(shí)現(xiàn)，以協(xié)議的方式和前端應(yīng)用服務(wù)器的jdbc驅(qū)動(dòng)進(jìn)行交互，以便讓數(shù)據(jù)庫對(duì)應(yīng)用服務(wù)器徹底透明。

• Oracle遷移至 MySQL（16拆128）

這個(gè)階段是整個(gè)階段中歷時(shí)最長(zhǎng)，復(fù)雜度最高，風(fēng)險(xiǎn)系數(shù)最高的，未知因素也最多的一個(gè)階段。雖然 MySQL 數(shù)據(jù)庫已經(jīng)在互聯(lián)網(wǎng)行業(yè)占據(jù)了大片江山，但是對(duì)于阿里巴巴來說，卻仍然是一個(gè)新鮮玩意兒，因?yàn)橹拔覀円恢倍加?Oracle 來提供所有的業(yè)務(wù)系統(tǒng)的數(shù)據(jù)庫服務(wù)。

在此之前，我們從來沒有在如此核心業(yè)務(wù)系統(tǒng)的數(shù)據(jù)庫上使用過 PC Server 和本地硬盤來承載數(shù)據(jù)庫，一直是使用 IBM 小型機(jī)和中高端存儲(chǔ)設(shè)備來解決高性能和高可靠的問題。在更換成 PC Server 和本地硬盤來承載數(shù)據(jù)庫之后，我們就必須面對(duì) PC Server 本身硬件可能存在的不可靠性所帶來的 Crash，所以我們必須有一套完善的 HA 切換機(jī)制，要比小型機(jī)廠商所提供的商業(yè) HA 管理軟件更加高效更加自動(dòng)化更加可控，才能我們降低了設(shè)備本身可靠性之后達(dá)到原有的可用性要求。

對(duì)于一個(gè)需要滿足 365 * 24 * 7 的核心業(yè)務(wù)系統(tǒng)來說，肯定是不可能給我們太多時(shí)間來進(jìn)行數(shù)據(jù)遷移的，所以我們不得不設(shè)計(jì)出一個(gè)對(duì)現(xiàn)有系統(tǒng)影響盡可能小的遷移方案，這勢(shì)必會(huì)造成方案的高度復(fù)雜化，帶來更多的風(fēng)險(xiǎn)。最后的遷移方案要經(jīng)歷如下4個(gè)階段：

1. Oracle 讀/寫;；MySQL 初始化并增量寫
2. Oracle 讀/寫； MySQL 寫
3. Oracle 寫； MySQL 讀/寫
4. Oracle 停訪問； MySQL 讀/寫

當(dāng)然，也正式由于有如此復(fù)雜的方案，才確保了在整個(gè)遷移過程中的的停機(jī)時(shí)間被控制在了10分鐘之類。

• 附屬Detail信息遷移至 MySQL

從項(xiàng)目開始，至完成主表拆分結(jié)束，已經(jīng)接近2年了。這2年時(shí)間內(nèi)，數(shù)據(jù)量一直都在飛漲，這讓即使僅僅只是按照主鍵訪問的附表也快無法承受持續(xù)增長(zhǎng)的業(yè)務(wù)壓力，附表的拆分也就成了必行之勢(shì)。由于在原來主表拆分的過程中，整個(gè)項(xiàng)目組已經(jīng)積累了大量的經(jīng)驗(yàn)，附表拆分過程非常順利，基本沒有出現(xiàn)任何問題。雖然附表的拆分過程與主表相比除了 1拆16這個(gè)階段外沒有減少其他任何環(huán)節(jié)，但是整個(gè)拆分過程也才2個(gè)月就全部搞定了。

　　這個(gè)遷移項(xiàng)目算是徹底完成了，但是我們的遷移之路并不會(huì)就此止步，還有很多的系統(tǒng)仍然存在擴(kuò)展性問題，還有很多的數(shù)據(jù)庫應(yīng)用等著我們?nèi)ゲ鸱帧?/p>

　　注：同事們還為此送了我們一個(gè)雖不太雅但也意思相近的名稱“拆遷隊(duì)”。

it知識(shí)庫：核心業(yè)務(wù)系統(tǒng)數(shù)據(jù)庫平臺(tái)遷移： Oracle -> MySQL，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。