到了預計 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 核的雲端機器，只能用一個爽字來形容。
「準備開始跑 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，一直有這個錯誤再跳！」
這什麼鬼？！看起來 id 沒有值無法寫入。可是怎麼可能？ id 應該是預設遞增值啊！怎麼可能還要自己配置？
我不信邪，立刻自己也用客戶端建一筆資料。果然 500！真他媽的什麼鬼問題！
我立刻孤狗，直覺告訴我可能預設值的設定不見了，但還是想不通 id 這麼基本的設定怎麼會跑掉。
後來在 aws dms 的官方文件中找到了，dms 不會幫我們搬預設值！
花惹發！
「幹！踩坑了！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 #2
拯救脆弱系統 – migrate to RDS by DMS #4
AWS Data Migration Service 攻略
封面圖片備註：通過崎嶇，貧脊，陡峭的地形考驗，才能抵達名為成功的目的地。
