PostgreSQL 連續(xù)歸檔和時間點恢復(fù)（PITR）

抽象地來說，一個運行中的PostgreSQL系統(tǒng)產(chǎn)生一個無窮長的WAL記錄序列。系統(tǒng)從物理上將這個序列劃分成WAL 段文件，通常是每個16MB（段尺寸在initdb期間可修改）。段文件會被分配一個數(shù)字名稱以便反映它在整個抽象WAL序列中的位置。在沒有使用WAL歸檔時，系統(tǒng)通常只創(chuàng)建少量段文件，并且通過重命名不再使用的段文件為更高的段編號來 “回收”它們。系統(tǒng)假設(shè)內(nèi)容位于最后一個檢查點之前的段文件是無用的且可以被回收。

在歸檔WAL數(shù)據(jù)時，我們需要在每一段被填充滿時捕捉其內(nèi)容，并且在段文件被回收重用之前保存該數(shù)據(jù)。依靠應(yīng)用和可用的硬件，有很多不同的方法來“保存數(shù)據(jù)”：我們可以將段文件拷貝到一個已掛載的位于另一臺機器上的NFS目錄，或者將它們寫出到一個磁帶驅(qū)動器（確保你有辦法標(biāo)識每個文件的原始文件名），或者將它們批量燒錄到CD上，或者其他什么方法。為了向數(shù)據(jù)庫管理員提供靈活性，PostgreSQL不對如何歸檔做任何假設(shè)。取而代之的是， PostgreSQL讓管理員聲明一個shell命令來拷貝一個完整的段文件到它需要去的地方。 該命令可以簡單得就是一個cp，或者它可以調(diào)用一個復(fù)雜的 shell 腳本 — 所有都由你決定。

要啟用WAL歸檔，需設(shè)置wal_level配置參數(shù)為replica或更高，設(shè)置archive_mode為on，并且使用 archive_command配置參數(shù)指定一個shell命令。實際上，這些設(shè)置總是被放置在postgresql.conf文件中。在archive_command中，%p會被將要歸檔的文件路徑所替代，而%f只會被文件名所替代（路徑名是相對于當(dāng)前工作目錄而言的，即集簇的數(shù)據(jù)目錄）。如果你需要在命令中嵌入一個真正的 %字符，可以使用%%。最簡單的命令類似于：

archive_command = 'test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f'  # Unix
archive_command = 'copy "%p" "C:\\server\\archivedir\\%f"'  # Windows

它將把 WAL 段拷貝到目錄/mnt/server/archivedir（這個只是一個例子，并非我們建議的方法，可能不能在所有系統(tǒng)上都正確運行）。在%p和%f參數(shù)被替換之后，實際被執(zhí)行的命令看起來可能是：

test ! -f /mnt/server/archivedir/00000001000000A900000065 && cp pg_wal/00000001000000A900000065 /mnt/server/archivedir/00000001000000A900000065

對每一個將要被歸檔的新文件都會生成一個類似的命令。

歸檔命令將在運行PostgreSQL服務(wù)器的同一個用戶的權(quán)限下執(zhí)行。因為被歸檔的一系列WAL 文件實際上包含你的數(shù)據(jù)庫里的所有東西，所以你應(yīng)該確保自己的歸檔數(shù)據(jù)不會被別人窺探； 比如，歸檔到一個沒有組或者全局讀權(quán)限的目錄里。

有一點很重要：當(dāng)且僅當(dāng)歸檔命令成功時，它才返回零退出。在得到一個零值結(jié)果之后，PostgreSQL將假設(shè)該文件已經(jīng)成功歸檔， 因此它稍后將被刪除或者被新的數(shù)據(jù)覆蓋。但是，一個非零值告訴PostgreSQL該文件沒有被歸檔； 因此它會周期性的重試直到成功。

歸檔命令通常應(yīng)該被設(shè)計成拒絕覆蓋已經(jīng)存在的歸檔文件。這是一個非常重要的安全特性， 可以在管理員操作失誤（比如把兩個不同的服務(wù)器的輸出發(fā)送到同一個歸檔目錄）的時候保持你的歸檔的完整性。

