於是我回到座位，開始實驗用 PostgreSQL 原生工具讓兩台 db 做對拷。首先需要設定防火牆，讓 slave db 可以直接連到 target RDS 的 5432，使用者帳號也需要先在 RDS 中設定好，接下來連入 slave db EC2，在 console 下這個命令

到了預計 cutover 當天晚上，我和 C 已經在線上等待預計維護的時間來臨。

「59分了，直接開始吧！」我在 slack 上和 C 說。
「go！」

於是我執行已經預寫好的Python script，他會使用 boto3 直接對我們的兩台 EC2，web server 和 database server 換上我特別設定好的 security group，擋住外部 80 和 443 連入 web server，以及內部 5432 連入 database server，只讓 dms 和我下指令用的 EC2 能連入。

把 RI 的 task 暫停後，果然客戶端就可以正常使用了，看來的確是 DMS 的關係。但是看 db 的 cpu，其實也只比平常多個 10% 左右，怎麼會有這麼大的影響呢？（後來才理解，瓶頸應該是出現在與 ebs 溝通的 throughput，但當時不清楚是這個原因）百思不得其解的我，只好把 task 的一些效能參數調小試試。

調小後果然就沒有收到抱怨了，但 task 狀態卻剛好轉 error，原來有幾張表沒有 primary key，所以無法搬移。

「竟然會有表沒有 pk？這不是基本的嗎？」我表示大傻眼，只好修改 task，略過這些奇怪的表。

但一啟動，立馬就跳紅字，似乎是找不到之前的中斷點了，奇怪，記得文件說暫停後可以繼續，怎麼會這樣？

架構重整系列分享在工作上遇到的棘手架構案例。希望讓同樣面對這些問題的人也能從中得到一些靈感來處理！

先簡單列一下這個案例的狀況：

1. 原始碼部分：

code base 已經發展五、六年，使用 twistd 框架架設出來的單塊系統，所有的應用 backend 都塞在同一份 code base 裡面，而且還在使用 python2！開發上沒有分層設計，底層 db 的 orm instance 直接暴露到表現層上，不同應用會使用到相同的表，甚至前後端沒有分離，互相沾黏非常嚴重。

這邊整理我在使用 AWS Data Migration Service （簡稱DMS）一路採坑後整理出來的筆記，希望對也是在水深火熱的人有幫助！

以下結構主要拆成兩部分，一部分是對原先的 database 做設定（這邊使用的是 PostgreSql），另一部分是對 DMS。先後順序沒有一定，只要最終 DMS 能連線進去 database 並啟動 task 即可！