歷史資料遷移方案
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 |
#遷移效能：
# # | 機數 | #執行緒數 | IOPS | #活躍連接數 | CPU | #CPU | 平均每秒事務數(TPS) (|
數(QPS) (峰值) | 測試1 | 4 | 10 | #27 | #20 | ||
| 12% 3000 | 4500 | 測試2 | #4 | 15 | 40 | 45 | |
| 20% #5500 | ##7500 | #測試3 | #測試3 | ##4 |
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 | #CPU | 平均每秒事務數(TPS) (|
數(QPS) (峰值) | 測試1 | 4 | 10 | #30 | #20 | ||
| 10% 3300 | 4500 | 測試2 | #4 | 15 | 40 | 45 | |
| 18% 6000 | ##7500 | #測試3 | #測試3 | ##4 | 25 | 112 |
注意：資料庫IOPS效能消耗較低，因為資料庫本身含有快取緩寫邏輯。
因此，不同IOPS效能的資料庫最終遷移時長差異不大。
FAQ
- 關於此文件暫時還沒有FAQ