我們建議你首先要測試你準(zhǔn)備使用到歸檔命令，以保證它實際上不會覆蓋現(xiàn)有的文件，并且在這種情況下它返回非零狀態(tài)。以上Unix中的命令例子通過包含一個獨立的test步驟來保證這一點。在某些Unix平臺上，cp具有諸如-i的開關(guān)，可用來更簡潔地完成這一切，但是在沒有驗證返回的退出狀態(tài)正確之前你不能依賴它們（特別地，GNU的 cp在使用-i時將對已存在的目標(biāo)文件返回狀態(tài)零，這并不是我們所期望的行為）。

在設(shè)計你的歸檔環(huán)境時，請考慮一下如果歸檔命令不停失敗會發(fā)生什么情況， 因為有些情況要求操作者的干涉，或者是歸檔空間不夠了。 例如，如果你往磁帶機上寫，但是沒有自動換帶機，那么就有可能發(fā)生這種情況； 如果磁帶滿了，除非換磁帶，否則任何事也做不了。 你應(yīng)該確保任何錯誤情況或者任何要求操作員干涉的情況都會被正確報告， 這樣才能迅速解決這些問題。否則pg_wal/目錄會不停地被WAL段文件填充，直到問題解決（如果包含pg_wal/的文件系統(tǒng)被填滿， PostgreSQL將會做一次致命關(guān)閉。不會有未提交事務(wù)被丟失，但是數(shù)據(jù)庫將會保持離線直到你釋放一部分空間）。

歸檔命令的速度并不要緊，只要它能跟上你的服務(wù)器生成 WAL 數(shù)據(jù)的平均速度即可。即使歸檔進(jìn)程稍微落后，正常的操作也會繼續(xù)進(jìn)行。 如果歸檔進(jìn)程慢很多，就會增加災(zāi)難發(fā)生的時候丟失的數(shù)據(jù)量。這同時也意味著pg_wal/目錄包含大量未歸檔的段文件， 并且可能最后超出了可用磁盤空間。我們建議你監(jiān)控歸檔進(jìn)程，確保它是按照你的期望運轉(zhuǎn)的。

在寫自己的歸檔命令的時候，你應(yīng)該假設(shè)被歸檔的文件名最長為64個字符并且可以包含 ASCII 字母、數(shù)字以及點的任意組合。 我們不需要保持原始的相對路徑（%p），但是有必要保持文件名（%f）。

請注意盡管 WAL 歸檔允許你恢復(fù)任何對你的PostgreSQL數(shù)據(jù)庫中數(shù)據(jù)所做的修改， 但它不會恢復(fù)對配置文件的修改（即postgresql.conf、pg_hba.conf以及pg_ident.conf），因為這些文件都是手工編輯的，而不是通過 SQL 操作來編輯的。 所以你可能會需要把你的配置文件放在一個日常文件系統(tǒng)備份過程可處理的位置。如何重定位配置文件請參閱第 19.2 節(jié)。

歸檔命令只會為完成的WAL段調(diào)用。因此如果你的服務(wù)器產(chǎn)生了一點點WAL流量（或者在產(chǎn)生時有寬松的周期），從一個事務(wù)完成到它被安全地記錄在歸檔存儲中之間將會有較長的延遲。要為未歸檔數(shù)據(jù)設(shè)置一個年齡限制，你可以設(shè)置archive_timeout來強制要求服務(wù)器按照其設(shè)定的頻度切換到一個新的WAL段。注意由于強制切換而被歸檔的文件還是具有和完全歸檔的文件相同的長度。因此設(shè)置一個很短的 archive_timeout是很不明智的 — 它會膨脹你的歸檔存儲。將archive_timeout設(shè)置為1分鐘左右通常是合理的。

同樣，如果你希望確保一個剛剛完成的事務(wù)能被盡快歸檔，可以使用pg_switch_wal進(jìn)行一次手動段切換。其他與WAL管理相關(guān)的使用函數(shù)在表 9.85中列出。

如第 14.4.7 節(jié)所述，當(dāng)wal_level為minimal時，一些SQL命令被優(yōu)化為避免記錄WAL日志。在這些語句的其中之一的執(zhí)行過程中如果打開了歸檔或流復(fù)制，WAL中將不會包含足夠的信息用于歸檔恢（崩潰恢復(fù)不受影響）。出于這個原因， wal_level只能在服務(wù)器啟動時修改。但是，archive_command可以通過重載配置文件來修改。如果你希望暫時停止歸檔，一種方式是將archive_command設(shè)置為空串（''）。這將導(dǎo)致WAL文件積累在pg_wal/中，直到一個可用的 archive_command被重新建立。

