目錄
本文主要講解數據從老庫遷移到新庫過程中遇到的問題，以及針對這些問題給出的解決方案，希望能給你一點點啓發或者幫助。
一 老庫表寫收口
由於多個業務端的多個服務公用一個老庫，且多個服務訪問老庫共用一套密碼。
如何確定只有我們對老庫的表進行寫入呢？
爲了排除還有其他業務端服務直連老庫，寫老庫的表，我們給表添加了一個字段，比如是 A，來標識是我們端對錶的寫入。如果不是我們端對錶的寫入，該字段應該是空值。
爲什麼一定需要確定寫收口呢？
假設有某個業務端的服務對老庫的表進行寫入，然後我們進行了數據遷移，那新老數據庫的表的數據將不一致，這在業務上面是不能忍受的。
二 平滑遷移數據
我們端這塊有4個表，共1億的數據，需要進行遷移。這塊的核心點是：如何解決遷移數據耗時的問題、如何減少錶停寫時間對業務測影響問題。
一開始我們定的方案是 RD 停寫，DBA 通過腳本執行命令，將歷史數據從老庫直接遷移到新庫，整個過程評估預計需要1小時，這將意味着需要停寫1小時，然後將這個結果同步給業務方，業務方無法忍受這個結果。
如何解決遷移數據耗時的問題？
我們使用 ALI 的 DTS 對數據進行遷移。DTS 能同步歷史數據和增量數據。
歷史數據是遷移了，那如何做到平滑呢？
我們這塊將新庫集羣當做老庫的從庫進行數據同步，當我們這塊進行業務停寫的時候、且新庫和老庫的數據一致的時候，DBA 將新庫集羣中的一臺機器升級爲主庫，其他機器掛載到這個主庫，當做這個機器的從庫。
三 業務影響最小
數據遷移過程中，如果能做到對業務無感，是最好的。那如何做好對業務影響最小呢？
首先，我們通過業務數據進行分析，找到業務的低谷。在低谷進行數據遷移操作，對業務影響小。
其次，我們是分鐘級別的停寫，在停寫的時候，我們一直是可讀的。這個在業務上是可以忍受的。
四 增量數據回寫
爲什麼要數據回寫呢？
在遷移數據的過程中，由於一些團隊排期問題，服務讀取的還是老庫，這個時候爲了保證其他團隊能讀取到增量數據，保證業務不受影響，我們這塊通過 Databus 對數據進行了同步，回寫到老庫。
當然了，我們的期望是隻維護新庫，所以我們要求其他業務端對讀收口進行了排期，2個月之後其他業務端都走我們的接口，實現了讀收口。
五 遷移回滾方案
回滾方案在數據遷移過程中不一定需要，但是從一件事情的完整度來說，還是需要的。針對這塊數據遷移，我們需要考慮的是服務回滾、數據庫回滾。
服務回滾？
是說服務從讀新庫切換到讀老庫，這塊可以做一個數據源動態開關，可以靈活切換訪問新老數據源。
數據庫回滾？
如果是增量數據我們需要將它們從新庫同步到老庫，保證數據的完整性。
六 老庫下線
數據遷移完了就完了？不，我們還需要下線老庫。
從公司資產角度考慮，有了新庫，爲了降低成本，我們需要將老庫下線。
從一件事情完整性來看，我們遷移數據只是完成了90%，剩下的10% 我們需要對老庫進行下線處理。
七 事前、事中、事後、我們應該做什麼呢
事前：我們應該給公司的研發和業務發送郵件，郵件的主題、涉及範圍、影響功能、數據遷移時間點、負責人、遷移方案、以及釘釘溝通羣。
事中：我們研發應該和各個業務端確認方案的可行性、與 DBA、QA 建立緊密的溝通，隨時同步方案進度、開發進度、遷移進度。
事後：我們研發應該發郵件告知研發和業務、BI、大數據等團隊，已經完成數據庫的遷移，及時同步遷移結果。釘釘羣裏面也需要同步。