还在继续给客户迁移不同的系统到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管理功能确实是有缺失，建议官方可以优化一下或者暂时先关闭
转载请注明出处，欢迎邮件交流：zhangrou@printhelloworld.com，或者加QQ群：11444444