執(zhí)行一次基礎(chǔ)備份最簡單的方法是使用pg_basebackup工具。它將會以普通文件或一個tar歸檔的方式創(chuàng)建一個基礎(chǔ)備份。如果需要比pg_basebackup更高的靈活性，你也可以使用低級API（見本文中第 25.3.3 節(jié)）來制作一個基礎(chǔ)備份。

沒有必要關(guān)心創(chuàng)建一個基礎(chǔ)備份所需的時間。但是，如果你正常地運行停用了full_page_writes的服務(wù)器，你可能會注意到備份運行時的性能下降，因為full_page_writes在備份模式期間會被實際強制實施。

要使用備份，你將需要保留所有在文件系統(tǒng)備份期間及之后生成的WAL段文件。為了便于你做這些，基礎(chǔ)備份過程會創(chuàng)建一個備份歷史文件，它將被立刻存儲到WAL歸檔區(qū)域。該文件以文件系統(tǒng)備份中你需要的第一個WAL段文件命名。例如，如果開始的WAL文件是0000000100001234000055CD，則備份歷史文件將被命名為0000000100001234000055CD.007C9330.backup.（文件名的第二部分表明WAL文件中的一個準(zhǔn)確位置，一般可以被忽略）。一旦你已經(jīng)安全地歸檔了文件系統(tǒng)備份和在備份過程中被使用的WAL段文件（如備份歷史文件中所指定的） ，所有名字在數(shù)字上低于備份歷史文件中記錄值的已歸檔WAL段對于恢復(fù)文件系統(tǒng)備份就不再需要了，并且可以被刪除。但是你應(yīng)該考慮保持多個備份集以絕對保證你能恢復(fù)你的數(shù)據(jù)。

備份歷史文件是一個很小的文本文件。它包含你指定給pg_basebackup的標(biāo)簽字符串，以及備份的起止時間以及起止WAL段。如果你使用該標(biāo)簽來標(biāo)識相關(guān)轉(zhuǎn)儲文件，則已歸檔的歷史文件足以說明需要哪個轉(zhuǎn)儲文件進(jìn)行恢復(fù)。

由于你不得不保存最后一次基礎(chǔ)備份之后的所有歸檔WAL文件，基礎(chǔ)備份之間的間隔通常應(yīng)該根據(jù)你希望在歸檔WAL文件上花費的存儲空間來設(shè)定。你也應(yīng)該考慮你準(zhǔn)備花多長時間來進(jìn)行恢復(fù)，如果需要恢復(fù) — 系統(tǒng)將不得不重放所有那些WAL段，如果這些WAL段覆蓋了最后一次基礎(chǔ)備份以后的很長時間，重放過程將會花費一些時間。

使用低級API制作一個基礎(chǔ)備份的過程比pg_basebackup方法要包含更多的步驟，但相對要更簡單。很重要的一點是，這些步驟要按照順序執(zhí)行，并且在執(zhí)行下一步之前要驗證上一步是否成功。

可以用非排他或者排他的方法來制作低級基礎(chǔ)備份。我們推薦非排他方法，而排他 的方法已經(jīng)被廢棄并且最終將被去除。

好，現(xiàn)在最壞的情況發(fā)生了，你需要從你的備份進(jìn)行恢復(fù)。這里是其過程：

所有這些的關(guān)鍵部分是設(shè)定一個恢復(fù)配置，它描述你希望如何恢復(fù)以及恢復(fù)要運行到什么程度。你絕對必須指定的是restore_command，它告訴PostgreSQL如何獲取歸檔WAL文件段。與archive_command相似，這也是一個shell命令字符串。它可以包含%f（將被期望的日志文件名替換）和 %p（將被日志文件被拷貝的目標(biāo)路徑名替換）。（路徑名是相對于當(dāng)前工作目錄的，即集簇的數(shù)據(jù)目錄）。如果你需要在命令中嵌入一個真正的%字符，可以寫成%%。最簡單的命令類似于：

restore_command = 'cp /mnt/server/archivedir/%f %p'

