本文转载自微信公众号「 虞大胆的叽叽喳喳」，作者虞大胆。转载本文请联系 虞大胆的叽叽喳喳公众号。
这周将核心数据库迁移到阿里云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迁移的第一步完成了，但后续还有很多的细节，在做一个事情的时候，其实成败不在于开始，而是在于后面，这方面自己有一些体会，比如说一个解决方案从大方向上很牛逼，但缺乏对于细节的思考，没有考虑后续的开发复杂度、通用性，会导致成为一个四不像。
但有了一个好的开始，走出了扎实的一步，很喜欢这周听到的这句话。
