本文來自微信公眾號“twt企業(yè)IT社區(qū)”，作者/韓鋒，CCIA（中國計算機(jī)協(xié)會）常務(wù)理事，前Oracle ACE，騰訊TVP，阿里云MVP，dbaplus等多家社群創(chuàng)始人或?qū)＜覉F(tuán)成員。有著豐富的一線數(shù)據(jù)庫架構(gòu)、軟件研發(fā)、產(chǎn)品設(shè)計、團(tuán)隊管理經(jīng)驗。曾擔(dān)任多家公司首席DBA、數(shù)據(jù)庫架構(gòu)師等職。在云、電商、金融、互聯(lián)網(wǎng)等行業(yè)均有涉獵，精通多種關(guān)系型數(shù)據(jù)庫，對NoSQL及大數(shù)據(jù)相關(guān)技術(shù)也有涉足，實踐經(jīng)驗豐富。曾著有數(shù)據(jù)庫相關(guān)著作《SQL優(yōu)化最佳實踐》、《數(shù)據(jù)庫高效優(yōu)化》。
隨著近些年來數(shù)據(jù)庫的變化，正有越來越多的企業(yè)面臨將傳統(tǒng)數(shù)據(jù)庫遷移到開源或新型商業(yè)產(chǎn)品上。在這一過程中，會面臨諸多問題。這里就將常見的一些問題整理出來，希望能夠在數(shù)據(jù)庫選型及評估數(shù)據(jù)庫遷移風(fēng)險等方面有所幫助。為了描述清晰，我將整個遷移過程劃分為幾個階段，其中橙色標(biāo)識工作為數(shù)據(jù)庫團(tuán)隊來支持。下面將就每個階段，詳細(xì)展開說明。
1.階段：遷移準(zhǔn)備
1).遷移規(guī)劃
在進(jìn)行遷移之初，首先要對遷移工作做個整體規(guī)劃，制定好對應(yīng)的原則方針。例如明確遷移范圍、遷移方式、是否可停機(jī)、窗口期等等。這些信息是作為后續(xù)遷移的指導(dǎo)性原則，遷移方案的制定很多需依靠這一規(guī)劃。要避免出現(xiàn)快要遷移，發(fā)現(xiàn)預(yù)期不符合要求的情況，在提前做好必要的規(guī)劃。此外，除技術(shù)因素外，其他如組織、管理、資源等，也在這一階段一并考慮。遷移是個很復(fù)雜的過程，涉及的方方面面很多，盡量在項目之初就有個全面的掌握。
2).業(yè)務(wù)梳理
要完成數(shù)據(jù)庫遷移，上層的業(yè)務(wù)系統(tǒng)也是需要考慮的，甚至在某種程度講，配套的應(yīng)用遷移更加重要，在后續(xù)的遷移過程中占比也更高、難度也更大。因此，在遷移準(zhǔn)備階段，就對涉及的業(yè)務(wù)有個全面的梳理非常有必要。這里需要梳理的信息，非常寬泛。包括但不限于對業(yè)務(wù)系統(tǒng)涉及的軟硬件環(huán)境、與數(shù)據(jù)庫交互、業(yè)務(wù)系統(tǒng)間調(diào)用關(guān)系等。后續(xù)在做應(yīng)用系統(tǒng)改造規(guī)劃中，上述信息非常重要，其有助于評估工作難點、工作量等。這里舉個例子，某系統(tǒng)之前使用Oracle，開發(fā)采用C語言，在遷移到某國產(chǎn)庫時發(fā)現(xiàn)，數(shù)據(jù)庫不支持C driver，好不尷尬。
3).方案選型
在做好業(yè)務(wù)梳理后，就是數(shù)據(jù)庫選型。這一過程也是遷移準(zhǔn)備階段比較耗時的一個工作。如何從眾多的數(shù)據(jù)庫產(chǎn)品中選擇一款符合自己要求的，要考慮的因素很多。比較推薦的做法，是在公司內(nèi)部之前就制定出推薦的方案矩陣，根據(jù)對數(shù)據(jù)庫能力要求、系統(tǒng)重要程度等，制定一個產(chǎn)品選型矩陣。如果前期有這個基礎(chǔ)，就比較簡單，只要按圖索驥即可。如果沒有的話，需要從頭完成一系列的工作，包括初始調(diào)研、技術(shù)評估、數(shù)據(jù)庫評測（功能、非功能、業(yè)務(wù)等）、適配性評估等。這里強(qiáng)調(diào)一個原則就是盡量在方案選型中保持最大的自由度，即不綁定單一廠商，隨時保持可替換能力。因此在方案選型中，不能本著業(yè)務(wù)少改造、遷移最簡單、成本最低的方案，而是應(yīng)選擇長期可替代的原則。推薦的做法是選擇兼容通用協(xié)議的產(chǎn)品，盡量弱化數(shù)據(jù)庫端能力，選擇使用標(biāo)準(zhǔn)數(shù)據(jù)庫功能的產(chǎn)品最好。
4).技術(shù)培訓(xùn)
在方案選擇完畢后，需進(jìn)行技術(shù)培訓(xùn)。這里說的培訓(xùn)，包含對研發(fā)、運維等多方面。對研發(fā)人員的培訓(xùn)，著重闡述此數(shù)據(jù)庫在架構(gòu)設(shè)計、結(jié)構(gòu)優(yōu)化、SQL語句等方面與原有數(shù)據(jù)庫的差異。如選擇通用性產(chǎn)品，則此處的工作較少，也就是方便進(jìn)行其他庫間的遷移。這里面有個原則就是不遷就研發(fā)，該做的必要修改還是要修改。例如，在很多去O工作中，為了盡量減少遷移工作，很多項目選擇兼容Oracle語法、甚至存儲過程的產(chǎn)品。此類產(chǎn)品確實減少了遷移工作量，但從長遠(yuǎn)角度來看并不是一個很好的選擇。對運維的培訓(xùn)，則側(cè)重如何將這種新的數(shù)據(jù)庫融入到現(xiàn)有的運維體系中。特別是當(dāng)前很多分布式架構(gòu)數(shù)據(jù)庫，與傳統(tǒng)集中式數(shù)據(jù)庫不同，其對于運維帶來的挑戰(zhàn)也更大。
2.階段：遷移評估
1).資源評估
做好準(zhǔn)備工作后，開始啟動之前，根據(jù)之前梳理的業(yè)務(wù)情況、所做的數(shù)據(jù)庫選型等信息，開始做必要的評估工作。這里的評估主要是為了后續(xù)遷移改造做好準(zhǔn)備。首當(dāng)其沖的就是資源評估，即完成上述遷移所需資源。這里有個隱藏的工作，就是相關(guān)的技術(shù)方案需要制定出來，包括數(shù)據(jù)庫及應(yīng)用端的。畢竟數(shù)據(jù)庫能力不是一對一對等的，因此架構(gòu)上會有很多調(diào)整甚至是重構(gòu)。但這里所做的評估，相對還是比較粗的，因為很難對資源消耗有個細(xì)粒度的描述，做后者的前提是有完整的評測數(shù)據(jù)為基礎(chǔ)。為什么在這個階段就要做此工作呢？主要是因為很多傳統(tǒng)企業(yè)是采用預(yù)算制，需要提前很長周期做好后續(xù)的采購規(guī)劃。因此將資源評估工作做了前置。
2).應(yīng)用評估
在這個階段要完成在數(shù)據(jù)庫選型確定后，應(yīng)用的評估工作。包括應(yīng)用方案的調(diào)整（甚至重構(gòu)）、應(yīng)用的代碼修改量、可能潛在的風(fēng)險等等。這里主要是由應(yīng)用架構(gòu)師來完成上述評估。
3).對象評估
完成應(yīng)用評估后，下面就是數(shù)據(jù)庫評估的。其評估的第一項就是對象評估，即對數(shù)據(jù)結(jié)構(gòu)的評估。數(shù)據(jù)庫的能力層次不齊，原有的數(shù)據(jù)結(jié)構(gòu)大概率都無法直接復(fù)用了，需要進(jìn)行必要的調(diào)整甚至重新設(shè)計。這里有個建議，就是盡量減少數(shù)據(jù)庫端復(fù)雜對象的使用，盡量只考慮表及索引的設(shè)計，其余包括視圖、序列、觸發(fā)器、存儲過程、函數(shù)、包等都通過外部的等價設(shè)計來完成。這點主要是出于減少對數(shù)據(jù)庫的依賴所提出的，畢竟后面這個功能的實現(xiàn)差距非常大。當(dāng)然，隨之帶來的外部等價實現(xiàn)的工作量也需要進(jìn)行評估。此外，如果是分布式數(shù)據(jù)庫方案，還需要考慮例如分片策略等。這里有個常見的通病，就是將原有設(shè)計原封不動地在新環(huán)境中落地，然后修改語法不兼容的部分就算是完成這一過程。其帶來的后果，往往是上線后問題頻出。
4).SQL評估
對象評估之后，開始對SQL語句的評估。較之前的經(jīng)驗，這部分也是較難評估的。比較推薦的做法是抓取源端的全量SQL，根據(jù)掌握的目標(biāo)庫的適配能力，做此評估工作。例如之前在去O的工作中，就從下面幾個維度來評估SQL，包括了SQL復(fù)雜度（多表關(guān)聯(lián)、文本過長等）、Oracle方言語法、特有語法（函數(shù)、偽列等）等。這些評估出的SQL，后續(xù)都將作為后續(xù)修改的依據(jù)。這里存在一個難點，就是兩種數(shù)據(jù)庫有相同SQL，但處理效果是有差異的情況，這些可能導(dǎo)致非預(yù)期的行為，也最好篩選出來。上述可通過簡單工具掃描SQL文本完成，例如我之前分享的一個小工具。
3.階段：遷移改造
1).對象改造
對象改造，對數(shù)據(jù)對象進(jìn)行改造。有些對象僅做簡單的映射修改就可以了，有些則需要大的重構(gòu)，甚至需要拆分、組合處理。很多對象（特別是復(fù)雜對象或重計算類對象），建議從數(shù)據(jù)庫端剝離，在上層等價實現(xiàn)。因此對象改造工作，不僅僅是DBA的工作，也有部分是需要應(yīng)用研發(fā)參與的。針對上述修改工作，特別是一些關(guān)鍵業(yè)務(wù)表，是需要通過一定手段進(jìn)行驗證測試的。
2).SQL改造
SQL改造，往往是在整個遷移過程中，最為浩大的工作。這主要是由于SQL代碼散落在應(yīng)用各處，需要統(tǒng)一修改。如果使用了OR Mapping工具還好，如果有硬code，改起來還是挺吃力的。目前有很多工具（包括開源的），通過指定源和目標(biāo)庫，輸入SQL語句協(xié)助完成改造工作。但這種方式，往往也僅僅起到輔助作用，轉(zhuǎn)換后的結(jié)果還是需要人工的審核修改工作。要保證語義等價，也要保證執(zhí)行效率等等。
3).應(yīng)用改造
配合遷移工作，應(yīng)用也存在改造的工作量。例如有些在數(shù)據(jù)庫端實現(xiàn)的邏輯，是需要改在應(yīng)用端實現(xiàn)的；有些應(yīng)用本身在新數(shù)據(jù)庫架構(gòu)下就需要進(jìn)行適配性改造等等。
4).功能測試
在數(shù)據(jù)庫改造（對象+SQL）和應(yīng)用改造均完成后，還需要一個關(guān)鍵步驟—功能測試。按業(yè)務(wù)功能拆分，針對每個獨立功能，從應(yīng)用側(cè)角度進(jìn)行測試驗證，來保證上述改造的結(jié)果是正確的，性能是符合預(yù)期的。此處的功能測試，與后面的上線交割的功能測試不同，更強(qiáng)調(diào)是以小的應(yīng)用單元為測試目標(biāo)。這樣便于隨時修改，隨時測試。
4.階段：遷移數(shù)據(jù)
1).遷移方案
改造工作完成后，就進(jìn)入了遷移數(shù)據(jù)環(huán)節(jié)。在遷移之初，最先確定的是遷移方案，這主要取決于對源目標(biāo)端的數(shù)據(jù)庫、物理環(huán)境、遷移窗口、是否并行、是否回退等諸多因素。在大的方面可分為應(yīng)用側(cè)同步、數(shù)據(jù)庫側(cè)同步、存儲側(cè)同步三種方式，各有優(yōu)勢點吧。個人建議，如果能在應(yīng)用側(cè)處理，盡量在應(yīng)用側(cè)；其主要原因是與業(yè)務(wù)結(jié)合緊密、同步驗證容易、方便并行回退等等。但這種方案的缺點在于，需要應(yīng)用側(cè)有大量修改工作，無法形成統(tǒng)一標(biāo)準(zhǔn)的方案。一般針對核心、重要的系統(tǒng)，建議采取應(yīng)用側(cè)同步的方式。針對數(shù)據(jù)庫、存儲端同步方案，一般都是較為通用的方案。下文重點講述數(shù)據(jù)庫同步的方式。
2).結(jié)構(gòu)遷移
結(jié)構(gòu)遷移，是將數(shù)據(jù)結(jié)構(gòu)的遷移。一般這一過程是可以提前完成的。數(shù)據(jù)結(jié)構(gòu)確定后，即可完成這一過程。不與后面數(shù)據(jù)同步放在一起，是為了便于出現(xiàn)問題時的排查分析。
3).全量遷移
如數(shù)據(jù)規(guī)模很大，可將整個過程劃分為全量+增量遷移兩部分。全量同步，一般是可離線、靜態(tài)去做，通過備份恢復(fù)、導(dǎo)入導(dǎo)出等方式，將絕大部分?jǐn)?shù)據(jù)遷移過去。這部分不放在停機(jī)窗口中，可提前進(jìn)行。并在遷移之后，記錄一個位點。
4).增量遷移
增量遷移，從全量遷移記錄位點開始。根據(jù)遷移技術(shù)本身，可采取停機(jī)或不停機(jī)的方式。一般都是通過追log的方式，逐步追齊數(shù)據(jù)，并短時靜默應(yīng)用，完成數(shù)據(jù)最終達(dá)到一致的狀態(tài)。
5.階段：上線交割
1).SQL審核
在上線交割之前，還需要完成部分前置工作。SQL審核，是為了保證SQL上線前的運行質(zhì)量。SQL審核細(xì)分，可分為事前、事中、事后審核，這里更多指事前審核部分。即在開發(fā)過程中，針對SQL運行情況給予評估判斷，來保證上線后的質(zhì)量可控。一般是通過預(yù)定義一組規(guī)則，完成對語句的審核。這一過程貫穿在整個開發(fā)過程中。
2).數(shù)據(jù)校驗
數(shù)據(jù)遷移后，在上線前還需要對數(shù)據(jù)同步后的質(zhì)量有所判斷，這就引入數(shù)據(jù)校驗的初衷。嚴(yán)格來講，這是數(shù)據(jù)質(zhì)量保證的一部分。其作用是對同步兩邊的數(shù)據(jù)是否一致做出判斷，來整體把握同步質(zhì)量，也是為后面是否正式切換的判斷依據(jù)之一。這里存在幾個難點，一是海量數(shù)據(jù)如何快速比對，二是異構(gòu)條件下數(shù)據(jù)如何比對，三是兩側(cè)數(shù)據(jù)同步變化時如何比對？目前已經(jīng)有些產(chǎn)品能夠支持較為完整的數(shù)據(jù)校驗功能。個人也是比較建議，在數(shù)據(jù)遷移后進(jìn)行對比。雖然這里有些成本，但要比運行一段時間后發(fā)現(xiàn)差異而無法回退好的多。
3).功能測試
在正式遷移前，針對遷移后的全量環(huán)境做完成的業(yè)務(wù)功能測試是非常必要的。需要對遷移后的結(jié)果有個全局的掌握。一方面可以驗證整個遷移過程是否OK，另一方面也可為后續(xù)正式遷移提供基線判斷標(biāo)準(zhǔn)。
4).性能測試
在功能測試的同時，還需保證遷移后的性能滿足預(yù)期設(shè)定，因此性能測試也必不可少。這里可以使用數(shù)據(jù)庫側(cè)進(jìn)行性能測試，但更建議是從應(yīng)用側(cè)完成性能測試，因為后者是從用戶視角，更具有說服力。
6.階段：運行保障
1).數(shù)據(jù)庫運維
遷移完成，系統(tǒng)上線后就進(jìn)入到運行保障階段。從數(shù)據(jù)庫來說，提供的基本能力之一就是基于新數(shù)據(jù)庫架構(gòu)下的運維能力。對于一個新的選型來說，需要將新品種數(shù)據(jù)庫納入到整體的運維體系中，這其中涉及的工作不少。一般是需要提前規(guī)劃完成的。
2).高可用保障
除了日常運維外，高可用被獨立出來，主要是這部分重要性很高。新的數(shù)據(jù)庫選型，代表著運行風(fēng)險更高，如何保證高可用值得關(guān)注。一般是建議提前規(guī)劃好高可用方案（而不是上線后），并進(jìn)行周全的高可用切換測試。甚至上線后，可應(yīng)保證一定頻率的切換演練，做到有備無患。
3).運行優(yōu)化
遷移后上線運行，運行效率值得關(guān)注。新的數(shù)據(jù)庫選型，對穩(wěn)定性運行會帶來一定調(diào)整。作為運行保障的一部分，建立其完備的運行優(yōu)化能力非常必要，包括基本的慢查詢、日志、栓鎖、會話等診斷工具及對應(yīng)的處理措施。這一點對于國產(chǎn)庫尤為重要，近些年來國產(chǎn)數(shù)據(jù)庫發(fā)展迅速，但相較于其內(nèi)核功能發(fā)展，上述周邊管理優(yōu)化能力發(fā)展不足，需要提前關(guān)注。
4).應(yīng)急響應(yīng)
作為最后的保障措施，當(dāng)出現(xiàn)問題時的應(yīng)急響應(yīng)是需要提前規(guī)劃的。這里更多是流程制度的設(shè)定，保證出現(xiàn)問題時及時感知、及時修復(fù)，不影響業(yè)務(wù)。