它將從目錄/mnt/server/archivedir中拷貝之前歸檔的WAL段。當(dāng)然，你可以使用更復(fù)雜的，甚至是一個要求操作者裝載合適磁帶的shell腳本。

重要的是命令在失敗時返回非零退出狀態(tài)。該命令將被調(diào)用來請求不在歸檔中的文件， 在這種情況下它應(yīng)該返回非零值。這不是一種錯誤情況。一種例外是該命令被一個信號（除了被用作數(shù) 據(jù)庫服務(wù)器關(guān)閉動作一部分的SIGTERM）終止或者被shell的錯誤 （例如命令未找到）終止，那樣恢復(fù)將中止并且服務(wù)器將不會啟動。

并非所有被請求的文件都是WAL段文件，你也許還會請求一些具有.history后綴的文件。還要注意的是，%p路徑的基本名字將會和%f 不同，但不要期望它們可以互換。

歸檔中找不到的WAL段可以在pg_wal/中看到，這使得可以使用最近未歸檔的段。但是，在歸檔中可用的段將會被優(yōu)先于pg_wal/中的文件被使用。

通常，恢復(fù)將會處理完所有可用的WAL段，從而將數(shù)據(jù)庫恢復(fù)到當(dāng)前時間點（或者盡可能接近給定的可 用WAL段）。因此，一個正常的恢復(fù)將會以一個“文件未找到”消息結(jié)束，錯誤消息的準(zhǔn)確文 本取決于你選擇的restore_command。你也可能在恢復(fù)的開始看到一個針對名稱類 似于00000001.history文件的錯誤消息。這也是正常的并且不表示在簡單恢復(fù)情 況中的問題，對此的討論見本文中第 25.3.5 節(jié)。

如果你希望恢復(fù)到之前的某個時間點（例如，恢復(fù)到幼稚的DBA丟棄了你主要的交易表之前），只需要 指定要求的停止點。你可以使用日期/時間、命名恢復(fù)點或一個 指定事務(wù)ID的結(jié)束時間來定義停止點（也被稱為“恢復(fù)目標(biāo)”）。在這種寫法中，只有日期/時 間和命名恢復(fù)點選項非常有用，因為沒有工具可以幫助你準(zhǔn)確地確定要用哪個事務(wù)ID。

如果恢復(fù)找到被破壞的WAL數(shù)據(jù)，恢復(fù)將會停止于該點并且服務(wù)器不會啟動。在這種情況下，恢復(fù)進(jìn)程需要從開頭重新開始運行，并指定一個在損壞點之前的“恢復(fù)目標(biāo)”以便恢復(fù)能夠正常完成。如果恢復(fù)由于一個外部原因失敗，例如一個系統(tǒng)崩潰或者WAL歸檔變?yōu)椴豢稍L問，則該次恢復(fù)可以被簡單地重啟并且它將會從幾乎是上次失敗的地方繼續(xù)?；謴?fù)重啟工作起來很像普通操作時的檢查點：服務(wù)器周期性地強制把它的所有狀態(tài)寫到磁盤中，然后更新 pg_control文件來說明已經(jīng)處理過的WAL數(shù)據(jù)，這樣它們就不會被再次掃描。

將數(shù)據(jù)庫恢復(fù)到一個之前的時間點的能力帶來了一些復(fù)雜性，這和有關(guān)時間旅行和平行宇宙的科幻小說有些相似。例如，在數(shù)據(jù)庫的最初歷史中，假設(shè)你在周二晚上5：15時丟棄了一個關(guān)鍵表，但是一直到周三中午才意識到你的錯誤。不用苦惱，你取出你的備份，恢復(fù)到周二晚上5：14的時間點，并上線運行。在數(shù)據(jù)庫宇宙的這個歷史中，你從沒有丟棄該表。但是假設(shè)你后來意識到這并非一個好主意，并且想回到最初歷史中周三早上的某個時間。你沒法這樣做，在你的數(shù)據(jù)庫在線運行期間，它重寫了某些WAL段文件，而這些文件本來可以將你引向你希望回到的時間。因此，為了避免出現(xiàn)這種狀況，你需要將完成時間點恢復(fù)后生成的WAL記錄序列與初始數(shù)據(jù)庫歷史中產(chǎn)生的WAL記錄序列區(qū)分開來。

