本文轉(zhuǎn)載自微信公眾號「 虞大膽的嘰嘰喳喳」，作者虞大膽。轉(zhuǎn)載本文請聯(lián)系 虞大膽的嘰嘰喳喳公眾號。

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

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

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

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

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

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

具體的方案在遷移過程中(必然要有操作時間)鎖住源庫的更新;同時遷移完成后，將新庫的數(shù)據(jù)同步到源庫(為了做回滾)。因?yàn)樯婕暗皆磶旌湍繕?biāo)庫的版本不一樣，所以新庫到源庫的同步并沒有做。

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

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

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

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

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

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