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