自动化迁移工单图
该功能包含扩容节点、主从切换、迁移域名、回收实例等步骤。如果出现选择的实例不易迁走，可以使用【更改节点结单】或者【回收实例结单】功能完成整个工单的闭环。
目前该项功能已经投入使用，直至目前已经提单259个，提高迁移效率达95%以上。
3.4 新备份恢复系统的不足
1. MongoDB shard 备份缺陷
由于MongoDB shard 引入，MongoDB shard 备份还未有更好的备份方案。目前MongoDB shard 依旧是使用物理备份，但是对数据恢复上还存在不足。在恢复至某一个时间点上，还需要使用oplog单独对每个分片进行恢复，恢复起来步骤复杂。
2. 数据恢复效率不高
数据恢复是在数据被误删的时候发起的操作，虽然使用频率较低，但是该功能却是非常重要的，目前恢复数据是基于全库恢复 binlog重做，恢复效率较低，依旧有很多的恢复方案亟待加入，提高恢复数据的效率，减少因误删数据产生的影响。
四、总结
4.1 安全
旧系统主要是文件系统安全，由于使用的是GlusterFS文件系统，物理机备份主要是挂载到目标机器上，导致登录物理机后，可以不受限制的操作备份文件，非常危险，虽然异地灾备文件系统只挂载至备份控制机，权限控制的比较严格，但是由于拷贝速度的限制，异地的副本已名存实亡。
使用新系统后，备份文件存储于多个机房之中，某个机房全部宕机，也不影响备份文件的读取，因此对备份文件保护得到了加强。同时由于对象存储系统未使用挂载形式，因此，DBA和系统工程师无法下载备份文件，也无法操作备份文件系统，让备份文件更加安全。
4.2 效率
受限于旧文件系统效率写入以及逻辑备份速度，MySQL 备份2天才能完成一轮备份，MongoDB 由于实例太大，受限于mongodbdump 本身的特性，备份时间很长，而且很容易失败。虽然优化后，改成ssd 盘备份，但受限于盘的大小，MongoDB 的备份效率依旧不好。
通过更换文件系统，以及备份策略，极大的提高了备份效率，备份从之前的2天完成备份，提高至10个小时完成备份。
自动化迁移在减少DBA选择实例的同时，也能形成完整的闭环，DBA在操作的时候只需要根据工单的流程即可，极大的提高了工作效率。
4.3功能模块扩展
自从使用Java 语言后，并且有专门的 Java 开发人员的介入，新功能需求得到了实现，经过多轮的优化，目前新备份恢复系统运行非常稳定。基于备份文件，我们扩展了定点恢复模块、自动化迁移方案、以及机器故障自动发起迁移等功能，极大的提高DBA的工作效率，让我们有更多的时间去解决企业的痛点。
作者:vivo 互联网数据库团队 - Han Chaobing
来源:微信公众号:vivo互联网技术
出处:https://mp.weixin.qq.com/s/HsYcQ3KnlVDBfYfGvp9kTA
,
