架構重整 - migrate to RDS by DMS #3

到了預計 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 能連入。

python set_cutover_sg.py

不用5秒鐘,console 顯示已經切換完成。當初會想用 script 做切換,就是怕轉移當下太累,手殘按錯東西,同時簡化步驟,加快速度,看來這個判斷是正確的。

然後暫停所有的 DMS task,從 cloudwatch 監看,等待 CDC target latency 降為零。

「好像外科醫生做心臟手術等待麻醉醫師停止心跳一樣厲害。」我自己苦中作樂。

避免後續步驟出包,我先對 RDS 做了備份,RDS 做備份非常簡單,簡單在 web console 點一點即可完成。

備份完後,跑 dms_create_lost_table.py,建立沒有 pk 的表,並搬移 dms 沒有搬的資料。因為資料量非常少,這部分很快就結束。

再來跑 check count script。

python dms_check_count.py

這也是預先寫好的 Python script,使用  SqlAlchemy 跑 raw SQL 來 count ,比對來源端和目標端的資料總數是否一致。這部分之前測試會跑大概 30分 鐘左右。於是下指令後我開始檢查後續的步驟有沒有問題,接著只能等待。

很快,30分鐘過去。下一步就是建立 fk,因為 db 會為每筆有 fk 設定的資料做重建。

python dms_migrate_fk.py

這部分在 m4.4xlarge 的機器上跑起來倒是頗快,只有八分鐘就搞定!螢幕上秀著之前為了成功準備的訊息:

create fk finish

檢查log,也沒有其他的錯誤訊息,看來可以進入下一階段!

為了加快後續跑測試與 script,我先把目標 RDS 開大,直接拉上 m4.16xlarge,主要目的是加大 ebs 頻寬,節省後續處理的時間。人生第一次開到 64 核的雲端機器,只能用一個爽字來形容。

架構重整系列 - migrate to RDS by DMS #3
m4.16xlarge 爽度爆表(但老闆錢包爆掉)

「準備開始跑 create index!」我在 slack 跟 C 說最新狀態。

接下來 db 會掃每筆資料的硬碟所在位置,然後用 btree 來建立 index,耗時非常久,之前試跑大約要 150 分鐘左右。於是我計畫按下去後直接滾去睡覺,設鬧鐘叫起床再做下一步。

「C,可以來睡一下,兩小半後見!」我在 slack 和 C 說。
「ok,等會見。」然後 slack 的小燈就熄滅了。

指令下完後,我關燈躺上床,腦中還在思考這些事情,通常只要在睡覺前還在寫扣或是弄電腦,腦袋就會持續運轉一段時間無法休息。但由於蠻晚的,我後來也昏昏沉沉的睡去。

「登登登登!」手機倒數計時器鈴聲大作。我立馬跳起來,開燈,打開筆電檢查結果。

立刻檢查執行結果:

all complete

太好了,於是切換 aws web console,先做一次備份,再把 RDS 縮小成 m4.2xlarge。

「要準備連接新 db 做測試囉!」
「ok,go!」C 回覆。

我分別連入兩台 EC2,手動修改了 db 位置,深吸了一口氣,然後依序重啟 twistd。

幾秒鐘過去。

Restart success.

看起來已經重啟完成。

「開始測試吧!」我和 C 說。
「好!」

她負責幫測試 app 相關功能,我則測試網頁應用的部分。
首先進入官網,嗯,滿正常的,各個頁面也都能看到。不過這只有前端的部分,真正的重頭戲在後頭。
登入後切換到客戶端頁面,資料也正常顯示,而且速度還比平常快很多!
讀取沒問題,正要開始嘗試建立資料測試寫入,壞消息就來了。

「J,你看 log channel,一直有這個錯誤再跳!」

架構重整 - migrate to RDS by DMS #3
爽跳的錯誤們

這什麼鬼?!看起來 id 沒有值無法寫入。可是怎麼可能? id 應該是預設遞增值啊!怎麼可能還要自己配置?
我不信邪,立刻自己也用客戶端建一筆資料。果然 500!真他媽的什麼鬼問題!

我立刻孤狗,直覺告訴我可能預設值的設定不見了,但還是想不通 id 這麼基本的設定怎麼會跑掉。
後來在 aws dms 的官方文件中找到了,dms 不會幫我們搬預設值!

架構重整系列 - migrate to RDS by DMS #3
DMS 官方文件其實都有說哦!是你沒仔細看!

花惹發!

架構重整系列 - migrate to RDS by DMS #3

「幹!踩坑了!dms 不會幫我們搬預設值!所以 id 才會是空!」我迅速的在 slack 打了這些話。

「什麼意思?為何會這樣?」C秒回。

經過一番解釋,C 才了解發生了什麼事情。

「所以我們都白搞了,現在也不可能再一個個手動搬預設值,我也不清楚有多少的設定」我心煩意亂的打字。

看來只能宣告失敗,全部復原後再商討策略。

和 C 說了之後,我即刻開始復原。但當時沒有考慮到做自動化復原,因此現在只能手動點按,在一夜沒睡好的情況下,非常吃力。

「下次肯定要把退路也先準備好!」我自言自語。

過了心中感受相當漫長的時間,總算回復原始組態,C 那邊也幫忙測試確認正常後,我就解除防火牆,立馬倒頭就睡。

星期一,我和 C 找了間空會議室討論接下來的策略。

「既然 dms 官方文件都說建議使用 PostgreSql 原生工具,不如我們試試看!」我說。

當初我們不考慮原生工具主要是會有很長的停機時間,如果備份需要 7 小時,還原到 RDS 肯定也需要差不多的時間,共 14 小時,這樣勢必無法在晚上一次搞定,會嚴重影響到一般使用者。

但我後來想到,假如能夠像 DMS 那樣,直接從 source DB dump 到 target RDS,這樣就只有 7 小時!可行性大幅提升!

google 了一下,還真的可以這樣搞。於是我建議 C 可以來試試看。

「我先開一台 RDS 用 slave db 來實驗。」反正 slave db 現在只有自己人用,卡頓沒關係。

「就試試看吧!」C 說。

相關文章

拯救脆弱系統 – Migrate to RDS by DMS #1
拯救脆弱系統 – migrate to RDS by DMS #2
拯救脆弱系統 – migrate to RDS by DMS #4
拯救脆弱系統 – 使用 ELB 與 Docker
拯救脆弱系統 – Route 53 設置
AWS Data Migration Service 攻略

封面圖片備註

通過崎嶇,貧脊,陡峭的地形考驗,才能抵達名為成功的目的地。
攝影師:Nick Bondarev,連結:Pexels

J
Written by J
雖然大學唸的是生物,但持著興趣與熱情自學,畢業後轉戰硬體工程師,與宅宅工程師們一起過著沒日沒夜的生活,做著台灣最薄的 intel 筆電,要與 macbook air 比拼。離開後,憑著一股傻勁與朋友創業,再度轉戰軟體工程師,一手扛起前後端、雙平台 app 開發,過程中雖跌跌撞撞,卻也累計不少經驗。可惜不是那 1% 的成功人士,於是加入其他成功人士的新創公司,專職開發後端。沒想到卻在採前人坑的過程中,拓寬了眼界,得到了深層的領悟。