於是我回到座位,開始實驗用 PostgreSQL 原生工具讓兩台 db 做對拷。首先需要設定防火牆,讓 slave db 可以直接連到 target RDS 的 5432,使用者帳號也需要先在 RDS 中設定好,接下來連入 slave db EC2,在 console 下這個命令
Share:
於是我回到座位,開始實驗用 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,略過這些奇怪的表。
但一啟動,立馬就跳紅字,似乎是找不到之前的中斷點了,奇怪,記得文件說暫停後可以繼續,怎麼會這樣?
架構重整系列分享在工作上遇到的棘手架構案例。希望讓同樣面對這些問題的人也能從中得到一些靈感來處理!
先簡單列一下這個案例的狀況:
code base 已經發展五、六年,使用 twistd 框架架設出來的單塊系統,所有的應用 backend 都塞在同一份 code base 裡面,而且還在使用 python2!開發上沒有分層設計,底層 db 的 orm instance 直接暴露到表現層上,不同應用會使用到相同的表,甚至前後端沒有分離,互相沾黏非常嚴重。
J
雖然大學唸的是生物,但持著興趣與熱情自學,畢業後轉戰硬體工程師,與宅宅工程師們一起過著沒日沒夜的生活,做著台灣最薄的 intel 筆電,要與 macbook air 比拼。
離開後,憑著一股傻勁與朋友創業,再度轉戰軟體工程師,一手扛起前後端、雙平台 app 開發,過程中雖跌跌撞撞,卻也累計不少經驗。
可惜不是那 1% 的成功人士,於是加入其他成功人士的新創公司,專職開發後端。沒想到卻在採前人坑的過程中,拓寬了眼界,得到了深層的領悟。