我記得在前面已經以regular方式為例詳細的講述了有關namenode啟動的過程，在開始本文的重點之前，我覺得還是有必要在簡單的描述一下這個過程：
好了，再回到本文將要闡述的重點吧——namenode節點的公升級/回滾/提交，這一步實際上只發生在上面過程的第一步：載入fsimage+editlog。前面我提過關係：檔案->資料塊持久化在本地磁碟上，所有對目錄樹的更新和檔名->資料塊關係的修改，都必須能夠持久化，為了保證每一次的修改不需要從新儲存整個結構，hdfs使用操作日誌來儲存更新。先來看一下與
目錄current：
目錄image：
in_use.lock的功能是防止其它的namenode節點讀取該目錄；fsimage儲存的是檔案系統的目錄(包括檔名->資料塊對映)；edits則是儲存檔案數上的操作日誌；fstime上一次新開啟乙個操作日誌的時間(long)。image/fsimage是乙個保護檔案，防止0.13以前的版本啟動出錯(0.13以前的版本將fsimage存放在name/image目錄下)。那麼，namenode在完成公升級/回滾/提交時，對這些檔案做了哪些操作呢？
在理想的情況下，上面的公升級/回滾/提交可以順利的完成，但是也難免會出現一些異常情況，特別是在進行上述操作的過程中，namenode節點出現突然斷電事件。不要緊，namenode在啟動載入fsimage+editlog時有乙個自動恢復的處理，當然這乙個過程明顯發生在真正load fsimage+editlog之前。下面我們來看看namenode節點在異常發生之後可以處於那些中間狀態，以及它在下一次啟動時是如何處理的。
pod 公升級與回滾
pod 公升級方式 1 刪掉舊pod,在部署新pod.2 建立新pod,通過修改service選擇器後刪除舊pod 3 滾動式公升級 rolling update 4 使用deployment宣告方式公升級 前兩者不在詳述，都需要中斷業務。kubectl 滾動式公升級 實驗 定義kubia v1 y...
openssh公升級和回滾
公升級有很多教程，但是回滾沒有很詳細的教程，因為回滾操作很少操作，但是生產環境要有預案，雖然我的回滾解決辦法有點蠢，但是沒有時間去研究那摩多，當時，直接把有關原環境資訊cp備份，然後回滾的時候還原。親測可用！wget o openssh 8.4p1.tar.gz wget o zlib 1.2.11...
Nginx的平滑公升級和回滾
隨著 併發訪問量越來越高，nginx web 伺服器也越來越流行，nginx 版本換代越來越頻繁，1.16.2版本的nginx更新了許多新功能，生產環境中版本公升級必然的，但是線上業務不能停，此時nginx的公升級就是運維的重要工作了。多程序模式下的請求分配方式 nginx預設工作在多程序模式下，即...