在第二部分中，我們開始設計PostgreSQL控制器。 今天，我們從上次停下來的地方開始，然后開始詳細介紹控制層(包括控制器和附帶工具)如何跟蹤PostgreSQL應用程序的狀態。

PostgreSQL應用程序的真實狀態包含許多組件：

· 每個PostgreSQL實例的當前狀態(狀態)：健康嗎？ 是主服務器(主服務器)還是備用服務器(從服務器)？ 還在配置嗎？

· 每個PostgreSQL實例的期望狀態(規范)：應該是主要狀態嗎？ 它應該從哪里流式傳輸WAL(預寫日志)？

· 整個應用程序的當前狀態：哪些實例屬于該PostgreSQL應用程序？ 備份寫在哪里？

· 整個應用程序的期望狀態：應該有多少個實例？ 備份到哪里去？

該真實狀態在中央存儲區中編碼，控制層使用該狀態來決定其需要做什么。 控制層的每個元素都負責維護部分編碼狀態：

· 無論是個人還是其他應用程序，應用程序管理員都負責設置應用程序整體的所需狀態。

· 控制器維護整個應用程序的當前狀態以及各個PostgreSQL實例的期望狀態。

· 每個PostgreSQL實例均由Sidecar控制，該Sidecar負責維護實例的當前狀態。

PostgreSQL實例狀態

在第一部分中，我們介紹了PostgreSQL實例必須實現的一些行為。 例如，當主數據庫啟動時，它將執行以下操作：

· 初始化數據庫，可能是從預先存在的備份中初始化。

· 配置連續備份。

· 配置流復制，包括身份驗證機制。

我們如何編碼實例的當前狀態取決于我們是否將上述三個動作捆綁為一個步驟。 如果僅一步，狀態轉換可能看起來像這樣：

· 未設定

· 完成設置

使用這種編碼，控制器無法確定實例所處的設置步驟。根據整體設計，這可能很好。 如果控制器需要更多有關實例設置過程的可見性，則狀態轉換可能看起來像這樣：

· 未設定

· 數據庫已初始化

· 備份配置

· 完成設置

在這兩種設計中，控制器設置的期望狀態為：

· 完成設置

實例Sidecar盡其所能將其當前狀態移至所需狀態。

實例故障

到目前為止，我聲稱PostgreSQL實例sidecar負責維護中央存儲區中編碼的當前狀態。 這并非完全正確。

當PostgreSQL實例Pod發生故障(由于Node發生故障，被逐出或剛剛崩潰)時，中央存儲中的當前狀態應表示該實例發生了故障。 雜物箱是Pod的一部分，因此，如果Pod死了，則沒有正在運行的雜物箱來更新中央商店。

解決方案是在實例失敗時使用外部代理更新中央存儲。 一種方法是執行Pod健康檢查。 然后，PostgreSQL控制器可以檢查其每個實例的Pod狀態，以查看哪些實例發生故障。 在這種模型中，Kubernetes和實例Sidecar共同負責在中央商店中維護實例的當前狀態。

PostgreSQL整個應用程序狀態

上一節是關于實例級狀態的。 在進入應用程序級狀態之前，我想解決控制器與實例Sidecar之間的關鍵區別。

實例死亡時，它將保持死亡狀態。 控制器死亡后，將使用新的控制器來代替。

之前，我們可以選擇編碼實例設置，既可以是從"未完成"到"完成"的單狀態轉換，也可以是從"未完成"到"步驟1"到"步驟2"到"完成"的多個轉換。 之所以存在這種選擇，是因為Sidecar不必依賴中央存儲中實例的當前狀態。 它可以簡單地將當前狀態保存在內存中。

另一方面，控制器確實依賴中央存儲中應用程序的當前狀態。 如果控制器死了，則其更換必須能夠從中斷處繼續進行。 例如，考慮故障轉移過程：

· 狀態：健康(1個主要狀態，2個備用狀態)→操作：無

· 狀態：不正常(0個主要狀態，2個備用狀態)→操作：將一個備用狀態所需的狀態設置為"主要"。

· 狀態：運行狀況良好(1個主數據庫，1個備用數據庫)→操作：創建一個新的備用數據庫

· 狀態：健康(1個主要狀態，2個備用狀態)→操作：無

注意，每個當前狀態對應于特定動作(給定特定期望狀態)。

如果控制器在步驟2中死亡，則替換控制器會做什么？ 前一個控制器是否執行了該動作？ 如果可以安全地重試該操作(即該操作是冪等的)，則替換控制器可以簡單地執行該操作，而不管原始控制器是否執行了該操作。 否則，可能的狀態集必須區分這兩種情況。

對于上面的步驟2，該操作只是在中央存儲區中寫入所需的狀態。 由于替換控制器可以寫入與其前任相同的期望狀態，因此該操作可能是冪等的。 另一種方法是在步驟2和3之間添加一個中間狀態：

2.狀態：不正常(0個主要狀態，2個備用狀態)→操作：將一個備用狀態所需的狀態設置為"主要"。

2.5。 狀態：不健康(0個主節點，2個備用數據庫)，正在等待升級備用數據庫1＃→操作：無

3.狀態：運行狀況良好(1個主數據庫，1個備用數據庫)→操作：創建一個新的備用數據庫

請注意，此方法要求操作和狀態更改以原子方式一起發生。 否則，控制器可能會在執行第2步的操作之后并在將狀態更新為2.5之前失敗。 替換負責人會認為第2步的操作尚未發生。

在此處的示例中，操作是設置實例的所需狀態。 如果應用程序的當前狀態包括每個實例的所需狀態，則操作和狀態更改確實會自動發生。 對于其他類型的操作，這將不成立。 最好確保這些動作是冪等的。

還剩什么？

到目前為止，我們已經廣泛地介紹了如何在Kubernetes上高度可用的PostgreSQL應用程序中協調PostgreSQL實例的生命周期。 如果您想在特定區域獲得更多詳細信息，請在評論中告訴我！ 有很多要討論的內容，所以請幫助我選擇下一部分內容。

不過，確保PostgreSQL正在運行并不是我們關注的終點。 我們仍然必須注意可觀察性，負載平衡，管理備份存檔等。 敬請關注。

(本文翻譯自Kynan Rilee的文章《PostgreSQL on Kubernetes the Right Way: Part Three》，參考：https://medium.com/kokster/postgresql-on-kubernetes-the-right-way-part-three-32fbd36942f)

總結

以上是生活随笔為你收集整理的postgresql 备份_在Kubernetes上使用PostgreSQL的正确姿势：第三部分的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。