要解決這個問題，PostgreSQL有一個時間線概念。無論何時當(dāng)一次歸檔恢復(fù)完成，一個新的時間線被創(chuàng)建來標(biāo)識恢復(fù)之后生成的WAL記錄序列。時間線ID號是WAL段文件名的一部分，因此一個新的時間線不會重寫由之前的時間線生成的WAL數(shù)據(jù)。實際上可以歸檔很多不同的時間線。雖然這可能看起來是一個無用的特性，但是它常常扮演救命稻草的角色?？紤]到你不太確定需要恢復(fù)到哪個時間點的情況，你可能不得不做多次時間點恢復(fù)嘗試和錯誤，直到最終找到從舊歷史中分支出去的最佳位置。如果沒有時間線，該處理將會很快生成一堆不可管理的混亂。而有了時間線，你可以恢復(fù)到 任何 之前的狀態(tài)，包括早先被你放棄的時間線分支中的狀態(tài)。

每次當(dāng)一個新的時間線被創(chuàng)建，PostgreSQL會創(chuàng)建一個“時間線歷史”文件，它顯示了新時間線是什么時候從哪個時間線分支出來的。系統(tǒng)在從一個包含多個時間線的歸檔中恢復(fù)時，這些歷史文件對于允許系統(tǒng)選取正確的WAL段文件非常必要。因此，和WAL段文件相似，它們也要被歸檔到WAL歸檔區(qū)域。歷史文件是很小的文本文件，因此將它們無限期地保存起來的代價很小，而且也是很合適的（而段文件都很大）。如果你喜歡，你可以在一個歷史文件中增加注釋來記錄如何和為什么要創(chuàng)建該時間線。當(dāng)你由于試驗的結(jié)果擁有了一大堆錯綜復(fù)雜的不同時間線時，這種注釋將會特別有價值。

恢復(fù)的默認(rèn)行為是沿著相同的時間線進(jìn)行恢復(fù)，該時間線是基礎(chǔ)備份創(chuàng)建時的當(dāng)前時間線。如果你希望恢復(fù)到某個子女時間線（即，你希望回到在一次恢復(fù)嘗試后產(chǎn)生的某個狀態(tài)），你需要在recovery_target_timeline中指定目標(biāo)時間線ID。你不能恢復(fù)到早于該基礎(chǔ)備份之前分支出去的時間線。

這里將給出一些配置連續(xù)歸檔的建議。

archive_command = 'test ! -f /var/lib/pgsql/backup_in_progress || (test ! -f /var/lib/pgsql/archive/%f && cp %p /var/lib/pgsql/archive/%f)'

touch /var/lib/pgsql/backup_in_progress
psql -c "select pg_start_backup('hot_backup');"
tar -cf /var/lib/pgsql/backup.tar /var/lib/pgsql/data/
psql -c "select pg_stop_backup();"
rm /var/lib/pgsql/backup_in_progress
tar -rf /var/lib/pgsql/backup.tar /var/lib/pgsql/archive/

archive_command = 'gzip < %p > /var/lib/pgsql/archive/%f'

restore_command = 'gunzip < /mnt/server/archivedir/%f > %p'

archive_command = 'local_backup_script.sh "%p" "%f"'

在編寫此文檔時，連續(xù)歸檔技術(shù)存在一些限制。這可能會在未來的發(fā)布中被修復(fù)：

還需要注意的是，默認(rèn)的WAL格式相當(dāng)龐大，因為它包括了很多磁盤頁快照。這些頁快照被設(shè)計用于支持崩潰恢復(fù)，因為我們可能需要修復(fù)斷裂的磁盤頁。依靠你的系統(tǒng)硬件和軟件，頁斷裂的風(fēng)險可能會小到可以忽略，在此種情況下你可以通過使用full_page_writes參數(shù)關(guān)閉頁快照來顯著降低歸檔日志的總?cè)萘浚ㄔ谶@樣做之前閱讀 第 29 章中的注解和警告）。關(guān)閉頁快照并不會阻止使用日志進(jìn)行PITR操作。一個未來的開發(fā)點是通過移除不需要的頁拷貝來壓縮歸檔的WAL數(shù)據(jù)，即使full_page_writes為on。同時，管理員可能希望通過盡可能增大檢查點間隔參數(shù)來減少WAL中包含的頁快照數(shù)量。