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，迁移耗时和迁移过程中的性能分别如下：

数据迁移时间：

迁移性能：

 2) 大型数据库(IOPS = 3000)压测：采用4台机器，做了三个测试，分别启用了10个、15个和25个线程，迁移数据200w，迁移耗时和迁移过程中的性能分别如下：

数据迁移时间：

迁移性能：

注意：数据库IOPS性能消耗较低，因为数据库本身含有缓存缓写逻辑。

因此，不同IOPS性能的数据库最终迁移时长区别不大。

FAQ

• 关于此文档暂时还没有FAQ