本文聊聊服務化過程中我曾經的資料遷移經歷。
服務化，其中乙個重要意義在於資料隔離，也就意味著服務化過程要拆分現有資料庫，進而涉及到資料遷移。
資料遷移過程我們要注意哪些關鍵點呢？第一，保證遷移後資料準確不丟失，即每條記錄準確而且不丟失記錄；第二，不影響使用者體驗（尤其是訪問量高的c端業務需要不停機平滑遷移）；第三，保證遷移後的效能和穩定性。
資料遷移我們經常遇到的兩個場景：
1，業務重要程度一般或者是內部系統，資料結構不變，這種場景下可以採用掛從庫，資料同步完找個訪問低谷時間段，停止服務，然後將從庫切成主庫，再啟動服務。簡單省時，不過需要停服避免切主庫過程資料丟失
2，重要業務，併發高，資料結構改變。這種場景一般需要不停機平滑遷移。下面就重點介紹這部分經歷。
網際網路行業，很多業務訪問量很大，即便凌晨低谷時間，仍然有相當的訪問量，為了不影響使用者體驗，很多公司對這些業務會採用不停機平滑遷移的方式。因為對老資料遷移的同時，線上還不斷有使用者訪問，不斷有資料產生，不斷有資料更新，所以我們不但要考慮老資料遷移的問題，還要考慮資料更新和產生新資料的問題。下面介紹一下我們之前的做法。
關鍵步驟如下：
將某時間戳之前的老資料遷移到新庫（需要指令碼程式做老資料遷移，因為資料結構變化比較大的話，從資料庫層面做資料遷移就很困難了），注意：1，時間戳一定要選擇開啟雙寫後的時間點，避免部分老資料被漏掉；2，遷移過程遇到記錄衝突直接忽略（因為第一步有更新操作，直接把記錄拉到了新庫）；遷移過程一定要記錄日誌，尤其是錯誤日誌
第二步完成後，我們還需要通過指令碼程式檢驗資料，看新庫資料是否準確以及有沒有漏掉的資料
資料校驗沒問題後，開啟雙讀，起初新庫給少部分流量，新老兩庫同時讀取，由於時間延時問題，新老庫資料可能有些不一致，所以新庫讀不到需要再讀一遍老庫。逐步將讀流量切到新庫，相當於灰度上線的過程。遇到問題可以及時把流量切回老庫
讀流量全部切到新庫後，關閉老庫寫入（可以在**裡加上可熱配開關），只寫新庫
遷移完成，後續可以去掉雙寫雙讀相關無用**。
第二步的老資料遷移指令碼程式和第三步的檢驗程式可以工具化，以後再做類似的資料遷移可以復用。
目前各雲服務平台也提供資料遷移解決方案，大家有興趣也可以了解一下！
資料庫應用程式遷移所帶來的問題
從一台32核cpu,30g記憶體，800m硬碟的機器上。遷往到雙節點rac機器上，該機器每個節點8核cpu 是雙核 4.硬碟和記憶體沒什麼變。聽起來是遷往一台高效能機器上，很令人興奮不已，雙節點哦！實際上效果並非如此，其中乙個節點被另外個資料庫所占用，也就是那台節點基本上不能全力去工作，相當於單節點...
伺服器公升級帶來的問題
系統環境 centos release 6.8 8核16g 使用的服務 nginx uwsgi celery redis mysql mongo 由於業務的需要，公升級到16核32g，公升級後啟動服務報錯 can t start new thread。開始一直以為是程式的問題，經過各種搜尋，修改，問...
Oracle資料遷移的問題
首先如果是大型應用並且資料量確實非常大推薦直接使用oracle，不建議從sql server後期遷移，因為遷移的成本是非常高的 包括停機成本，測試，以及承擔bug的風險等 例如 sql server 到oracle。主要有以下幾個問題 1 資料型別差異 儘管大多數資料型別通用，但仍有專屬資料型別，例...