把 RI 的 task 暫停後，果然客戶端就可以正常使用了，看來的確是 DMS 的關係。但是看 db 的 cpu，其實也只比平常多個 10% 左右，怎麼會有這麼大的影響呢？（後來才理解，瓶頸應該是出現在與 ebs 溝通的 throughput，但當時不清楚是這個原因）百思不得其解的我，只好把 task 的一些效能參數調小試試。
調小後果然就沒有收到抱怨了，但 task 狀態卻剛好轉 error，原來有幾張表沒有 primary key，所以無法搬移。
「竟然會有表沒有 pk？這不是基本的嗎？」我表示大傻眼，只好修改 task，略過這些奇怪的表。
但一啟動，立馬就跳紅字，似乎是找不到之前的中斷點了，奇怪，記得文件說暫停後可以繼續，怎麼會這樣？
沒辦法，只好讓 task 先 drop 掉所有已經搬移的表，全部重新開啟。
沒多久後又報誤，看訊息是說 LOB 被截斷之類的問題。但我不清楚這是甚麼意思，上網 google 發現 LOB 意指較大的欄位，比如說存了很大的 json。檢查文件發現 DMS 需要對 LOB 做設定，他有幾個選項，請勿包含、完整、有限。
但我不清楚目前 LOB 到底最大是多少，資料庫本身就已經很混亂。
「不如就設定成完整吧！讓他全抓最安全！」我暫停task，修改設定，然後再讓他繼續。
但是搬移的速度非常慢，大部分的小表已經過去，但是其中有幾張超大表，有的 row 數甚至上千萬，還在龜速般前進。
「看來要複製到天荒地老了，不過反正有的是時間，就讓他慢慢跑吧！」於是我就打完收工，開心回家去了。
隔天再來看，task 竟然停頓了！也沒有甚麼特殊的錯誤訊息，就是卡在那邊。看 RI 的讀取寫入幾乎歸零，記憶體只剩下幾 MB。
「難道記憶體爆了？」沒想到 RI 這麼吃記憶體，只好狠心把 instance 開大，再重頭來過。
可惜，速度還是很慢，於是時間就在我不斷重試參數的過程中流逝…
「再這樣下去不行，感覺根本是矇著眼睛亂試！」網路上討論 DMS 的資訊也不多，讓我非常的焦急。
後來和 C 討論，決定求助於 aws 的技術協助，但這個服務可不便宜！他會收取訂閱當月的費用 10%！也就是說，雖然問一樣次數的問題，如果機器開越多的人，費用就越高！
「這招實在陰險厲害，使用 aws 的服務有問題要客服，不但要付費，還有層級之分！」我驚嘆。也只能說 aws 服務使用後幾乎被綁住，不太可能因為這件事就跳槽。
不過 aws 技術客服可以說是非常專業且不錯，一開始只是線上留言詢問，但因為這次的問題頗複雜，後來他還特定打電話來與我討論。
經過多次的討論與持續的踩坑失敗，最後得到了他的運作原理與設定技巧，技巧可參考這篇 AWS Data Migration Service 攻略，這邊則簡述它的原理和重要觀念：
- DMS 一開始會是 Full load mode，會用 sql select 資料，並寫入 target database
- Full load mode 的時候不能有 fk 的存在，因為 DMS 不會依照 fk 約束的應有順序搬資料（這能夠理解，如果 fk 存在，除非是 schema designer，不然很難做一個通用的程式來搬資料）
- Full load 後，就會進入 CDC 階段，此時只要 source db 有變動，就會透過 RI 串流過去 target database
- 此時依需求，選擇繼續保持 CDC 或是做 cutover，以這次為例，我們要做 cutover，所以正式轉移前，要透過 cloud watch 確認 CDCLatencyTarget 已經歸零即可進行
- CDC 有兩個重要參數：CDCLatencySource，指的是 source db data 建立的時間戳，到 RI 的時間戳差異，如果數值偏大，表示瓶頸發生在 source db 和 RI 之間，通常會是發生在地端資料庫要串上雲端，兩者網路的頻寬限制。CDCLatencyTarget，指的是 RI 的時間戳，和寫入 target db data 的時間戳差異，如果此參數過大，表示瓶頸發生在 RI 和 target db 之間，通常會是 target db instance 開太小導致。
- LOB 的部分，沒有特殊用途的話不要使用「完整 LOB 模式」，因為 RI 每次讀取的時候，都會在 RI 的記憶體中先宣告對應的大小，在不確定 LOB 有多大的情況下，RI 就會屢次擴張所宣告的大小，一方面耗費時間，一方面可能會因此耗盡記憶體。因此他建議使用「有限 LOB 模式」，這樣 RI 就會在記憶體上限內一次宣告適當且足夠的大小，如此大大增加速度和成功率。
- 如果 task 暫停後有調整過一些比較關鍵的設定，如表的選擇，LOB 模式等等，會需要讓 task 重新來過
總算成功後，我計畫 cutover 當天要做以下的事情：
- 用防火牆擋住外部連線
- 手動複製沒有 pk 的表
- 確認每張 table 的 row 數一致
- 重建 fk、index
- Cutover
- 確認 api 都正常
- 解開防火牆
評估了一下，如果晚上10點展開，看來也是要搞到清晨，主要是我們的資料實在太多，事先測試做 fk 和 index 分別就要兩個多小時，我想當天是不用睡覺了！
「拼一下吧！」我無奈的和 C 講。
「到時候就補假休息吧！只希望一切順利！」C 雙手合十。
「是啊！」我回覆，看著虛空。
延伸閱讀：
拯救脆弱系統 – Migrate to RDS by DMS #1
拯救脆弱系統 – migrate to RDS by DMS #3
AWS Data Migration Service 攻略
封面圖片備註：當時的我就與圖中的人一樣，煩惱的看著電腦，不知道搬移計畫能不能成功
