Postgresql

PostgreSQL 預寫日誌存檔模式

  • January 18, 2022

我試圖弄清楚 PostgreSQL 周圍的各種事情,以及備份應該如何與 WAL 和 Commvault Simpana 一起工作。Simpana 告訴我一切正常,但文件仍留在 WAL 存檔目錄中。

讓旅程開始吧。

環境

PostgreSQL 和作業系統版本

PostgreSQL 9.3 在 Ubuntu 14.04.3 LTS 伺服器上執行。

Postgres WAL 配置

postgres.conf 文件為 WAL 歸檔設置如下。

#------------------------------------------------------------------------------
# WRITE AHEAD LOG
#------------------------------------------------------------------------------
# - Settings -
#wal_level = minimal                    # minimal, archive, or hot_standby
wal_level = archive

[...]

# - Archiving -
archive_mode = on
#archive_mode = off             # allows archiving to be done
                               # (change requires restart)
archive_command = 'cp %p /pgsql-backup/archive/postgres1/%f'
                               # command to use to archive a logfile segment
                               # archive_command = ''           
                               # command to use to archive a logfile segment
                               # placeholders: %p = path of file to archive
                               #               %f = file name only
                               # e.g. 'test ! -f /mnt/server/archivedir/%f    && cp %p /mnt/server/archivedir/%f'
#archive_timeout = 0            # force a logfile segment switch after this
                               # number of seconds; 0 disables

如果test ...零件留在其中,archive_command它會破壞 Simpana 備份,這就是我們省略它的原因。

上面的配置應該會導致 WAL 文件從/pg_xlog/目錄複製到/pgsql-backup/archive/postgres1/目錄,當…

  1. 不再需要,因為 pg_basebackup
  2. WAL 文件已滿(預設為 16MB)且不再使用

Commvault Simpana

客戶端電腦已配置為備份存檔日誌目錄中的 PostgreSQL 數據庫/實例和 WAL 文件。不再需要時應刪除 WAL 文件,因為已為 PostgreSQL 客戶端設置了 Simpana 選項“刪除存檔”。

預期行為

因為 Simpana 正在使用 PostgreSQL 本機命令執行備份,所以我希望當 Simpana 完成完整備份或 WAL 備份時,/pgsql-backup/archive/postgres1/目錄中的文件將被刪除。

有效行為

當我/pgsql-backup/archive/postgres1/在 Simpana 執行備份後檢查目錄時,目錄中還會有一個帶有0000000300000037000000nn.mmmmmmmm.backup語法的文件。這暗示 Simpana 正在使用本機 PostgreSQL 命令執行備份,因為0000000300000037000000nn.mmmmmmmm.backup只有在使用pg_basebackup. 這只是我在閱讀 PostgreSQL 9.3 的文件後得出的結論。

以下是目錄內容的範例:

[...]
00000003000000370000007A
00000003000000370000007B.00000028.backup
000000030000003700000091.00000028.backup
000000030000003700000093.00000028.backup
000000030000003700000095.00000028.backup
000000030000003700000097.00000028.backup
000000030000003700000099.00000028.backup
00000003000000370000009B.00000028.backup

PostgreSQL 文件

官方文件指出

要使用備份,您需要保留在文件系統備份期間和之後生成的所有 WAL 段文件。為了幫助您執行此操作,基本備份過程會創建一個備份歷史文件,該文件會立即儲存到 WAL 存檔區域中。該文件以文件系統備份所需的第一個 WAL 段文件命名。例如,如果起始 WAL 文件是 0000000100001234000055CD,則備份歷史文件將命名為 0000000100001234000055CD.007C9330.backup。(文件名的第二部分代表 WAL 文件中的確切位置,通常可以忽略。)一旦您安全地歸檔了文件系統備份和備份期間使用的 WAL 段文件(如備份歷史記錄中指定的那樣)文件),不再需要名稱數字較小的所有已歸檔 WAL 段來恢復文件系統備份,並且可以將其刪除。但是,您應該考慮保留幾個備份集,以絕對確定您可以恢復數據。

