還在繼續給客戶遷移不同的系統到Azure，這一次是一個系統的MySQL數據庫要遷移，將遷移過程記錄一下
原系統環境
數據庫版本：MySQL Community Edition 5.7
服務器環境：自建機房虛擬化環境，E7 4820 分配8核32G，主節點+非熱備災備節點
運維方式：每日夜間停止服務，ETL程序備份全庫至災備環境
數據規模：用戶與業務表相關表，記錄數據量在500萬級別以內；日誌表，記錄數據量在5000萬條以內，總數據存儲量在50G
Azure環境選擇
考慮到Azure並不擅長MySQL的PaaS服務（這是我自己的意淫），所以原本計劃在Azure上新建相同配置的虛擬機並安裝同樣的MySQL版本，後經過與Azure專家的溝通，確認Azure的MySQL數據庫服務是適合並且穩定的服務於商用環境的，所以最終的方案是，新建一個MS4規模的MySQL庫，在官網可以查詢到MS4規模如下：
可以看到有100G的空間，應該是足夠的，1000的連接數也是綽綽有餘
對比一下阿里雲的價格
其實這樣直接對比沒什麼意義，但是相對而言，阿里雲的MySQL看上去還是稍微便宜點
開始在Portal中新建MySQL數據庫
可以看到這裏還加了一個（預覽），可能還是一個內部在持續研發的產品吧
下面選擇配置並輸入管理員賬號和密碼
等待一會後，創建完成
可以看到，這裏沿用了和SQL Azure一樣的結構，即服務器-數據庫的架構，需要自己新建數據庫和賬號
然後就發現一個比較坑爹的地方，就是新的Portal面板，功能缺失嚴重，竟然沒有防火牆管理，密碼管理也有BUG，從而導致一直無法通過Navicat訪問成功，幸好想起1年前曾經在經典面板中看到過相關功能，於是前往經典面板，發現了這臺新建的數據庫，並且找到了防火牆配置
於是添加一條允許所有IP地址的規則，用於臨時數據遷移
後來經過與Azure專家的溝通得知，新的控制面板還不全面，後續會加一些提示，提醒用戶前往經典面板進行管理，或者會臨時關閉新面板上的MySQL管理
下面就開始進行正式的數據遷移
首先是對原數據庫的備份
由於我對數據庫非常不精通，而MySQL就更不熟悉了，所以爲了保險起見，做了如下準備工作
1、在夜間操作
2、關閉了所有對外的Web服務
3、停止MySQL服務，對MySQL的數據庫文件目錄（Data目錄）進行了文件拷貝備份（50G），數據庫級的備份就沒有做了，因爲ETL程序每天有備份
然後開始選擇遷移方式
事先想到了三種可能的遷移方式，經過搜索最終用瞭如下兩個工具
1、Navicat For MySQL
試用了一下里面的數據傳輸功能，原理上應該是逐條偏移讀取數據，再傳輸，用這個做數據傳輸肯定不行，但是Navicat有個特別好用的功能，就是導出MySQL數據結構，於是用Navicat導出了數據結構
然後再連接到Azure庫，執行剛纔導出的SQL語句，於是就成功的在Azure庫中把所有表建好了（包含索引）
2、使用MySQL的SELECT INTO OUTFILE 、LOAD DATA FILE
我不是MySQL專家， 導入導出只能百度，搜索了一下，大部分文章均推薦使用SELECT INTO OUTFILE方式進行快速的導入導出，效率最高，所以我也選擇了這種方式
先找一個300萬數據的表試試看
可以看到，260萬條數據，4分鐘導出完成
然後再連接到Azure服務器，執行導入命令，悲劇了，提示沒有權限哈哈。
經過與Azure專家的溝通，原來LOAD DATA FILE的時候，要加上Local關鍵詞，這樣數據就識別爲從客戶端讀取，而不是服務器上的路徑，於是導入試試看
由於帶寬受限（5M），所以260萬條數據花了40分鐘才全部導入成功
不過這也算是成功的開始了
3、實戰一下AzureMySQL的速度
進行了一個用戶暱稱的關鍵詞Like查詢，原服務器耗時114秒，Azure服務器耗時2秒，哈哈哈，真是不錯啊！！！！然後我就嚴重懷疑原服務器的性能和優化都存在很大問題！
好了，至此爲止，已經可以說順利的完成了遷移的所有的技術調研和測試，剩下的就是緩慢的表的數據的導入導出了，然後還是要總結一下
總結
1、MySQL的數據遷移，還是比較容易的，可搜索到的資料也很多，特別是數據的導入導出，有很多種辦法，都可以嘗試嘗試
2、Azure的MySQL版整體上看，功能比較簡單傻瓜，適合我這樣的初級DBA，而在命令行模式下，應該有更多可深入挖掘的參數設置、運維功能
3、今天僅僅是遷移，後續在實際運行中可能還會遇到需要解決的場景和問題，我會保持跟進，隨時記錄
4、Azure新Portal裏面的MySQL管理功能確實是有缺失，建議官方可以優化一下或者暫時先關閉
轉載請註明出處，歡迎郵件交流：[email protected]，或者加QQ羣：11444444