注意：以下文档只适用于TOP接口，请谨慎使用！
注意：以下文档只适用于TOP接口，请谨慎使用！
在线上加密覆盖到全量用户后，接下去的一个重要步骤就是要把历史数据全量加密。
我们根据内部压测数据和案例经验总结出的RDS迁移方案和性能数据，以供参考。
2.1 数据迁移，准备：
1) 请确认代码逻辑已经做好明文和密文的兼容。
2) 确认加密开关已经打开。
3) 确认从RDS和TOP api新流入的数据已经是密文的。
在确认容错逻辑已完成后进行迁移。先进行少量客户迁移测试之后，可以进行全量迁移测试。
1) 首先单个客户数据迁移测试：
借用迁移1个客户的机会测试迁移方案。建议迁移量<100万。可以先从较低的并发数开始。例如：并发5- 10个线程。（可以根据上面压测数据自选）
提前记录平时的性能；
记录迁移期间再记录迁移时间、迁移过程中的IOPS/连接/CPU/TPS/QPS等，和平时的性能做比较。
2) 迁移方案
根据前期计算好的迁移速度，计算迁移时间和方案。
首先确定迁移的最小粒度：例如，独立部署的ISV，则可决定一个部署为一个最小粒度。兼顾功能的独立性，以及迁移的总时长（控制在3个小时以内）。
第一天进行迁移时，继续记录数据量、时间……等。
如果迁移过程顺利无问题、且性能负载可以承受，可以在之后逐渐增加线程数。
之后，可在第一天的基础上逐步增加线程数和迁移并发数。注意持续监测数据库性能。直至迁移完成。
3) 代码逻辑注意：
• 请注意：仅当用户Session有效的，或者过期不超过90天，并且用户状态没有过期才能拉取到密钥。
在迁移过程中，请排除已经过期超过90天和无效的用户(即：冻结、清退等)。
否则造成大量失败的密钥请求，且加密失败。
• 从数据库中拉取用户数据并加密的时候，请注意控制分页大小。
目标：根据数据库大小、数据库和应用架构以及选择的数据库性能，推荐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性能的数据库最终迁移时长区别不大。
