許多人都熟悉 PostgreSQL DBMS，並且它已經在小型安裝中證明了自己。 然而，即使涉及大公司和企業需求，開源的趨勢也越來越明顯。 在本文中，我們將向您介紹如何將Postgres整合到企業環境中，並以Commvault備份系統為例，分享我們為此資料庫建立備份系統（BSS）的經驗。
PostgreSQL 已經證明了它的價值——DBMS 運作良好，它被阿里巴巴和 TripAdvisor 等時尚數位企業所使用，而且無需支付許可費，使其成為 MS SQL 或 Oracle DB 等龐然大物的誘人替代品。 但一旦我們開始考慮企業環境中的 PostgreSQL，我們立即就會遇到嚴格的要求：「配置容錯怎麼樣？ 抗災能力？ 全面監控在哪裡？ 自動備份怎麼樣？ 直接使用磁帶庫和在輔助存儲上使用磁帶庫怎麼樣？”
一方面，PostgreSQL 沒有內建的備份工具，例如 Oracle DB 中的 RMAN 或 SAP 資料庫備份等「成人」DBMS。 另一方面，企業備份系統的供應商（Veeam、Veritas、Commvault）雖然支援 PostgreSQL，但實際上他們只能使用某種（通常是獨立的）配置並受到一系列各種限制。
專門為 PostgreSQL 設計的備份系統，例如 Barman、Wal-g、pg_probackup，在 PostgreSQL DBMS 的小型安裝或不需要對 IT 環境的其他元素進行大量備份的情況下非常受歡迎。 例如，除了 PostgreSQL 之外，基礎架構還可能包括實體和虛擬伺服器、OpenShift、Oracle、MariaDB、Cassandra 等。 建議使用通用工具來備份所有這些。 專門為 PostgreSQL 安裝單獨的解決方案是一個壞主意：資料將複製到磁碟的某個位置，然後需要將其刪除到磁帶。 這種雙重備份增加了備份時間，更重要的是，增加了復原時間。
在企業解決方案中，安裝備份是在專用叢集中的一定數量的節點上進行的。 同時，例如Commvault只能與雙節點叢集一起工作，其中Primary和Secondary被嚴格分配給某些節點。 而且只有從主節點備份才有意義，因為從輔助節點備份有其限制。 由於 DBMS 的特殊性，不會在輔助資料庫上建立轉儲，因此僅保留檔案備份的可能性。
為了降低停機風險，在建立容錯系統時，會建立「即時」叢集配置，並且 Primary 可以在不同伺服器之間逐步遷移。 例如，Patroni 軟體本身在隨機選擇的叢集節點上啟動 Primary。 IBS 無法立即追蹤此情況，如果配置發生變化，流程就會中斷。 也就是說，外部控制的引入阻礙了ISR的有效工作，因為控制伺服器根本不知道需要從哪裡複製什麼資料。
另一個問題是Postgres中備份的實作。 這可以透過轉儲來實現，並且適用於小型資料庫。 但在大型資料庫中，轉儲需要很長時間，需要大量資源，並且可能導致資料庫執行個體失敗。
檔案備份可以糾正這種情況，但在大型資料庫上速度很慢，因為它在單線程模式下工作。 此外，供應商還有許多額外的限制。 您不能同時使用文件和轉儲備份，或不支援重複資料刪除。 存在著許多問題，而且大多數情況下，選擇昂貴但經過驗證的 DBMS 比 Postgres 更容易。
無處可退！ 莫斯科開發商落後了！
然而，最近我們的團隊面臨著一個艱鉅的挑戰：在創建AIS OSAGO 2.0的專案中，我們創建了IT基礎設施，開發人員選擇了PostgreSQL作為新系統。
對於大型軟體開發人員來說，使用「流行」的開源解決方案要容易得多。 Facebook 有足夠的專家來支援這個 DBMS 的運作。 而對於RSA來說，「第二天」的所有任務都落在了我們的肩上。 我們需要確保容錯、組裝集群，當然也要設定備份。 行動邏輯如下：
- 指導 SRK 從叢集的主節點進行備份。 為此，SRK 必須找到它 - 這意味著需要與一個或另一個 PostgreSQL 叢集管理解決方案整合。 對於 RSA，Patroni 軟體用於此目的。
- 根據資料量和復原需求決定備份類型。 例如，當您需要粒度恢復頁面時，請使用轉儲，如果資料庫很大且不需要粒度恢復，請在檔案層級工作。
- 將區塊備份的可能性附加到解決方案中，以在多執行緒模式下建立備份副本。
同時，我們最初著手創建一個有效且簡單的系統，而不需要大量的附加元件。 拐杖越少，工作人員的工作量就越少，IBS 失敗的風險就越低。 我們立即排除了使用 Veeam 和 RMAN 的方法，因為一組兩種解決方案已經暗示了系統的不可靠性。
企業的小魔法
因此，我們需要保證 10 個叢集（每個叢集有 3 個節點）的可靠備份，並在備份資料中心鏡像相同的基礎設施。 PostgreSQL 的資料中心遵循主動-被動原則。 資料庫總大小為 50 TB。 任何企業級控制系統都可以輕鬆應對這個問題。 但要注意的是，最初 Postgres 並不知道與備份系統的完全和深度相容性。 因此，我們必須尋找一種最初能夠與 PostgreSQL 結合發揮最大功能的解決方案，並完善系統。
我們舉行了 3 場內部「黑客馬拉松」——我們研究了 XNUMX 多個開發項目，對其進行了測試，根據我們的假設進行了更改，然後再次進行了測試。 在審查了可用選項後，我們選擇了 Commvault。 該產品開箱即用，可以與簡單的 PostgreSQL 叢集安裝一起使用，其開放式架構為成功開發和整合帶來了希望（這是合理的）。 Commvault 還可以備份 PostgreSQL 日誌。 例如，Veritas NetBackup 就 PostgreSQL 而言只能進行全量備份。
更多關於建築的資訊。 Commvault 管理伺服器以 CommServ HA 配置安裝在兩個資料中心中。 該系統透過一個控制台進行鏡像和管理，從 HA 的角度來看，可以滿足所有企業需求。
我們還在每個資料中心啟動了兩台實體媒體伺服器，透過光纖通道將專用於 SAN 備份的磁碟陣列和磁帶庫連接到這些伺服器。 擴展的重複資料刪除資料庫確保了媒體伺服器的容錯能力，並且將每個伺服器連接到每個 CSV 可以在任何元件發生故障時進行連續操作。 即使其中一個資料中心發生故障，該系統架構也允許備份繼續進行。
Patroni 為每個群集定義一個主節點。 它可以是資料中心中的任何空閒節點 - 但只是大部分。 在備份中，所有節點都是輔助節點。
為了讓 Commvault 了解哪個叢集節點是主要節點，我們將系統（得益於解決方案的開放架構）與 Postgres 整合。 為此，建立了一個腳本，用於向 Commvault 管理伺服器報告主節點的當前位置。
一般來說，該過程如下所示：
Patroni 選擇主節點 → Keepalived 選擇 IP 叢集並執行腳本 → 所選叢集節點上的 Commvault 代理程式會收到這是主節點的通知 → Commvault 會自動在偽客戶端內重新配置備份。
這種方法的優點是該解決方案不會影響日誌的一致性、正確性或Postgres實例的復原。 它也易於擴展，因為不再需要修復 Commvault 主節點和輔助節點。 系統知道 Primary 在哪裡就足夠了，節點數量可以增加到幾乎任何值。
該解決方案並不假裝是理想的，並且有其自身的細微差別。 Commvault 只能備份整個實例，而不能備份單一資料庫。 因此，為每個資料庫建立了一個單獨的實例。 真實的客戶端被組合成虛擬的偽客戶端。 每個 Commvault 偽客戶端都是一個 UNIX 叢集。 安裝了 Commvault Agent for Postgres 的叢集節點將會加入其中。 這樣一來，偽客戶端的所有虛擬節點都會作為一個實例進行備份。
在每個偽客戶端內，指示叢集的活動節點。 這就是我們的 Commvault 整合解決方案所定義的。 其操作原理非常簡單：如果在節點上引發叢集 IP，腳本會在 Commvault 代理二進位檔案中設定「活動節點」參數 - 事實上，腳本會在記憶體的所需部分設定「1」 。 代理程式將此資料傳輸到 CommServe，然後 Commvault 從所需節點進行備份。 此外，在腳本層級檢查配置的正確性，有助於避免啟動備份時發生錯誤。
同時，大型資料庫跨多執行緒分塊備份，滿足RPO和備份視窗要求。 系統上的負載微不足道：完整副本不會經常發生，在其他日子以及低負載期間僅收集日誌。
順便說一句，我們應用了單獨的策略來備份 PostgreSQL 歸檔日誌 - 它們根據不同的規則存儲，根據不同的計劃進行複製，並且不會為它們啟用重複資料刪除，因為這些日誌包含唯一的資料。
為了確保整個 IT 基礎架構的一致性，每個叢集節點上都安裝了單獨的 Commvault 檔案用戶端。 它們從備份中排除 Postgres 文件，並且僅用於作業系統和應用程式備份。 這部分數據也有自己的政策和儲存期限。
目前，IBS 不會影響生產力服務，但如果情況發生變化，Commvault 可以啟用負載限制。
好嗎？ 好的！
因此，我們不僅收到了一個可行的、而且是完全自動化的 PostgreSQL 叢集安裝備份，而且它滿足了企業呼叫的所有要求。
1小時和2小時的RPO和RTO參數都有餘裕，這意味著即使儲存資料量大幅增加，系統也會遵守它們。 與許多質疑相反，事實證明 PostgreSQL 和企業環境非常相容。 現在，根據我們自己的經驗，我們知道可以在多種配置中備份此類 DBMS。
當然，這一路走來，我們穿破了七雙鐵靴，克服了一些困難，踩了幾把耙子，糾正了一些錯誤。 但現在該方法已經經過測試，可用於在惡劣的企業條件下實施開源而不是專有的 DBMS。
您是否嘗試過在企業環境中使用 PostgreSQL？
作者：
Oleg Lavrenov，Jet Infosystems 資料儲存系統設計工程師
Dmitry Erykin，Jet Infosystems 電腦系統設計工程師
來源： www.habr.com