1. 場景需求

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

我們根據(jù)內(nèi)部壓測數(shù)據(jù)和案例經(jīng)驗(yàn)總結(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)容錯(cuò)邏輯已完成后進(jìn)行遷移。先進(jìn)行少量客戶遷移測試之后，可以進(jìn)行全量遷移測試。

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

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

提前記錄平時(shí)的性能；

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

 2) 遷移方案

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

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

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

如果遷移過程順利無問題、且性能負(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ù)并加密的時(shí)候，請注意控制分頁大小。

 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臺(tái)機(jī)器，做了三個(gè)測試，分別啟用了10個(gè)、15個(gè)和25個(gè)線程，遷移數(shù)據(jù)200w，遷移耗時(shí)和遷移過程中的性能分別如下：

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

遷移性能：

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

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

遷移性能：

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

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

FAQ

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