迁移一般输出有三个文档:
- 数据库[上云/迁移/同步]评估方案
- 数据库[上云/迁移/同步]可行性结果
- 数据库[上云/迁移/同步]正式迁移报告
若业务侧认为无需评估直接迁移,则可以省略评估阶段。
案例
markdown 模板
数据库[上云/迁移/同步]评估方案
--- |
数据库[上云/迁移/同步]可行性结果
--- |
数据库[上云/迁移/同步]正式迁移报告
--- |
分布式数据库上云迁移项目坑点小结
数据库上云选型阶段
坑点
- 在数据库选型时,没有明确的目标和指导,只考虑到成本问题,将云上产品全部尝试一遍,最终消耗了大量的人力和测试资源成本。
- 在数据库选项时,没有考虑数据库版本的兼容性问题,例如线下为5.6 云上选择了5.7 导致执行计划不一致,需要优化SQL和代码来满足业务需求。而优化操作并不在计划内。
建议
- 调研清楚当前数据库架构和数据库版本明细后由专业人员给出建议;
- 客户应权衡成本和性能,确认迁移的实际目标,以确认最终数据库架构,为后续的落地提供明确目标。
数据库上云预演迁移阶段
坑点
- 在预演迁移阶段,由于客户并非将整个逻辑库迁移至云上,而是挑选库中部分的表进行同步,导致同步链路的搭建耗时耗力;
- 在预演迁移阶段,伴随着线下业务的变更,会修改表的结构,而表结构的变更会导致同步链路的实效,需要重新配置同步链路;
- 在预演迁移阶段,伴随着业务改造,部分表名、列名存在变更,此时同步链路也需要重新配置,耗费时间;
- 由于数据库跨版本迁移,因此数据库侧的优化和应用性能对比占了很大的工作量;
- 在预演迁移阶段,发现大量没有主键的表,需要添加主键后才能正常同步。
建议
- 应在数据库预演迁移前完成业务侧的代码改造,不要和数据库迁移混在一起,加大迁移难度,且造成不必要的时间和人力成本;
- 调研实例与实例、库、表的逻辑映射关系,为后续的同步链路做好准备;
- 调研表的主键情况,将没有主键的表提前处理;调研DRDS的序列SHOW SEQUENCES的明细;
- 涉及的人工操作较多,需要两人互备,互相检查确认操作,防止误操作。
- 涉及数据库优化的部分,应成立专项优化小组,确定优化目标,制定优化计划,验证优化结果。
- 数据库上云预演迁移阶段结束时应提供《数据库上云可行性分析报告》《数据库优化报告》等。
数据库上云正式迁移阶段
建议
- 制定完整的迁移和回滚计划
- 数据库上云正式迁移阶段结束时应提供《数据库上云正式迁移报告》