這破壞了我的結論,即 Simpana 正在使用本機 PostgreSQL 命令來備份目錄中的數據庫/實例及其 WAL 存檔日誌文件/pgsql-backup/archive/postgres1/

根據文件,nnnnnnnnnnnnnnnnnnnnnn.mmmmmmmm.backup 文件是指向成功前滾恢復所需的最早 WAL 文件的指針。存檔日誌目錄中的任何舊 WAL 文件都可以刪除並且不再需要。

讓我吃驚的是,Archive Log 目錄中有一個 WAL 文件,沒有對應的 *.mmmmmmmm.backup 指針文件。

問題

  1. 如果我不使用 Simpana 進行備份,誰會(必須)刪除 WAL 存檔目錄中的 *.mmmmmmmm.backup 文件?pg_archivecleanup命令?
  2. 為什麼存檔日誌目錄中仍然有一個完整的 WAL 文件,而它應該像存檔日誌目錄中的所有其他 WAL 文件一樣被刪除?
  3. 為什麼存檔日誌目錄中沒有00000003000000370000007A.mmmmmmmm.backup仍然存在的WAL 文件的文件?00000003000000370000007A

我期待您的回复,並希望有人在某個地方有類似的 Simpana 和 PostgreSQL 配置。

這似乎從根本上是關於 Commvault Simpana 的問題,而不是 PostgreSQL 的問題。由於 Commvault 似乎是商業軟體,因此您最好聯繫他們的支持台。

預期行為 因為 Simpana 正在使用 PostgreSQL 本機命令執行備份,所以我希望當 Simpana 完成完整備份或 WAL 備份時,/pgsql-backup/archive/postgres1/ 目錄中的文件將被刪除。

我不知道這裡的“WAL 備份”是什麼意思。這是 Simpana 特有的術語嗎?這是否只是意味著您原始存檔目錄中的 WAL 文件已被複製到某個異地儲存?

問題 如果我不使用 Simpana 進行備份,誰會(必須)刪除 WAL 存檔目錄中的 *.mmmmmmmm.backup 文件?pg_archivecleanup 命令?

如果您不使用 Simpana,那麼您將使用其他東西。我們不能告訴你其他東西會是什麼——有很多選擇。雖然pg_archivecleanup是一種這樣的方法,但這些天它看起來已經過時了。如果您只想將 WAL 文件保留足夠長的時間以便在備用設備上安全地儲存(或重放)它們,您現在可以使用“流式複制”,從而完全取消日誌傳送。

或者您可以製定一個永久保留第一個基本備份的策略(在您初始化空數據庫之後立即),以及從那時起存檔的每個 WAL 文件,以便您可以對歷史中的任何時間進行時間點恢復您的數據庫。

為什麼存檔日誌目錄中仍然有一個完整的 WAL 文件,而它應該像存檔日誌目錄中的所有其他 WAL 文件一樣被刪除?

在我看來,當 Simpana 決定清理存檔時,它不是刪除所有比目前需要的最舊文件更舊的 WAL 文件,而是刪除從上次清理時仍需要的文件開始的文件範圍,結束在目前需要的那個之前的那個。

如果是這種情況,那麼如果一個 WAL 文件在您打開歸檔後立即被 PostgreSQL 歸檔,但在啟動 Simpana 之前(或在它得到支持之前),那麼該文件將永遠不會被刪除。

為什麼歸檔日誌目錄中仍然存在的 00000003000000370000007A WAL 文件沒有 00000003000000370000007A.mmmmmmmm.backup 文件?

如果在 00000003000000370000007A 是活動的 WAL 文件期間沒有啟動備份,那麼首先就不會有 00000003000000370000007A.mmmmmmmm.backup 文件。

引用自:https://dba.stackexchange.com/questions/133144