迁移方案
迁移工作的开展需根据具体的工作要求制定相应的工作计划及迁移方案,迁移目的可能是基于测试验证的兼容性测试,也可能是替换 MySQL上线运行,迁移目的决定了迁移方案的具体规划。
迁移方案内容的选择如表1所示。
工作类型 | 兼容性测试 | 正式性迁移 |
---|---|---|
硬件环境 | 基础硬件 | 业务硬件 |
软件环境 | 测试软件 | 业务软件 |
数据来源 | 部分数据或脱敏数据 | 正式数据 |
应用功能 | 部分功能 | 全部功能 |
应用性能 | 无或按需 | 核心业务性能 |
压力测试 | 无或按需 | 业务并发访问峰值 |
稳定性测试 | 无 | 7x24小时 |
容灾性测试 | 无 | 容灾验证 |
数据同步 | 无 | 按需进行 |
业务割接 | 无 | 按需进行 |
兼容性测试:用户或者集成开发商对于迁移可能性和技术工作量的评估和确认工作,即尝试性迁移,迁移后可能并不会立刻进行产品级的应用功能、性能、稳定性测试。此类测试,以验证试验为主,对配置无特别要求,满足基本运行条件即可,在这种情况下,基础环境可以灵活选取,用虚拟机或物理机服务器均可。
正式性迁移:以正式上线为目的,需要对应用进行产品级全方位的功能点测试、性能测试、压力测试以及稳定性测试等集成测试,需考虑应用上线的各种可能性及保障措施。正式性迁移优先采用物理服务器搭建数据库,并且对于物理服务器的相关硬件配置有硬性要求,根据系统数据量规模、性能要求、并发规模、可用性要求等基本情况向测试方提出建议。硬件支撑的合理性是保证迁移和测试效果的必要条件。