本文转载自微信公众号“于大胆的推特”，作者于大胆。转载本文，请联系推特上的于大胆公众号。这周，我把核心数据库迁移到了阿里云RDS。为什么我需要迁移？我在之前的文章中已经说过很多次了。过去的一年，感觉自己也是半个DBA，但是继续做的话，需要更多的专业知识。数据库是产品的命脉，托管更安全。而且RDS和周边服务的功能很多，比自己做更好，更省力。在购买RDS产品的过程中，我也和对接的运营经理进行了数次沟通。说实话，我能感受到对方解决问题的诚意。相反，专家组的印象一般。也许这不是他们的核心工作。如果有问题使用工单系统更安全。提前做了很多调研，在功能、成本、规格的选择上做了大量的工作。要想合理使用，还是要坚持看文档。在交流过程中，我也发现很多阿里云的对接人员并不理解。我已经很长时间没有进行系统级别的更改，尤其是在数据库级别。刚进新浪的时候，第一周就经历了数据库扩容。当时把所有服务都挂了，然后用脚本导入导出数据库。相反，现在，基本不允许你中断服务，依赖阿里云的DTS服务。迁移工作真的方便很多，这也是技术进步的体现。这次通过DTS把mysql从5.6升级到5.7。至于改进了什么，后面会继续分享。原来有同事说都用mysql8.0，不能太保守。想过升级到mysql5.6，最后还是选择了Mysql5.7已经安装。迁移方案首先要保证健壮性，其次要保证安全，最后要保证体验。三者之间有一些权衡。DTS虽然也支持双向同步，但是和mysql主主同步是一样的。具体实现上有很多限制，所以整体的解决方案也不是完全不可感知的。具体解决方案是在迁移过程中锁定源库的更新（必须有操作时间）；同时，迁移完成后，将新库的数据同步到源库（用于回滚）。因为源库和目标库的版本不同，所以还没有做新库到源库的同步。阿里云的DTS服务确实不错。我可以稍后再说。它可以在广泛的场景中使用。即使你不使用阿里云的服务，我也建议你试一试。不过，今天我也发现，DTS同步毕竟不是原生同步。会受到很多限制。在实现的过程中，也收获了很多，比如mysql中readonly和globalread锁的区别；mysql5.7中的sql_mode；在gtid中重置master和resetslave；会导致数据不一致）；账号授权规则的重要性（分级，授权范围越小越好，比如只授权给代理）；主从同步最好也同步mysql库（这样主从数据库很多信息可以保持一致），但是库的配置信息（比如poolsize）不能同步；切换主从并没有原来想象的那么复杂，包括升级版。整个迁移过程必须提前进行模拟，模拟得越逼真，错误越少，模拟得越逼真，就要检验整体架构的合理性。和同事讨论过很多次，目的是验证大家理解是否一致，有没有更多好的建议，在具体操作过程中，两个人共同努力，一方面坚定信心，另一方面手，他们还可以互相提醒。整体实现的时候有一个checklist，目前看来还比较顺利。如果要给阿里云RDS一个建议，那就是把它的读写分离功能分开。你是什??么意思？可以生成读写分离的多个实例，主从实例可以无限组合。即使这些实例也不一定是RDS。RDS迁移第一步完成，后续还有很多细节。做一件事，成败不在于开始，而在于结束。我在这方面有一些体会，比如一个解决方案从大方向设计的很强大，但是缺乏对细节的思考，后续开发的复杂性和通用性会导致四大不同。但这是一个良好的开端，坚定的步伐，喜欢我本周听到的内容。
