24.3. 在線備份以及即時恢復(PITR) · PostgreSQL 中文文檔 9.3

# 24.3\. 在線備份以及即時恢復(PITR) 在任何時候，PostgreSQL都在集群的數據目錄的`pg_xlog/` 子目錄里維護著一套_預寫日志_(WAL)。這些日志記錄著每一次對數據庫的修改細節。這些日志存在是為了防止崩潰：如果系統崩潰，數據庫可以通過"重放"上次檢查點以來的日志記錄以恢復數據庫的完整性。但是，日志的存在讓它還可以用于第三種備份數據庫的策略：我們可以組合文件系統備份與WAL文件的備份。如果需要恢復，我們就恢復備份，然后重放備份了的WAL文件，把備份恢復到當前的時間。這個方法對管理員來說，明顯比以前的方法更復雜，但是有非常明顯的優勢： * 在開始的時候我們不需要一個非常完美的一致的備份。任何備份內部的不一致都會被日志重放動作修改正確 (這個和崩潰恢復時發生的事情沒什么區別)。因此我們不需要文件系統快照的功能，只需要tar或者類似的歸檔工具。 * 因為我們可以把無限長的WAL文件序列連接起來，所以連續的備份簡化為連續地對WAL文件歸檔來實現。這個功能對大數據庫特別有用，因為大數據庫的全備份可能并不方便。 * 我們可沒說重放WAL記錄的時候我們必須重放到結尾。我們可以在任意點停止重放，這樣就有一個在任意時間的數據庫一致的快照。因此，這個技術支持_即時恢復_：我們可以把數據庫恢復到你開始備份以來的任意時刻的狀態。 * 如果我們持續把WAL文件序列填充給其它裝載了同樣的基礎備份文件的機器，我們就有了一套_熱備份_系統：在任何點我們都可以啟動第二臺機器，而它擁有近乎當前的數據庫拷貝。 > **Note:** pg_dump和 pg_dumpall沒有產生文件系統級別備份，并且不能作為連續歸檔解決方案的一部分。比如備份是_符合邏輯的_并且不包含 WAL重放使用的足夠信息。和簡單的文件系統備份技術一樣，這個方法只能支持整個數據庫集群的恢復，而不是一個子集。同樣，它還要求大量的歸檔存儲：基礎備份量可能很大，而且忙碌的系統將生成許多兆需要備份的的WAL流量。但是，它仍然時在需要高可靠性的場合下的最好的備份技術。要想從連續歸檔中成功恢復（也被許多數據庫供應商稱為"在線備份"），你需要一套連續的WAL歸檔文件，它們最遠回朔到你開始備份的時刻。因此，要想開始備份，你應該在開始第一次基礎備份_之前_根據我們討論過的歸檔WAL文件機制設置并測試你的步驟。 ## 24.3.1\. 設置WAL歸檔抽象來看，一個運行著的PostgreSQL系統生成一個無限長的WAL日志序列。系統物理上把這個序列分隔成WAL_段文件_，通常每段16M(在編譯PostgreSQL的時候可以改變其大小)。這些段文件的名字是數值命名的，這些數值反映他們在抽取出來的 WAL 序列中的位置。在不適用WAL歸檔的時候，系統通常只是創建幾個段文件然后"循環"使用它們，方法是把不再使用的段文件的名字重命名為更高的段編號。系統假設那些內容比前一次檢查點更老的段文件已經沒用了，然后就可以循環利用。在歸檔WAL數據的時候，我們希望在每個段文件填充滿之后捕獲之，并且把這些數據在段文件被循環利用之前保存在某處。根據應用以及可用的硬件的不同，我們可以有許多不同的方法"把數據保存在某處"：我們可以把段文件拷貝到一個 NFS 掛載的目錄，把它們放到另外一臺機器上，或者把它們寫入磁帶機里(需要保證你有辦法把文件恢復為原名)，或者把它們打成包，燒錄到 CD 里，或者是其它的什么方法。為了給數據庫管理員提供最大可能性的靈活性， PostgreSQL試圖不對如何歸檔做任何假設。取而代之的是， PostgreSQL讓管理員聲明一個shell命令執行來拷貝一個完整的段文件到它需要去的地方。該命令可以簡單得就是一個`cp`，或者它可以調用一個復雜的shell腳本— 這些都由管理員決定。為了啟動WAL歸檔，設置[wal_level](#calibre_link-1039) 配置參數到`archive` (或者`hot_standby`), [archive_mode](#calibre_link-1038)為`on`，并且所使用的shell命令由配置參數[archive_command](#calibre_link-467)聲明，它實際上總是放在`postgresql.conf`文件里的。在`archive_command`中，任何`%p`都被要歸檔文件的絕對路徑代替，而任何`%f`只是被文件名代替。如果你需要在命令里嵌入一個真正的`%`字符，那么必須雙寫(`%%`)。最簡單的有用命令類似下面這樣： ``` 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`目錄。這個只是一個例子，并非我們建議的方法， `%p`和`%f`參數被取代之后，實際執行的命令看起來這樣： ``` test ! -f /mnt/server/archivedir/00000001000000A900000065 && cp pg_xlog/00000001000000A900000065 /mnt/server/archivedir/00000001000000A900000065 ``` 為每一個歸檔的新文件產生類似的命令。歸檔命令將在運行PostgreSQL服務器的同一個用戶的權限下執行。因此被歸檔的WAL文件實際上包含你的數據庫里的所有東西，所以你應該確保自己的歸檔數據不會被別人窺探；比如，歸檔到一個沒有組或者全局讀權限的目錄里。有一點很重要：當且僅當歸檔命令成功時，它才返回零。在得到一個零值結果之后，PostgreSQL將假設該WAL段文件已經成功歸檔，因此它稍后將被刪除或者被新的數據覆蓋。但是，一個非零值告訴PostgreSQL該文件沒有被歸檔；因此它會周期性的重試直到成功。歸檔命令通常應該設計成拒絕覆蓋已經存在的歸檔文件。這是一個非常重要的安全特性，可以在管理員操作失誤 (比如把兩個不同的服務器的輸出發送到同一個歸檔目錄)的時候保持你的歸檔的完整性我們建議你首先要測試你準備使用的歸檔命令，以保證它實際上不會覆蓋現有的文件，并且_在這種情況下它返回非零狀態_。上邊Unix例子中的命令包含單獨的`測試`步驟。在一些Unix平臺上，`cp` 有可以使用的開關比如`-i`可以做同樣的簡單的事情。但是你不應該依靠這些而不驗證返回的正確退出狀態。（尤其是，當使用`-i`并且已經存在目標文件時，GNU `cp`將返回狀態零，這_不是_期望的操作。）在設計你的歸檔環境的時候，請考慮一下如果歸檔命令不停失敗會發生什么情況，因為有些方面要求操作者的干涉，或者是歸檔空間不夠了。比如，如果你往磁帶機上寫，但是沒有自動換帶機，那么就有可能發生這種情況；如果磁帶滿了，那就除非換磁帶，否則啥事也做不了。你應該確保任何錯誤條件或者要求操作員干涉的錯誤都會正確報告，這樣才能迅速解決這些問題。否則`pg_xlog/`目錄會不停地填充WAL段文件，直到問題解決。（如果文件系統由`pg_xlog/`填充，PostgreSQL將執行 PANIC關機。沒有提交的事務將丟失，但是數據庫將保持未連接直到你釋放一些空間）。歸檔命令的速度并不要緊，只要它能跟上你的服務器生成WAL數據的平均速度即可。即使歸檔進程落在了后面一點，正常的操作也會繼續進行。如果歸檔進程慢很多，就會增加災難發生時的數據丟失量。同時也意味著`pg_xlog/` 目錄包含大量未歸檔的日志段文件，并且可能最后超出了磁盤空間。我們建議你監控歸檔進程，確保它是按照你的意識運轉的。在寫自己的歸檔命令的時候，你應該假設被歸檔的文件最多 64個字符長并且可以包含ASCII字母、數字、點的任意組合。我們不必要記住原始的全路徑(`%p`)，但是有必要記住文件名(`%f`。請注意盡管WAL歸檔允許你恢復任何對PostgreSQL數據庫的修改，在最初的基礎備份之后，它還是不會恢復對配置文件的修改 (`postgresql.conf`, `pg_hba.conf`和 `pg_ident.conf`)，因為這些文件都是手工編輯的，而不是通過SQL操作來編輯的。所以你可能會需要把你的配置文件放在一個日常文件系統備份過程即可處理到的地方。參閱[Section 18.2](#calibre_link-1241)獲取如何重定位配置文件的知識。因為歸檔命令僅在已經完成的WAL段上調用，因此，如果你的服務器只產生很小的WAL流量或段之間的間隔很長，那么在事務完成之后與其被安全歸檔之間就會存在很長的延時。為了限制未歸檔數據的最長期限，可以設置[archive_timeout](#calibre_link-468)強制服務器在切換 WAL段之間的時間間隔。需要注意的是，由于強制切換而提早結束的已歸檔文件的大小與完整的歸檔文件相同。因此將`archive_timeout`設為一個很小的值是不明智的— 它將很快耗盡歸檔空間。將`archive_timeout`設置為60秒左右通常是比較合理的。同樣，如果你想確保剛剛完成的事務被立即歸檔，那么也可以通過`pg_switch_xlog`手動強制切換段文件。其它與WAL管理相關的工具函數在[Table 9-60](#calibre_link-1642)中列出。當`wal_level`是`minimal`的時候，一些SQL命令進行優化以避免WAL日志，正如[Section 14.4.7](#calibre_link-1197)所描述的。如果在這些語句之一執行過程中打開歸檔或者流復制，WAL不包含歸檔恢復的足夠信息。 (崩潰恢復不受影響)，出于這些原因，在服務器開始改變`wal_level`。然而，重新加載配置文件時改變`archive_command`。如果你希望暫時停止歸檔，這樣做的一個方法是設置`archive_command`為空字符串 (`''`)。這將導致WAL文件在`pg_xlog/`中積累直到`archive_command`重新建立。 ## 24.3.2\. 進行一次基礎備份執行基礎備份最簡單方式是使用[pg_basebackup](#calibre_link-471)工具，它使用普通文件或者tar歸檔創建基礎備份。如果比[pg_basebackup](#calibre_link-471)提供更多的靈活性，你也可以使用低水平API（參閱[Section 24.3.3](#calibre_link-1633)）創建基礎備份。不必擔心基礎備份需要大量時間。然而，如果你正常運行禁用了`full_page_writes`的服務器，當運行備份時，你可能注意到性能方面，因為`full_page_writes`有效強加在備份方式中。要使用這個備份，你需要保存所有備份開始以及之后的WAL段文件。為了幫助你實現這個任務，基礎備份過程創建一個_備份歷史文件_，它馬上存儲到WAL歸檔區域。這個文件的名字是以你在使用文件系統備份的時候需要的第一個 WAL段文件的名字命名的。比如，如果開始 WAL 文件是`0000000100001234000055CD`，那么備份歷史文件將命名為類似`0000000100001234000055CD.007C9330.backup`這樣的東西。這個文件名的第二部分表示在該WAL文件里面的準確位置，通常可以被忽略。一旦你安全地把這些日志段文件歸了檔，那么你就可以刪除所有那些數值名字在這個文件前面的歸檔的WAL段。文件系統備份不再需要它們了。當然，你應當保留幾套備份以絕對確保可以恢復先前的數據。備份歷史文件只是一個小的文本文件。它包含你給予[pg_basebackup](#calibre_link-471)的標簽字符串，以及備份的起始時間和終止時間。如果你使用這個標簽來表示轉儲文件放在哪里，則在需要的時候，歸檔的歷史文件就足夠告訴你轉儲文件存放在哪里了。因為你必須保留直到最后一次基礎備份的所有歸檔的WAL文件，那么兩次基礎備份之間的間隔通常是根據你想在歸檔WAL 文件上花多少存儲空間來定的。你還應該考慮你準備在恢復上花多少時間。如果需要恢復的話— 系統將需要重放所有那些段，而如果最后一次基礎備份以來，時間已經很長了，那么那些動作可能會花掉好些時間。 ## 24.3.3\. 使用低級別API進行基礎備份使用包含多個步驟的低水平API而不是[pg_basebackup](#calibre_link-471)方法，但是相對簡單。在序列中執行這些步驟非常重要，并且在進行下一步之前需要驗證當前步成功。 1. 確保WAL歸檔打開并且可以運轉。 2. 以數據庫超級用戶身份連接到數據庫，發出命令: ``` SELECT pg_start_backup('label'); ``` 這里的`label`是任意你想使用的這次備份操作的唯一標識 (一個好習慣是使用備份轉儲文件的放置地全路徑)。 `pg_start_backup`用備份信息在集群目錄里創建一個_備份標簽_文件`backup_label`。包含起始時間和標簽字符串。該文件對于備份完整性是非常重要的，你需要從中恢復。至于你連接到集群中的那個數據庫沒什么關系。你可以忽略函數返回的結果；但是如果它報告錯誤，那么在繼續之前先處理它。默認情況下，`pg_start_backup`可能需要很長的時間才能完成。這是因為它會執行一個檢查點，并且I/O所需的檢查點會被分散在一個顯著的時間段，默認情況下，使用一半你的相互檢查點間隔（參見配置參數 [checkpoint_completion_target](#calibre_link-1643)）。這是你想要的，因為它最大限度地減少對查詢處理的影響。如果你想盡快開始備份，使用： ``` SELECT pg_start_backup('label', true); ``` 這強制檢查點盡快完成。 3. 執行備份，使用任何方便的文件系統工具，比如tar或者cpio （而不是pg_dump或者 pg_dumpall）。這些操作過程中既不需要關閉數據庫，也不需要關閉數據庫的操作。 4. 再次以數據庫超級用戶身份連接數據庫，然后發出命令： ``` SELECT pg_stop_backup(); ``` 這將中止備份模式并自動切換到下一個WAL段。自動切換是為了在備份間隔中寫入的最后一個WAL 段文件可以立即為下次備份作好準備。 5. 只要在備份過程中使用的WAL段文件備份完畢，你的備份工作就完成了。通過`pg_stop_backup`的結果標識的文件是需要形成一套完整備份文件的最后一段。如果`archive_mode`已啟用， `pg_stop_backup`不返回，直到最后段被歸檔。這些文件的歸檔是自動發生的，因為已配置`archive_command`。在大多數情況下，這將迅速發生，但建議您監控您的存檔系統以確保沒有延遲。如果歸檔進程已經落后，因為存檔命令失敗，它會繼續重試直到存檔成功，備份完成。如果您希望在執行`pg_stop_backup`時有時間限制，則設定適當的 `statement_timeout`值。一些文件系統備份工具發出警告或錯誤，如果這些文件他們正試圖復制副本處理的變化。當執行活動數據庫的基礎備份，這種情況是正常的并且不發生錯誤。但是，你需要確保你能辨別這種從實際錯誤中的投訴。例如，rsync某些版本返回一個"消失源文件"單獨的退出代碼，你可以寫一個驅動程序腳本接受這個退出代碼作為一個非錯誤情況。此外，當tar復制它，如果一個文件被截斷時， GNU tar某些版本返回一個錯誤代碼區分致命的錯誤，幸運的是，如果文件在備份過程中改變，GNU tar版本1.16和后期版本退出1，其他錯誤則返回2。對于GNU tar版本1.23版和后期版本，您可以使用警告選項的`--warning=no-file-changed --warning=no-file-removed`隱藏相關的警告信息。要保證你的備份轉儲包括所有數據庫集群目錄里的文件 (比如`/usr/local/pgsql/data`)。如果你在使用并未放置在這個目錄里的表空間，也要小心地包含它們，并且要確保你的備份轉儲歸檔符號連接是符號連接，否則，恢復會把你的表空間搞亂。不過，你可以在備份轉儲文件里省略集群目錄下的`pg_xlog/`子目錄。這個略微復雜些的動作是值得的，因為它減少了恢復時候的錯誤。如果`pg_xlog/`是一個指向集群目錄之外的符號連接，那么這件事情很容易處理，出于性能考慮的時候經常這么做。你可能還想排除`postmaster.pid`和`postmaster.opts`，記錄有關運行postmaster的信息，而不談postmaster。它最終將使用這個備份。（這些文件可以混淆pg_ctl）。還有一件事值得一提，那就是`pg_start_backup`函數在數據庫集群目錄里創建了一個叫`backup_label`的文件，它被`pg_stop_backup`刪除。這個文件當然也會作為備份轉儲文件的一部分歸檔。這個備份標簽文件包含你給予`pg_start_backup`的標簽字符串，以及`pg_start_backup`運行的時刻，以及起始WAL文件的名字。如果有混淆，那么我們可以看看備份轉儲文件里面然后判斷轉儲文件來自那個備份會話。然而，這些文件不僅僅是你的信息，它的存在和內容對系統的恢復過程的正確操作是關鍵的。我們還可以在服務器停止的時候制作一個備份轉儲。在這種條件下，很明顯你不能使用`pg_start_backup` 或者`pg_stop_backup`，并且因此你必須靠自己的手段來跟蹤備份轉儲文件都是那些，以及相關的WAL文件最遠走到哪里。通常使用上面的在線備份步驟更好些。 ## 24.3.4\. 從在線備份中恢復好，最糟糕的事情發生了，現在你需要從備份中恢復。下面是步驟： 1. 停止服務器，如果它還在運行的話。 2. 如果你還有足夠的空間，把整個集群數據目錄和所有表空間拷貝到一個臨時位置，以防萬一你之后還需要它們。請注意這個預防措施要求你在系統里有足夠的剩余空間來現有庫的保持兩份拷貝。如果你沒有足夠的空間，那么你至少需要把集群數據目錄的`pg_xlog`子目錄的內容拷貝到安全的地方，因為它們可能包含系統宕掉的時候還沒有歸檔的日志。 3. 然后清理掉所有在該集群數據目錄里的現存文件，以及所有你使用的表空間里根目錄下的現存文件。 4. 從你的備份轉儲中恢復數據庫文件。要小心用正確的所有者(數據庫系統用戶，而不是`root`!)和權限恢復它們。如果你使用了表空間，你可能需要核實在`pg_tblspc/`里的符號連接都得到正確恢復。 5. 刪除任何目前還在`pg_xlog/`里的文件；這些文件來自備份轉儲，因此它們可能比目前的老。如果你就根本沒有歸檔`pg_xlog/`，那么重建之，它具有合適的權限，如果你已經像從前那樣建立了，小心確保你重新建立它作為符號鏈接， 6. 如果你有在步驟 2 里面保存的WAL段文件，那么把它們拷貝到`pg_xlog/`。最好是拷貝它們，而不是把它們移動回來，這樣即使發生了糟糕的事情，你需要重啟的時候，你也依然擁有未修改的文件。 7. 在集群數據目錄里創建一個恢復命令文件`recovery.conf`(參閱[Chapter 26](#calibre_link-1283))。你可能還需要臨時修改`pg_hba.conf`以避免普通用戶連接，直到你確信恢復已經正常了為止。 8. 啟動服務器。服務器將進入恢復模式并且繼續讀取它需要的 WAL 歸檔文件。在遇見外部錯誤的應當中止恢復過程，然后重新啟動服務器，這樣它會自動繼續進行恢復工作。在恢復過程完成后，服務器將把`recovery.conf`改名為`recovery.done` 以避免不小心因后面的崩潰再次進入恢復模式，然后開始正常的數據庫操作。 9. 檢查數據庫的內容以確保你已經恢復到你期望的位置。如果還沒有，回到步驟1。如果全部正常，則恢復`pg_hba.conf` 成正常狀態以允許普通用戶登錄。所有這些操作的關鍵是設置一個恢復命令文件，這個文件描述你希望如何恢復以及恢復應該走到哪里。你可以使用`recovery.conf.sample`(通常安裝在安裝目錄的`share/` 子目錄里)作為原型。你必須在`recovery.conf`里面聲明的一個東西是`restore_command`，它告訴系統如何拿回歸檔的WAL文件段。類似`archive_command`，這個是一個腳本命令字符串。它可以包含`%f`，這個變量會被需要的日志文件名替換，以及`%p`，它會被要拷貝去的日志文件的絕對路徑代替。如果需要在命令里替換真正的`%`字符，那么就雙寫(`%%`)。最簡單的有用命令是類似下面的東西： ``` restore_command = 'cp /mnt/server/archivedir/%f %p' ``` 這個命令將把以前歸檔的WAL段從`/mnt/server/archivedir`目錄拷貝過來。你當然可以使用某些更復雜的東西，甚至是一個要求操作者掛載合適的磁帶的shell腳本。重要的一點是：該命令在失敗的時候返回非零值。如果日志文件沒有出現在規檔中，那么該系統_將要_詢問該命令；在問到的時候，它必須返回非零。這個不是錯誤條件。并不是所有需要的文件都是WAL分段文件；你應該希望請求`.backup`或者 `.history`的后綴文件。還要注意`%p`路徑的基礎名將和`%f`不一樣；不要認為它們是可以互換的。在歸檔中沒有的WAL分段將在`pg_xlog/`中；這樣就允許使用最近沒有歸檔的段。但是在歸檔中的段將比`pg_xlog/`中的優先。通常，恢復將處理所有可用的 WAL 段，因此將把數據庫恢復到當前時間(或者是在所給出的可用 WAL 段數的情況下，我們能走到的最近的地方)。因此，一個正常恢復以"文件沒找到"信息結束，錯誤信息的確切文本依賴于`restore_command` 你的選擇。你也可能在類似于`00000001.history`文件恢復開頭看到錯誤信息。這也是正常的，并不表明簡單恢復情況下的問題。參閱[Section 24.3.5](#calibre_link-1635) 獲取更多信息。但是如果你想恢復到某些以前的時刻點(比如，在菜鳥DBA刪除你的主要事務表之前)，那么只需要在`recovery.conf`里聲明要求的停止點。你可以通過日期/時間來聲明，也可以通過特定事務ID的結束來聲明這個停止點，我們叫做"恢復目標"。目前，只有日期/時間和稱為恢復點選項比較有用，因為我們沒有工具來幫助你精確地標識應該使用哪個事務ID。 > **Note:** 請注意停止點必須在備份的終止時間之后(也就是`pg_stop_backup`的時間)。你無法使用一個基礎備份恢復到備份正在進行中的某個時刻。要想恢復到該時刻，你必須回到你以前的基礎備份，然后從那個位置向前滾動。如果在恢復過程中發現在 WAL 數據中存在錯誤，那么恢復將在錯誤的地方停止，并且不會啟動服務器。在這種情況下，可以指定一個位于錯誤點之前的"恢復目標"，然后從起始點開始重新運行恢復進程，這樣恢復就可以正常完成。如果由于外部原因(系統崩潰、無法讀取 WAL 歸檔)導致恢復失敗，那么可以簡單的重新啟動恢復過程即可，它將從上次失敗的地方繼續。重新啟動恢復過程與檢查點的操作非常類似：服務器周期性的強制將其狀態記錄到磁盤上并更新`pg_control`文件以標識已經處理的 WAL 數據不需要被再次掃描。 ## 24.3.5\. 時間線能夠把數據庫恢復到以前的某個時間點的能力導致了一些類似科幻小說里的時間跟蹤和并行宇宙這樣的復雜情況。在數據庫最初的歷史里，可能你在周二下午5:15刪除掉了一個非常關鍵的表。但是沒有意識到你自己的錯誤直到周三中午。有條不紊地拿出備份，恢復到周二晚上5:14的即時備份。在_這個_數據庫宇宙的歷史里，你從來沒有刪除過那個表。但是假如你后來認識到這么干是錯誤的，并且想回到最初的歷史中的稍后的點。你沒法這么干，因為在數據庫運行的時候，它覆蓋了一些WAL段文件的序列，這些序列就在你希望回去的區間里。因此你的確需要區分在你從那些原始數據庫歷史生成的WAL中完成即時恢復之后生成的WAL序列。為了處理這些問題，PostgreSQL有個叫_時間線_的概念。當完成一個歸檔恢復時，那么就創建一個新的時間線，以表示在該次恢復之后生成的 WAL 記錄序列。時間線ID號是WAL段文件名的一部分，因此新的時間線并不會覆蓋以前的時間線生成的 WAL 數據。實際上我們可以歸檔許多不同的時間線。雖然這些看起來像沒用的特性，但它卻可能常常是救命稻草。考慮一下你并不很確信應該恢復到那個時刻的情況，這個時候你不得不做好幾次試驗性即時恢復然后從中找到舊歷史中最好的分支。如果沒有時間線，那么這個過程可能很快就會導致無法管理的混亂。有了時間線，你可以恢復到_任意_以前的狀態，包括恢復到你后來放棄的時間線分支的狀態。每當創建一個新的時間線的時候，PostgreSQL都創建一個"時間線歷史"文件，它顯示自己從哪個時間線分出來，以及何時分出來的。這些歷史文件是在從包含多個時間線的歸檔中進行恢復時，允許系統選取正確 WAL 段文件的必要文件。因此，它們像 WAL 段文件一樣歸檔到 WAL 歸檔里。歷史文件只是很小的文本文件(不像段文件很大)，所以獨立地保存他們代價很小，也值得做。如果你喜歡，你可以在歷史文件里加入注釋，記錄自己為什么設置這個時間線以及如何設置的等信息。這樣的注釋會在你有厚厚一堆不同的時間線需要選擇和分析的時候特別有價值。恢復的缺省的行為是沿著與基礎備份的同一個時間線恢復。如果你想恢復到某些子時間線，也就是，你想回到某些本身就是在開始恢復之后發生的狀態。你需要在`recovery.conf`里聲明目標時間線ID。你無法恢復到比基礎備份更早的時間線分支。 ## 24.3.6\. 技巧和例子給出了配置連續歸檔的一些技巧。 ### 24.3.6.1\. 單機熱備可以使用PostgreSQL備份工具產生單機熱備。這些都是不能使用時間點恢復的備份，往往備份和恢復比pg_dump轉儲速度更快。（他們也比pg_dump轉儲更大，因此在某些情況下速度優勢可能是否定的）。作為基礎備份，最簡單的方式是使用[pg_basebackup](#calibre_link-471)工具產生單機熱備份。當調用它時，如果你有`-X`參數，那么所有需要使用備份的事務日志將包含在自動備份中，并且不需要特殊操作恢復備份。如果在復制備份文件中需要更大的靈活性，較低的水平過程可更好用于單機熱備份。為了準備低水平單機熱備份，設置`wal_level`到 `archive` (或者`hot_standby`), `archive_mode`為 `on`，并且只有當_開關文件_存在時，建立`archive_command`執行存檔。例如： ``` archive_command = 'test ! -f /var/lib/pgsql/backup_in_progress || (test ! -f /var/lib/pgsql/archive/%f && cp %p /var/lib/pgsql/archive/%f)' ``` 當`/var/lib/pgsql/backup_in_progress`存在時，這個命令將執行歸檔。否則默默返回零退出狀態（允許PostgreSQL回收不需要的WAL文件）。有了這個準備，備份可以使用如下腳本： ``` 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/ ``` 開關文件`/var/lib/pgsql/backup_in_progress`是第一次創建，使已完成的WAL文件的歸檔發生。在備份后刪除開關文件。歸檔的WAL文件然后添加至備份，使兩個基礎備份和所有必需的WAL文件是相同的tar文件的一部分。請記住，錯誤處理添加到您的備份腳本中。 ### 24.3.6.2\. 壓縮歸檔日志如果歸檔存儲大小是一個問題，你可以使用gzip 壓縮歸檔文件： ``` archive_command = 'gzip < %p > /var/lib/pgsql/archive/%f' ``` 在恢復過程中你需要使用gunzip： ``` restore_command = 'gunzip < /mnt/server/archivedir/%f > %p' ``` ### 24.3.6.3\. `archive_command`腳本許多人選擇使用腳本定義他們的`archive_command`，因此`postgresql.conf`記錄看起來很簡單： ``` archive_command = 'local_backup_script.sh "%p" "%f"' ``` 任何你想在歸檔過程中使用不只是獨立命令時。使用一個單獨的腳本文件是可取的，這允許所有的復雜性在腳本中管理，這可以使用流行的腳本語言書寫，如bash或者perl。可能在腳本中解決的所需例子包含： * 拷貝數據到安全異地數據存儲 * 計量WAL文件以致于他們每三個小時改變，而不是一個時間。 * 其他備份和恢復軟件接口 * 監控軟件報告錯誤接口 > **Tip:** 當使用`archive_command`腳本時，期望啟動[logging_collector](#calibre_link-1443)。來自腳本寫入stderr中的任何消息將出現在數據庫服務器日志中，如果失敗，則允許簡單地診斷復雜配置。 ## 24.3.7\. 警告目前，在線備份技術還有幾個局限。它們可能在將來的版本中修補： * 在Hash索引上的操作目前沒有使用WAL記錄日志，所以重放就不會更新這些索引類型。這將意味著任何新的插入被索引忽略，已更新行顯然會消失，并且已刪除行將仍然保留指針。換句話說，如果你修改了帶有hash索引的表，那么你將獲得備用服務器上不正確的查詢結果。當完成恢復時，建議是在完成恢復操作之后手工[REINDEX](#calibre_link-614)每個這樣的索引。 * 如果在進行數據庫備份的時候發出一個[CREATE DATABASE](#calibre_link-111)命令，然后在這個過程中`CREATE DATABASE`命令拷貝的模板數據庫被修改了，那么用這個備份進行恢復的數據庫很有可能導致這些修改也傳播到新創建的數據庫中去。這個行為當然是不愿意看到的。為了避免這個風險，最好在進行數據庫備份的時候不要修改任何模板數據庫。 * [CREATE TABLESPACE](#calibre_link-99)命令是用文本的絕對路徑記錄WAL日志的，因此會以相同的絕對路徑重新創建。如果日志是在另外一臺機器上重放，那么這個行為可能不是我們想要的。即使在同一臺機器，但是在一個新的數據目錄里重放日志，都很可能是危險的：重放仍將會覆蓋原來的表空間的內容。為了避免這類的潛在問題，最好的方法是在創建或者刪除表空間之后進行一次新的基礎備份。還要注意，缺省的WAL格式體積相當大，因為它包含許多磁盤頁快照。這些磁盤頁快照是設計來支持崩潰恢復的，因為我們可能需要修補部分寫入的磁盤頁。根據你的系統硬件和軟件的不同，這種部分寫入的危險可能是微乎其微的。這種情況下，你可以通過使用[full_page_writes](#calibre_link-1135)關閉磁盤頁面快照，從而大大減少歸檔日志的總尺寸(在你這么做之前，閱讀[Chapter 29](#calibre_link-79)里面的注意和警告)。關閉頁面快照并不阻止日志使用PITR操作。一個將來需要開發的功能是在`full_page_writes`打開的時候，通過刪除不需要的磁盤頁拷貝來壓縮歸檔的 WAL 數據。同時，管理員可以通過盡量合理地增加檢查點的時間間隔來減少包含在WAL里的頁面快照。