於是我回到座位，開始實驗用 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，略過這些奇怪的表。

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

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