我建議您閱讀 Andrey Borodin 2019 年初的報告文字記錄“WAL-G 備份。2019 年有什麼？”
大家好！ 我叫安德烈·鮑羅丁。 我是 Yandex 的開發人員。 自 2016 年以來，我一直對 PostgreSQL 感興趣，在我與開發人員交談後，他們說一切都很簡單 - 你獲取原始程式碼並建立它，一切都會成功。 從那時起我就停不下來——我寫了各種不同的東西。
我正在做的事情之一是備份系統。 。 總的來說，在 Yandex，我們很長時間以來一直致力於 PostgreSQL 的備份系統。 您可以在網路上找到一系列關於我們如何製作備份系統的六份報告。 每年他們都會進化一點，發展一點，變得更可靠。
但今天的報告不僅是關於我們做了什麼，而且是關於它有多簡單以及是什麼。 你們當中有多少人已經看過我關於 WAL-G 的報導？ 還好有不少人沒看，因為我會從最簡單的開始。
如果你突然有了一個 PostgreSQL 集群，而且我想每個人都有幾個，並且突然還沒有備份系統，那麼你需要獲得任何 S3 儲存或 Google Cloud 相容儲存。
例如，您可以來到我們的展位並獲取與 S3 相容的 Yandex 物件儲存的促銷代碼。
然後創建一個桶子。 它只是一個資訊容器。
建立服務用戶。
為服務使用者建立存取金鑰：aws-s3-key。
下載 WAL-G 的最新穩定版本。
我們的預發布版本與發布版本有何不同？ 我經常被要求提前釋放。 如果版本在足夠長的時間內（例如一個月）沒有出現錯誤，那麼我就會發布它。 這是 XNUMX 月發布的版本。 這意味著我們每個月都會發現某種錯誤，通常是在非關鍵功能中，但我們尚未發布版本。 之前的版本只有XNUMX月。 其中沒有我們已知的錯誤，即隨著專案的進展添加了錯誤。
下載 WAL-G 後，您可以執行一個簡單的「備份清單」指令，並傳入環境變數。 它將連接到物件儲存並告訴您有哪些備份。 當然，首先您不應該有備份。 這張投影片的目的是表明一切都很簡單。 這是一個接受環境變數並執行子命令的控制台命令。
之後，您可以進行第一次備份。 在 WAL-G 中說出「backup-push」並在 WAL-G 中指定叢集的 pgdata 位置。 最有可能的是，如果您還沒有備份系統，PostgreSQL 會告訴您需要啟用「歸檔模式」。
這意味著您需要進入設定並打開“archive_mode = on”並添加“archive_command”，這也是WAL-G中的子命令。 但出於某種原因，人們經常在這個主題上使用 bar 腳本並將其包裝在 WAL-G 周圍。 請不要這樣做。 使用 WAL-G 中的功能。 如果您遺漏了什麼，請寫信至 。 WAL-G 假定它是在 archive_command 中執行的唯一程式。
我們使用WAL-G主要是在Yandex資料庫管理中建立高可用性叢集。
通常用於一主多副本的拓樸中。 同時，它在 Yandex 物件儲存中製作備份副本。
最常見的場景是使用時間點復原建立叢集的副本。 但在這種情況下，備份系統的效能對我們來說並不是那麼重要。 我們只需要從備份上傳一個新的叢集。
通常，我們在新增節點時需要備份系統效能。 為什麼它如此重要？ 通常，人們會向叢集新增節點，因為現有叢集無法處理讀取負載。 他們需要添加新的副本。 如果我們把pg_basebackup的負載加到Master上，那麼Master可能會崩潰。 因此，對我們來說非常重要的是，我們可以快速從存檔中上傳新節點，從而在主節點上創建最小的負載。
還有一個類似的情況。 這是從失去連線的資料中心切換 Cluster Master 後需要重新啟動舊的 Master。
- 結果，在製定複製系統的需求時，我們意識到pg_basebackup不適合我們在雲端操作時的情況。
- 我們希望能夠壓縮我們的數據。 但除了自備的備份系統之外，幾乎所有備份系統都將提供資料壓縮功能。
- 我們希望將一切並行化，因為雲端中的用戶購買了大量的處理器核心。 但如果我們在某些操作中沒有並行性，那麼大量的核心就變得毫無用處。
- 我們需要加密，因為資料通常不屬於我們，無法以明文形式儲存。 順便說一下，我們對 WAL-G 的貢獻是從加密開始的。 我們在WAL-G中完成了加密，之後有人問我們：“也許我們中的一個人會開發這個項目？” 從那時起，我已經與 WAL-G 合作了一年多。
- 我們還需要資源節流，因為隨著使用雲端的時間的推移，我們發現有時人們在晚上有重要的雜貨負載，並且該負載不能被幹擾。 這就是我們添加資源限制的原因。
- 以及上市和管理。
- 並驗證。
我們研究了很多不同的工具。 幸運的是，我們在 PostgreSQL 中有大量的選擇。 我們到處都缺少一些東西，有些是一項小功能，有些是一項小功能。
在檢查了現有系統後，我們得出的結論是我們將開發 WAL-G。 那時這是一個新項目。 容易影響備份系統雲端基礎設施的發展。
我們堅持的主要理念是 WAL-G 應該像巴拉萊卡琴一樣簡單。
WAL-G 有 4 個指令。 這：
WAL-PUSH – 歸檔軸。
WAL-FETCH – 取得軸。
BACKUP-PUSH – 進行備份。
BACKUP-FETCH – 從備份系統取得備份。
事實上，WAL-G也對這些備份進行管理，即列出和刪除歷史中暫時不再需要的記錄和備份。
對我們來說重要的功能之一是建立增量副本的功能。
增量副本意味著我們不會建立整個叢集的完整備份，而只會建立叢集中已更改檔案的已更改頁面。 從功能上看，這與使用 WAL 進行恢復的能力非常相似。 但我們可以並行匯總 WAL 單線程增量備份。 因此，當我們在周六進行基本備份、每天進行增量備份、週四失敗時，我們需要匯總 4 個增量備份和 10 小時的 WAL。 由於增量備份並行滾動，因此大約需要相同的時間。
基於 LSN 的增量 - 這意味著在建立備份時，我們需要組合每個頁面並檢查其 LSN 與前一個備份的 LSN，以便了解它是否已更改。 任何可能包含更改資料的頁面都應該出現在增量備份中。
正如我所說，並行性受到了相當多的關注。
但 PostgreSQL 中的存檔 API 是一致的。 PostgreSQL 歸檔一個 WAL 文件，恢復時要求一個 WAL 文件。 但是，當資料庫使用「WAL-FETCH」命令請求一個 WAL 檔案時，我們呼叫「WAL-PREFETCH」命令，該命令準備接下來的 8 個檔案以並行地從物件儲存中取得資料。
當資料庫要求我們歸檔一個檔案時，我們會查看 archive_status 並查看是否還有其他 WAL 檔案。 而我們也在嘗試並行下載WAL。 這提供了顯著的性能增益，並顯著減少了未歸檔 WAL 數量的距離。 許多備份系統開發人員認為這是一個風險很大的系統，因為我們依賴程式碼內部的知識，而不是 PostgreSQL API。 PostgreSQL 不保證我們存在 archive_status 資料夾，也不保證那裡的 WAL 檔案的語意、就緒訊號的存在。 儘管如此，我們正在研究原始程式碼，我們發現確實如此，我們正在嘗試利用它。 我們控制著 PostgreSQL 的發展方向；如果這個機制突然被打破，我們就會停止使用它。
在其純粹形式中，基於 LSN 的 WAL 增量需要讀取自上次備份以來檔案系統中的模式時間已更改的任何叢集檔案。 我們忍受了很長一段時間，差不多一年了。 最後我們得出的結論是我們有 WAL 增量。
這意味著我們每次在Master上歸檔WAL時，我們不僅會壓縮、加密並將其發送到網絡，而且同時還會對其進行讀取。 我們分析並閱讀其中的記錄。 我們了解哪些區塊已更改並收集增量檔案。
增量文件描述了一定範圍的WAL文件，描述了在這個範圍的WAL中哪些區塊被改變的資訊。 然後這些增量檔案也被存檔。
在這裡，我們面臨著這樣一個事實：我們很快就並行化了所有內容，但我們無法並行讀取順序歷史記錄，因為在某個段落中，我們可能會遇到前一個WAL 記錄的末尾，而我們還沒有任何東西可以連接，因為平行閱讀導致我們首先分析未來，而未來還沒有過去。
結果，我們不得不將難以理解的部分放入 _delta_partial 檔案中。 結果，當我們回到過去時，我們會將 WAL 記錄的各個部分粘合在一起，然後我們將解析它並了解其中發生了什麼變化。
如果在我們的軸解析歷史中至少有一個點我們不明白發生了什麼，那麼相應地，在下一次備份期間，我們將被迫再次讀取整個集群，就像我們對常規 LSN 所做的那樣基於三角洲。
結果，我們所有的痛苦都導致了我們開源WAL-G解析函式庫。 據我所知，還沒有人在使用它，但如果有人想編寫和使用它，它就屬於公共領域。 （更新了連結 )
因此，所有的資訊流看起來都相當複雜。 我們的大師存檔軸並存檔增量文件。 並且製作備份副本的副本必須在備份之間經過的時間內接收增量檔案。 在這種情況下，需要大量新增並解析部分歷史記錄，因為並非整個歷史記錄適合大段。 只有在此之後，副本才能歸檔完整增量備份。
在圖表上，一切看起來都簡單得多。 這是從我們的真實集群之一下載的。 我們有基於 LSN 的、一日之內製作的產品。 我們看到基於 LSN 的增量備份從凌晨三點運行到凌晨五點。 這是處理器核心數量的負載。 WAL-delta在這裡花了我們大約20分鐘，也就是說，它變得明顯更快，但同時網路上的交換也更加激烈。
由於我們掌握了有關資料庫歷史記錄中哪些區塊發生更改以及發生時間的信息，因此我們進一步決定整合功能 - 一個名為“pg_prefaulter”的 PostgreSQL 擴展
這意味著當備用庫執行恢復命令時，它告訴 WAL-G 取得下一個 WAL 檔案。 我們大致了解 WAL 復原過程將在不久的將來存取哪些資料區塊，並對這些區塊發起讀取操作。 這樣做是為了提高 SSD 控制器的效能。 因為WAL磁碟區會到達需要更改的頁面。 該頁位於磁碟上，不在頁快取中。 而他會同步等待這個頁面的到達。 但附近是 WAL-G，它知道在接下來的幾百兆位元組的 WAL 中我們將需要某些頁面，同時開始預熱它們。 啟動多個磁碟訪問，以便並行執行。 這在 SSD 驅動器上效果很好，但不幸的是，它絕對不適用於硬碟，因為我們只會透過提示來幹擾它。
這就是現在程式碼中的內容。
我們想添加一些功能。
從這張圖可以看出WAL-delta花費的時間比較短。 這是讀取白天資料庫中發生的變更。 我們不僅可以在晚上進行 WAL-delta，因為它不再是重要的負載源。 我們每分鐘都可以讀 WAL-delta，因為它很便宜。 一分鐘內我們可以掃描集群發生的所有變化。 這可以稱為“即時 WAL-delta”。
關鍵是，當我們恢復集群時，我們減少了必須按順序滾動的故事數量。 也就是說，應該減少 PostgreSQL 滾動的 WAL 量，因為這需要花費大量時間。
但這還不是全部。 如果我們知道某些區塊將被更改為備份一致性點，那麼我們就無法更改它過去。 也就是說，現在我們對 WAL-delta 轉送進行了逐一檔的最佳化。 這意味著，例如，如果週二完全刪除了表或從表中完全刪除了某些文件，那麼當週一增量滾動並恢復週六的 pg_basebackup 時，我們甚至不會創建此資料。
我們希望將這項技術擴展到頁面層級。 也就是說，如果文件的某些部分在周一發生了變化，但在周三會被覆蓋，那麼當恢復到週四的某個點時，我們不需要將前幾個版本的頁面寫入磁碟。
但這仍然是我們內部正在積極討論的想法，但尚未達到程式碼。
我們想在 WAL-G 中再增加一項功能。 我們希望使其可擴展，因為我們需要支援不同的資料庫，並且希望能夠以相同的方式進行備份管理。 但問題是 MySQL API 完全不同。 在MySQL中，PITR不是基於實體WAL日誌，而是基於binlog。 而且我們在 MySQL 中沒有歸檔系統來告訴外部系統這個 binlog 已經完成並且需要歸檔。 我們需要站在 cron 中資料庫的某個地方，檢查是否有準備好的東西？
同樣，在MySQL復原期間，沒有復原指令可以告訴系統我需要這樣或那樣的檔案。 在開始重建叢集之前，您需要知道需要哪些檔案。 您自己需要猜測您將需要哪些文件。 但這些問題或許可以透過某種方式規避。 （澄清：MySQL 已經支援）
在報告中，我還想談談WAL-G不適合你的那些情況。
如果您沒有同步副本，WAL-G 不保證最後一個段落將被保留。 如果歸檔落後於歷史的最後幾段，那就是一個風險。 如果沒有同步副本，我不建議使用WAL-G。 儘管如此，它主要是為雲端安裝而設計的，這意味著具有同步副本的高可用性解決方案，它負責最後提交的位元組的安全性。
我經常看到人們嘗試同時運行 WAL-G 和 WAL-E。 我們支援向後相容性，即 WAL-G 可以從 WAL-E 恢復文件，並且可以恢復在 WAL-E 中製作的備份。 但由於這兩個系統都使用並行 wal-push，它們開始互相竊取檔案。 如果我們在 WAL-G 中修復它，它仍然會保留在 WAL-E 中。 在 WAL-E 中，它會查看歸檔狀態，查看已完成的檔案並將其歸檔，而其他系統根本不知道此 WAL 檔案存在，因為 PostgreSQL 不會嘗試再次歸檔它。
我們要在 WAL-G 方面修復什麼？ 我們不會通知 PostgreSQL 該檔案是並行傳輸的，當 PostgreSQL 要求我們歸檔它時，我們已經知道具有此模式時間和此 md5 的檔案已經歸檔，我們會簡單地說 PostgreSQL -好的，一切都準備好了，基本上不需要做任何事。
但這個問題不太可能在 WAL-E 端得到解決，因此目前無法建立將檔案同時歸檔到 WAL-G 和 WAL-E 中的歸檔指令。
另外，現在有些情況WAL-G不適合您，但我們一定會修復它。
首先，我們目前沒有內建的備份驗證。 我們在備份或復原期間都沒有驗證。 當然，這是在雲端實現的。 但這是簡單地透過預檢查、簡單地恢復叢集來實現的。 我想把這個功能提供給使用者。 但透過驗證，我假設在 WAL-G 中可以恢復叢集並啟動它，並執行冒煙測試：pg_dumpall 到 /dev/null 和 amcheck 索引驗證。
目前在 WAL-G 中，無法推遲 WAL 的一項備份。 也就是說，我們支持一些視窗。 例如，儲存最近 XNUMX 天、儲存最近 XNUMX 個備份、儲存最近 XNUMX 個完整備份。 人們常常過來說：“我們需要備份新年發生的事情，我們希望永遠保留它。” WAL-G 還不知道如何做到這一點。 （注意 - 這已修復。閱讀更多 - 備份標記選項 )
在驗證 PITR 時，我們沒有對所有軸段進行頁面校驗和和完整性檢查。
由此，我為 Google Summer of Code 整理了一個專案。 如果你認識聰明的學生，他們想用 Go 寫一些東西，並從一家帶有字母「G」的公司獲得數千美元，那麼向他們推薦我們的專案。 我將擔任這個專案的導師，他們可以做到。 如果沒有學生，那麼暑假我就拿去自己做。
我們還有許多其他小問題正在逐步解決。 一些非常奇怪的事情發生了。
例如，如果您給 WAL-G 一個空備份，它就會掉落。 例如，如果您告訴他需要備份一個空資料夾。 pg_control 檔案將不存在。 他會認為他不明白某些事。 理論上，在這種情況下，您需要向使用者編寫一條普通訊息，向他解釋如何使用該工具。 但這甚至不是程式設計的特徵，而是良好的、易於理解的語言的特徵。
我們不知道如何進行離線備份。 如果資料庫說謊，我們就無法備份它。 但這裡的一切都很簡單。 我們在啟動時透過 LSN 來呼叫備份。 底層庫的LSN必須從控製檔中讀取。 這是一個尚未實現的功能。 許多備份系統可以備份底層資料庫。 而且很方便。
我們目前無法正確處理備份空間不足的問題。 因為我們通常在家處理大量備份。 但他們沒有抽出時間去做。 但是，如果有人現在想用 Go 進行編程，請將對空間不足錯誤的處理添加到儲存桶中。 我一定會研究拉取請求。
讓我們擔心的主要事情是我們需要盡可能多的 docker 整合測試來檢查各種場景。 目前我們只測試基本場景。 在每次提交時，我們希望逐次檢查我們支援的所有功能。 特別是，例如，我們將對 PostgreSQL 9.4-9.5 提供足夠的支援。 我們支持它們是因為社群支援 PostgreSQL，但我們不會逐次檢查提交以確保一切都沒有損壞。 在我看來，這是一個相當嚴重的風險。
我們在 Yandex 資料庫管理中的一千多個叢集上運行 WAL-G。 它每天備份數百 TB 的資料。
我們的程式碼中有很多 TODO。 如果你想編程，來吧，我們正在等待拉取請求，我們正在等待問題。
問題
晚安! 謝謝你！ 我的猜測是，如果您使用 WAL-delta，您可能會嚴重依賴全頁寫入。 如果是這樣，您是否進行了測試？ 你展示了一個漂亮的圖表。 關閉FPW會變得多麼美麗？
我們啟用了全頁寫入，但我們沒有嘗試停用它。 也就是說，我作為開發人員並沒有嘗試將其關閉。 研究過的系統管理員大概都研究過這個問題。 但我們需要 FPW。 幾乎沒有人禁用它，因為否則就不可能從副本中備份。
感謝您的報告！ 我有兩個問題。 第一個問題是表空間會發生什麼事？
我們正在等待拉取請求。 我們的資料庫駐留在 SSD 和 NMVE 磁碟上，我們其實不需要此功能。 我現在還沒有準備好花大量時間來做好這件事。 我衷心主張我們支持這一點。 有人支持它，但以適合他們的方式支持它。 他們做了一個分叉，但他們不做拉取請求。 （0.2.13版本新增）
第二個問題。 您一開始就說過，WAL-G 假設它單獨工作，不需要包裝器。 我自己用包裝紙。 為什麼不應該使用它們？
我們希望它像三弦琴一樣簡單。 這意味著除了三弦琴之外，您根本不需要任何東西。 我們希望系統簡單。 如果您有需要在腳本中完成的功能，請告訴我們 - 我們將在 Go 中完成。
晚安! 感謝您的報告！ 我們無法讓 WAL-G 與 GPG 解密一起使用。 它正常加密，但不想解密。 這對我們來說是不成功的事嗎？ 情況令人沮喪。
在 GitHub 上建立一個問題，讓我們來解決這個問題。
也就是說，你沒有遇過這種情況嗎？
錯誤報告有一個特點，當WAL-G不明白它是什麼類型的文件時，它會詢問：“也許它被加密了？” 也許問題根本不在於加密。 我想改進這個主題的日誌記錄。 他必須破解它。 我們目前正在研究這個主題，因為我們不太喜歡取得公鑰和私鑰的系統的組織方式。 因為我們呼叫外部 GPG，以便它為我們提供金鑰。 然後我們把這些金鑰傳輸到內部GPG，這是開放的PGP，它是在WAL-G內部為我們編譯的，我們稱之為加密。 對此，我們希望改進系統，希望支援Libsodium加密（在0.2.15版本中新增）。 當然，解碼應該可以工作，讓我們弄清楚 - 你需要的不僅僅是幾個單字的症狀。 您可以找個時間聚集在演講者的房間並查看系統。 （無需外部 GPG 的 PGP 加密 - v0.2.9）
你好！ 感謝您的報告！ 我有兩個問題。 我有一個奇怪的願望，希望在兩個提供者中執行 pg_basebackup 和 WAL 登錄，即我想做一個雲，另一個。 有什麼方法可以做到這一點嗎？
現在這個想法不存在了，但這是一個有趣的想法。
我只是不信任某個提供者，我想在另一個提供者擁有相同的服務，以防萬一。
這個想法很有趣。 從技術上來說，這並不難實現。 為了防止這個想法丟失，我可以請你在 GitHub 上問一個問題嗎？
是的，當然。
然後，當學生來到 Google Summer of Code 時，我們會將他們加入專案中，以便他們有更多的工作來獲得更多收益。
第二個問題。 GitHub 上有一個問題。 我認為它已經關閉了。 恢復期間出現恐慌。 為了打敗它，你做了一個單獨的組件。 在問題上是對的。 並且可以選擇在一個執行緒中執行可變環境。 這就是為什麼它運行得非常慢的原因。 而且我們也遇到了這個問題，而且還沒解決。
問題是，由於某種原因，當我們以高並發存取儲存（CEPH）時，它會重置連接。 關於這個還能做什麼？ 重試邏輯如下圖所示。 我們正在嘗試再次下載該文件。 在一次傳遞中，我們有許多文件未下載，我們將為所有未登入的人製作第二個文件。 只要每次迭代至少載入一個文件，我們就會重複、重複、重複。 我們改進了重試的邏輯—指數退避。 但目前尚不完全清楚如何處理儲存系統端的連線中斷這一事實。 也就是說，當我們上傳到一個串流時，它不會破壞這些連線。 這裡我們可以改進什麼？ 我們有網路限制，我們可以透過每個連線發送的位元組數來限制它。 否則，我不知道如何處理物件儲存不允許我們從它並行下載或下載的事實。
沒有 SLA？ 這不是寫給他們如何讓自己受折磨的嗎？
關鍵是提出這個問題的人通常都有自己的金庫。 也就是說，沒有人來自 Amazon、Google Cloud 或 Yandex Object Storage。
也許這個問題不再適合你？
在這種情況下，問題對誰來說並不重要。 如果有任何關於如何處理這個問題的想法，讓我們在 WAL-G 中實現。 但到目前為止我對如何處理這個問題還沒有好的想法。 有一些物件儲存支援以不同方式列出備份。 您要求他們列出對象，他們會在其中添加資料夾。 WAL-G 對此感到害怕 - 這裡有某種不是檔案的東西，我無法恢復它，這意味著備份沒有恢復。 也就是說，事實上，您有一個完全恢復的集群，但它返回了一個錯誤狀態，因為物件儲存返回了一些它不完全理解的奇怪資訊。
這是發生在郵件雲中的事情。
如果你能建立一個重現...
它不斷地被複製...
如果有重現，那麼我認為我們將嘗試重試策略，並找出如何重試並了解雲端對我們的要求。 也許對我們來說在三個連接上會很穩定，不會斷開連接，那麼我們就小心的達到三個。 因為現在我們很快就斷開連接，也就是說，如果我們啟動了 16 個執行緒的恢復，那麼第一次重試後將有 8 個執行緒、4 個執行緒、2 個執行緒和 7,5 個執行緒。 然後它將把檔案拉入一個流中。 如果有一些神奇的值，例如 7,5 線程最適合泵送，那麼我們將詳細討論它們並嘗試製作另一個 XNUMX 個線程。 這是一個想法。
感謝您的報告！ 使用 WAL-G 的完整工作流程是什麼樣的？ 例如，在頁面之間沒有增量的愚蠢情況下。 我們取出並刪除最初的備份，然後將軸歸檔，直到我們臉色發青。 據我了解，這裡出現了故障。 在某些時候，您需要對頁面進行增量備份，即某些外部進程正在驅動此備份，或者這是如何發生的？
增量備份 API 非常簡單。 那裡有一個數字——最大增量步數，這就是它的名字。 它預設為零。 這意味著每次執行備份推送時，它都會下載完整備份。 如果將其變更為任何正數，例如 3，那麼下次執行備份推送時，它將查看先前備份的歷史記錄。 他看到你沒有超過 3 個 delta 的鏈，並製作了一個 delta。
也就是說，每次我們啟動 WAL-G 時，它都會嘗試進行完整備份？
不，我們運行 WAL-G，如果您的政策允許，它會嘗試實現增量。
粗略地說，如果每次都用零運行它，它的行為會像pg_basebackup嗎？
不，它仍然會運行得更快，因為它使用壓縮和並行性。 pg_basebackup 會將軸放在你旁邊。 WAL-G 假定您已配置歸檔。 如果沒有配置它會發出警告。
Pg_basebackup 可以在沒有軸的情況下運作。
是的，那麼他們的行為幾乎是一樣的。 pg_basebackup 複製到檔案系統。 順便說一句，我們有一個我忘記提及的新功能。 我們現在可以從 pg_basebackup 備份到檔案系統。 我不知道為什麼需要這個，但它就在那裡。
例如，在 CephFS 上。 並不是每個人都想配置物件儲存。
是的，這可能是他們詢問有關此功能的問題的原因，以便我們可以做到這一點。 我們做到了。
感謝您的報告！ 只是有一個關於複製到檔案系統的問題。 開箱即用，您現在是否支援複製到遠端存儲，例如，如果資料中心或其他地方有某個架子？
在這個表述中，這是一個難題。 是的，我們支持，但此功能尚未包含在任何版本中。 也就是說，所有預發行版都支援這一點，但發行版不支援。 該功能是在0.2版本中新增的。 一旦我們修復了所有已知的錯誤，它肯定會很快發布。 但目前這只能在預發布中完成。 預發行版有兩個錯誤。 WAL-E 恢復有問題，我們尚未修復。 在最新的預發行版中新增了有關增量備份的錯誤。 因此，我們推薦大家使用release版本。 一旦預發布中沒有更多錯誤，我們可以說我們支援 Google Cloud、S3 相容的東西和文件儲存。
您好，感謝您的報告。 據我了解，WAL-G 不是像酒保那樣的某種集中式系統嗎？ 你打算朝這個方向發展嗎？
問題是我們已經偏離了這個方向。 WAL-G 存在於基本主機、叢集主機以及叢集中的所有主機上。 當我們搬到數千個集群時，我們安裝了許多調酒師。 每當其中有東西崩潰時，這就是一個大問題。 因為它們需要修復，所以您需要了解哪些叢集現在沒有備份。 我不打算在備份系統的實體硬體方向上開發WAL-G。 如果社群想要這裡的一些功能，我一點也不介意。
我們有負責儲存的團隊。 我們感覺很好，不是我們，而是有特殊的人將我們的文件放在安全的地方。 他們在那裡進行各種巧妙的編碼，以承受一定數量文件的遺失。 他們負責網路頻寬。 當你有調酒師時，你可能會突然發現流量很大的小型資料庫都聚集在同一台伺服器上。 您似乎有很多空間，但由於某種原因，所有內容都無法通過網路。 結果可能恰恰相反。 那裡有很多網絡，有處理器核心，但這裡沒有磁碟。 我們厭倦了這種需要兼顧的事情，我們轉向這樣一個事實：資料儲存是一項單獨的服務，由單獨的特殊人員負責。
PS 新版本已經發布 ，您可以在其中使用 .walg.json 配置文件，該文件預設位於 postgres 主目錄中。 您可以放棄 bash 腳本。 範例 .walg.json 在本期中
視頻：
來源： www.habr.com