前言
對於一個系統來說，進行定期的升級維護是一件比較常見的事情。但是對於複雜分佈式系統的升級，系統管理員系統考慮更多的因素來做升級這個事情。同時對於分佈式系統開發者來說，他們也要考慮系統升級的前後兼容性，避免升級後部分老的功能無法使用或是升級回退後之前寫出的數據無法使用等等類似的情況。本文筆者來簡單聊聊關於分佈式系統的升級，你需要了解和注意的那些事。
分佈式系統升級的狀態轉化
在介紹本文主要內容前，我們首先需要對分佈式系統的升級有一個總的瞭解，瞭解這裏面總的幾個過程階段。
在這裏，我們一般會有3個階段：
- Older Version，升級前的初始階段。
- Pre-Finalized，升級中且並未結束的階段。
- New Version(Finalized)，升級結束完成階段。
在這3個階段的狀態轉變過程中，需要外界來輸入些action操作，來促使狀態的轉變，由用戶來決定是否可以進入到下一個階段了。
- 從Old Version到Pre-Finalized的action爲Upgrade升級操作
- 從Pre-Finalized到New Version的action爲Finalize確認操作
- 從Pre-Finalized到Old Version的action爲Downgrade降級操作
上圖還能表明的一點信息是在Finalized後是不能再回退到Old Version的操作了。
上述3個階段的流程圖展示如下所示：
下面我們再對裏面的Upgrade和Downgrade過程具體需要注意的幾點進行分析。
關於Upgrade需要注意的點
當我們替換掉系統的包從現有版本(老的版本)到一個新的版本，然後執行啓動Upgrade操作。這個操作之後，其實系統就進入了一個Upgrade In-Progress的階段。
在這個中間狀態過程中，會存在以下會發生的幾種情形：
- 元數據的自動備份，以方便後續可能需要的降級操作。
- 數據格式layout的轉變，常見的我們會有數據存儲文件格式的layout的定義，升級後如果格式發生轉變，我們會對應修改layout的版本。在新老layout格式的替換中，有時我們需要進行程序自動的格式轉換。
- 新版本的部分不兼容的新功能特性不應該被允許執行，因爲此時升級還未完全結束，還意味着有降級的可能性。貿然允許新功能特性操作，會導致降級後的數據無法使用的情況。這裏的“兼容性判斷”來自於開發者給新功能特性定義的最小兼容版本號的值的設定。
- 升級過程中被執行刪除的數據，應該進行trash的暫時轉移而不是直接的物理刪除，這是爲了保護數據的安全性。
- 如果涉及比較複雜的系統，系統內還分多個字服務，還需要進行服務的依賴升級，逐個進行Upgrade。
關於Downgrade需要注意的點
上面說了關於Upgrade過程需要注意的點，那麼對於Downgrade來說，我們要保證哪幾點要求呢？
首先第一點，確保Downgrade後前後數據的完全一致性，這裏的前指的是Downgrade操作執行前即Upgrade In-Progress的階段。在這個In-Progress的階段，還是有用戶的請求會被系統處理到的。這裏要達成的一個效果是Downgrade操作完對於用戶來講完全的透明。
其次元數據以及其layout的rollback回滾操作，退回到和之前Old Version一樣的格式。
當然關於升級還有其它別的要點需要關注，類似總升級時間的限制等等，本文筆者只是取其中部分要點進行略微闡述。
引用
[1].https://issues.apache.org/jira/browse/HDFS-5535
[2].https://issues.apache.org/jira/browse/HDDS-3698