Postgres 研究筆記 – Upgrade Major Version 過程中的 Downtime 時間可否盡量減少？

本次研究對象，是 AWS RDS 的某一台 Postgresql 的主版本要升級。

然而，一經研究，發現主版本升級幾乎不可能沒有 downtime，這邊紀錄一下研究過程，看能不能在技術上，找到直接或間接方法去減少 downtime

研究一、原地升級

若採原地升級(在 Aws Console 表單上操作)，以該資料庫的情況，具體會 downtime 15 分鐘左右。

研究二、兼顧 application 讀取，但犧牲 application 寫入

想兼顧前端讓他看起來大致正常，並盡量減少 fail response 數量與時間的話，可以參考 Airbnb 這篇

這篇的目的是把原本 DB 中關於聊天的資料拉出來，放在另一台 DB instance 上做事，使原本 DB 的負擔降低。

他們先開了一台 read replica，作為之後的聊天 DB master(文中稱’message-master’)，之後有關聊天的 Query Traffic 就指向這台 read replica ，並承受這段時間關於聊天的 Write Fail ，同時也因為 Write Fail，所以倒是保證了聊天資料的一致性，之後開始 promote 這台 read replica 成為新的 instance，等 promote 結束後，也就順利完成流程了。

參考這個做法，並經過適當的流程設計，就可以讓升級的這段時間裡，網站大致呈現正常。

如果前端顯示上，對 Failure 有要求，不想被前端看到，則可以在 application 這邊補上一些適當的 try catch ，或是改 Code ，讓會受影響的寫入部分停用，等升級之後再重新開放。

研究三、Multi-AZ

開 Multi-AZ 對升級過程的 downtime 沒有幫助。

可參考：Will a Multi-AZ deployment help reduce downtime during an Amazon RDS MySQL modification?

另外也有在 RDS 上實測過，即使 instance 開啟 Multi-AZ。但在整個 Upgrade 過程裡， Aws RDS 的 Event 完全沒有關於 Multi-AZ、failover 的動作出現。

反倒是如果只是修改 instance type，那 Multi-AZ 有點幫助，可以稍微縮短中斷時間，但整體時間會拉長。