本文轉載自微信公眾號「 虞大膽的嘰嘰喳喳」，作者虞大膽。轉載本文請聯系 虞大膽的嘰嘰喳喳公眾號。

這周將核心數據庫遷移到阿里云RDS了，為什么要遷移?以前文章也說過好多次了，最近一年感覺自己也是半個DBA了，但再搞下去就需要更專業的知識，再加上數據庫是一個產品的命根，托管還是更穩妥。而且RDS和周邊服務有很多功能，比自己弄更好，更省力。

在購買RDS產品過程中，也和對接的運營經理溝通過好幾次，說實話能感覺到對方解決問題的誠意，反而是拉的一個專家群印象一般，也許這不是他們的核心工作，如果有問題還是走工單系統比較穩妥。

提前做了很多調研，對于功能，成本，規格選擇做了很多工作，如果要合理利用，還是要死磕文檔，在溝通中也發現阿里云的對接人員也有很多并不了解的。

很久沒做系統級的變更了，尤其是數據庫層面的，自己剛進sina的時候，第一周就體驗了一把數據庫擴容，那時候是暫停所有服務，然后使用腳本將數據庫導入導出。而反觀現在，基本上不允許你中斷服務，同時依賴于阿里云的DTS服務，遷移工作真的是方便了很多，這也是技術進步的一種體現。

這次通過DTS將mysql從5.6升級到了5.7，至于提升了什么，后面再繼續分享，原來有個同事說都用mysql 8.0，所以也并不能太保守，本來想著升級到mysql5.6，最終選擇了mysql5.7。

遷移方案首先要保證穩健性，其次要保證安全性，最后要保證體驗，三者之間可以做些取舍，雖然DTS也支持雙向同步，但和mysql主主同步一樣，具體實施的時候有很多限制，所以整體的方案沒有做到完全無感知。

具體的方案在遷移過程中(必然要有操作時間)鎖住源庫的更新;同時遷移完成后，將新庫的數據同步到源庫(為了做回滾)。因為涉及到源庫和目標庫的版本不一樣，所以新庫到源庫的同步并沒有做。

阿里云的DTS服務確實很不錯，后面可以多說一些，使用的場景非常寬泛，即使你沒有使用阿里云的服務，也建議可以嘗試一下，不過今天也發現DTS的同步畢竟不是原生的同步，速度上會受到很多制約。

在實施過程中，也收獲了很多，比如mysql中的readonly和全局讀鎖區別;mysql5.7的sql_mode;gtid中的reset master和reset slave;gtid同步異常怎么辦(以前是忽略跳過，但這會導致數據不一致性);賬號授權規則的重要性(分級，授權范圍越小越好，比如只授權給proxy);主從同步最好也同步mysql庫(這樣很多信息主從庫能保持一致)，但庫的配置信息(比如pool size)無法同步;切換主從并沒有原先想的那么復雜，包括升級版本。

整個遷移過程一定要提前模擬好，而且模擬的越真實就會減少錯誤的存在，而越真實的模擬就要考驗整體架構的合理性，和同事討論了多次，目的也是校驗大家理解的是否一致，是否有更多好的建議，在具體操作過程中，也是兩個人一起弄，一方面是加強信心，另外也能互相提醒。整體實施的時候有一個checklist，目前看來還是比較順利的。

如果要說給阿里云RDS一個建議，就是將它的讀寫分離功能獨立出來，什么意思呢?可以產生多個讀寫分離實例，可以無限組合主從實例，甚至這些實例都不一定要求是RDS。

RDS遷移的第一步完成了，但后續還有很多的細節，在做一個事情的時候，其實成敗不在于開始，而是在于后面，這方面自己有一些體會，比如說一個解決方案從大方向上很牛逼，但缺乏對于細節的思考，沒有考慮后續的開發復雜度、通用性，會導致成為一個四不像。

但有了一個好的開始，走出了扎實的一步，很喜歡這周聽到的這句話。