歷史數據遷移方案
1. 場景需求
在線上加密覆蓋到全量用戶后，接下去的一個重要步驟就是要把歷史數據全量加密。
我們根據內部壓測數據和案例經驗總結出的RDS遷移方案和性能數據，以供參考。
2 方案介紹
2.1 數據遷移，準備：
1) 請確認代碼邏輯已經做好明文和密文的兼容。
2) 確認加密開關已經打開。
3) 確認從RDS和TOP api新流入的數據已經是密文的。
2.2數據遷移建議方案
在確認容錯邏輯已完成后進行遷移。先進行少量客戶遷移測試之后，可以進行全量遷移測試。
1) 首先單個客戶數據遷移測試：
借用遷移1個客戶的機會測試遷移方案。建議遷移量<100萬。可以先從較低的并發(fā)數開始。例如：并發(fā)5- 10個線程。（可以根據上面壓測數據自選）
提前記錄平時的性能；
記錄遷移期間再記錄遷移時間、遷移過程中的IOPS/連接/CPU/TPS/QPS等，和平時的性能做比較。
2) 遷移方案
根據前期計算好的遷移速度，計算遷移時間和方案。
首先確定遷移的最小粒度：例如，獨立部署的ISV，則可決定一個部署為一個最小粒度。兼顧功能的獨立性，以及遷移的總時長（控制在3個小時以內）。
第一天進行遷移時，繼續(xù)記錄數據量、時間……等。
如果遷移過程順利無問題、且性能負載可以承受，可以在之后逐漸增加線程數。
之后，可在第一天的基礎上逐步增加線程數和遷移并發(fā)數。注意持續(xù)監(jiān)測數據庫性能。直至遷移完成。
3) 代碼邏輯注意：
? 請注意：僅當用戶Session有效的，或者過期不超過90天，并且用戶狀態(tài)沒有過期才能拉取到密鑰。
在遷移過程中，請排除已經過期超過90天和無效的用戶(即：凍結、清退等)。
否則造成大量失敗的密鑰請求，且加密失敗。
? 從數據庫中拉取用戶數據并加密的時候，請注意控制分頁大小。
2.3 數據遷移，關鍵數據參考：
目標：根據數據庫大小、數據庫和應用架構以及選擇的數據庫性能，推薦ISV適當的數據遷移方案。
資料和數據：
RDS推送數據庫性能：http://cloud.tmall.com/rdsSelection.htm
上圖為數據庫配置列表。我們內部壓測選擇了紅框中的4種RDS配置做了測試。測試結果見下一節(jié)。
壓測結果：
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性能的數據庫最終遷移時長區(qū)別不大。
FAQ
- 關于此文檔暫時還沒有FAQ