1. 場景需求

在線上加密覆蓋到全量用戶后，接下去的一個重要步驟就是要把歷史數(shù)據(jù)全量加密。

我們根據(jù)內(nèi)部壓測數(shù)據(jù)和案例經(jīng)驗總結(jié)出的RDS遷移方案和性能數(shù)據(jù)，以供參考。

2 方案介紹

2.1 數(shù)據(jù)遷移，準(zhǔn)備：

1) 請確認(rèn)代碼邏輯已經(jīng)做好明文和密文的兼容。

2) 確認(rèn)加密開關(guān)已經(jīng)打開。

3) 確認(rèn)從RDS和TOP api新流入的數(shù)據(jù)已經(jīng)是密文的。

2.2數(shù)據(jù)遷移建議方案

 在確認(rèn)容錯邏輯已完成后進(jìn)行遷移。先進(jìn)行少量客戶遷移測試之后，可以進(jìn)行全量遷移測試。

 1) 首先單個客戶數(shù)據(jù)遷移測試：

借用遷移1個客戶的機會測試遷移方案。建議遷移量<100萬?？梢韵葟妮^低的并發(fā)數(shù)開始。例如：并發(fā)5- 10個線程。（可以根據(jù)上面壓測數(shù)據(jù)自選）

提前記錄平時的性能；

記錄遷移期間再記錄遷移時間、遷移過程中的IOPS/連接/CPU/TPS/QPS等，和平時的性能做比較。

 2) 遷移方案

  根據(jù)前期計算好的遷移速度，計算遷移時間和方案。

 首先確定遷移的最小粒度：例如，獨立部署的ISV，則可決定一個部署為一個最小粒度。兼顧功能的獨立性，以及遷移的總時長（控制在3個小時以內(nèi)）。

 第一天進(jìn)行遷移時，繼續(xù)記錄數(shù)據(jù)量、時間……等。

如果遷移過程順利無問題、且性能負(fù)載可以承受，可以在之后逐漸增加線程數(shù)。

之后，可在第一天的基礎(chǔ)上逐步增加線程數(shù)和遷移并發(fā)數(shù)。注意持續(xù)監(jiān)測數(shù)據(jù)庫性能。直至遷移完成。

 3) 代碼邏輯注意：

? 請注意：僅當(dāng)用戶Session有效的，或者過期不超過90天，并且用戶狀態(tài)沒有過期才能拉取到密鑰。

在遷移過程中，請排除已經(jīng)過期超過90天和無效的用戶(即：凍結(jié)、清退等)。

否則造成大量失敗的密鑰請求，且加密失敗。

? 從數(shù)據(jù)庫中拉取用戶數(shù)據(jù)并加密的時候，請注意控制分頁大小。

 2.3 數(shù)據(jù)遷移，關(guān)鍵數(shù)據(jù)參考：

目標(biāo)：根據(jù)數(shù)據(jù)庫大小、數(shù)據(jù)庫和應(yīng)用架構(gòu)以及選擇的數(shù)據(jù)庫性能，推薦ISV適當(dāng)?shù)臄?shù)據(jù)遷移方案。

 資料和數(shù)據(jù)：

RDS推送數(shù)據(jù)庫性能：http://cloud.tmall.com/rdsSelection.htm

上圖為數(shù)據(jù)庫配置列表。我們內(nèi)部壓測選擇了紅框中的4種RDS配置做了測試。測試結(jié)果見下一節(jié)。

壓測結(jié)果：

1) 中型數(shù)據(jù)庫(IOPS = 1200)壓測：采用4臺機器，做了三個測試，分別啟用了10個、15個和25個線程，遷移數(shù)據(jù)200w，遷移耗時和遷移過程中的性能分別如下：

數(shù)據(jù)遷移時間：

遷移性能：

 2) 大型數(shù)據(jù)庫(IOPS = 3000)壓測：采用4臺機器，做了三個測試，分別啟用了10個、15個和25個線程，遷移數(shù)據(jù)200w，遷移耗時和遷移過程中的性能分別如下：

數(shù)據(jù)遷移時間：

遷移性能：

注意：數(shù)據(jù)庫IOPS性能消耗較低，因為數(shù)據(jù)庫本身含有緩存緩寫邏輯。

因此，不同IOPS性能的數(shù)據(jù)庫最終遷移時長區(qū)別不大。

FAQ

• 關(guān)于此文檔暫時還沒有FAQ