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