历史数据迁移方案
1. 场景需求
在线上加密覆盖到全量用户后,接下去的一个重要步骤就是要把历史数据全量加密。
我们根据内部压测数据和案例经验总结出的RDS迁移方案和性能数据,以供参考。
2 方案介绍
2.1 数据迁移,准备:
1) 请确认代码逻辑已经做好明文和密文的兼容。
2) 确认加密开关已经打开。
3) 确认从RDS和TOP api新流入的数据已经是密文的。
2.2数据迁移建议方案
在确认容错逻辑已完成后进行迁移。先进行少量客户迁移测试之后,可以进行全量迁移测试。
1) 首先单个客户数据迁移测试:
借用迁移1个客户的机会测试迁移方案。建议迁移量<100万。可以先从较低的并发数开始。例如:并发5- 10个线程。(可以根据上面压测数据自选)
提前记录平时的性能;
记录迁移期间再记录迁移时间、迁移过程中的IOPS/连接/CPU/TPS/QPS等,和平时的性能做比较。
2) 迁移方案
根据前期计算好的迁移速度,计算迁移时间和方案。
首先确定迁移的最小粒度:例如,独立部署的ISV,则可决定一个部署为一个最小粒度。兼顾功能的独立性,以及迁移的总时长(控制在3个小时以内)。
第一天进行迁移时,继续记录数据量、时间……等。
如果迁移过程顺利无问题、且性能负载可以承受,可以在之后逐渐增加线程数。
之后,可在第一天的基础上逐步增加线程数和迁移并发数。注意持续监测数据库性能。直至迁移完成。
3) 代码逻辑注意:
• 请注意:仅当用户Session有效的,或者过期不超过90天,并且用户状态没有过期才能拉取到密钥。
在迁移过程中,请排除已经过期超过90天和无效的用户(即:冻结、清退等)。
否则造成大量失败的密钥请求,且加密失败。
• 从数据库中拉取用户数据并加密的时候,请注意控制分页大小。
2.3 数据迁移,关键数据参考:
目标:根据数据库大小、数据库和应用架构以及选择的数据库性能,推荐ISV适当的数据迁移方案。
资料和数据:
RDS推送数据库性能:http://cloud.tmall.com/rdsSelection.htm
上图为数据库配置列表。我们内部压测选择了红框中的4种RDS配置做了测试。测试结果见下一节。
压测结果:
1) 中型数据库(IOPS = 1200)压测:采用4台机器,做了三个测试,分别启用了10个、15个和25个线程,迁移数据200w,迁移耗时和迁移过程中的性能分别如下:
数据迁移时间:
| 机器数 | 线程数 | 数据量 | 时间 |
测试1 | 4 | 10 | 200w | 31min |
测试2 | 4 | 15 | 200w | 19 min |
测试3 | 4 | 25 | 200w | 13 min |
迁移性能:
| 机器数 | 线程数 | IOPS | 活跃连接数 | CPU峰值 | 平均每秒事务数(TPS) (峰值) | 每秒SQL数 (QPS) (峰值) |
测试1 | 4 | 10 | 27 | 20 | 12% | 3000 | 4500 |
测试2 | 4 | 15 | 40 | 45 | 20% | 5500 | 7500 |
测试3 | 4 | 25 | 40 | 75 | 32% | 7500 | 10000 |
2) 大型数据库(IOPS = 3000)压测:采用4台机器,做了三个测试,分别启用了10个、15个和25个线程,迁移数据200w,迁移耗时和迁移过程中的性能分别如下:
数据迁移时间:
| 机器数 | 线程数 | 数据量 | 时间 |
测试1 | 4 | 10 | 200w | 31 min |
测试2 | 4 | 15 | 200w | 19 min |
测试3 | 4 | 25 | 200w | 13 min |
迁移性能:
| 机器数 | 线程数 | IOPS | 活跃连接数 | CPU峰值 | 平均每秒事务数(TPS) (峰值) | 每秒SQL数 (QPS) (峰值) |
测试1 | 4 | 10 | 30 | 20 | 10% | 3300 | 4500 |
测试2 | 4 | 15 | 40 | 45 | 18% | 6000 | 7500 |
测试3 | 4 | 25 | 112 | 60 | 27% | 8000 | 11000 |
注意:数据库IOPS性能消耗较低,因为数据库本身含有缓存缓写逻辑。
因此,不同IOPS性能的数据库最终迁移时长区别不大。
FAQ
- 关于此文档暂时还没有FAQ