PostgreSQL Replication之第三章 理解即時恢複（4）

標籤：

3.4 重放交易記錄

一旦我們建立了一個我們自己的初始基礎備份，我們可以收集資料庫建立的XLOG。當時間到時，我們可以使用所有這些XLOG 檔案並執行我們所期望的恢複進程。這就像本節描述的一樣工作。

執行基本恢複

在PostgreSQL中，整個恢複過程有一個稱為recover.conf的檔案管理，其主要駐留在基礎備份的主目錄中。在啟動的時候被讀取，並告訴資料庫伺服器到哪裡可以找到XLOG歸檔，什麼時候終止重放，等等。

為了讓您開始恢複，我們決定為執行一個基本的備份過程包含一個簡單的recovery.conf樣本檔案：

restore_command = ‘cp /archive/%f %p‘

recovery_target_time = ‘2013-10-10 13:43:12‘

restore_command 基本上是與您之前見過的archive_command命令相對應的命令。archive_command應該將資料放入歸檔，restore_command 應該使用一個一個檔案為恢複執行個體提供資料。再次，它是一個簡單的提供一個又一個XLOG塊的shell命令或者一個簡單的shell指令碼。您在這裡的選項僅僅受限於想象力；PostgreSQL要做的是檢查您寫的代碼的返回碼，並通過您的指令碼提供的資料。

就像在postgresql.conf中，我們使用%p 和%f作為預留位置；這兩個預留位置的意思和之前的完全一樣。

要告訴系統什麼時候停止恢複，我們可以設定recovery_target_time。該變數是可選的。如果它沒有被指定，PostgreSQL 將一直恢複，直到它運行完 XLOG。在許多情況下，簡單地消耗整個XLOG是一個非常可取的過程；如果有東西出現故障，您要恢複儘可能多的資料。但是，並非總是如此。如果您要使PostgreSQL在一個特定的時間帶您停止恢複，您必須要把關鍵的日誌放到這裡。這裡至關重要的部分其實是，要知道您要多大程度地重放XLOG；在一個實際的工作情境，這已經被證明是要回答的很棘手的問題。

[如果您在未來碰巧有一個recovery_target_time，不要擔心，PostgreSQL將在您的XLOG中最近的可用事務處開始，並簡單地停止恢複。資料庫執行個體將仍然是一致的，並準備採取行動。您不能終止PostgreSQL，但是，在資料丟失的情況您可能會終止您的應用程式，因為缺少XLOG。]

在啟動 PostgreSQL之前，您必須對包含基礎備份的目錄執行 chmod 700，否則，PostgreSQL將輸出錯誤：

iMac:target_directoryhs$ pg_ctl -D /target_directory\

start

server starting

FATAL: data directory "/target_directory" has group or world access

DETAIL: Permissions should be u=rwx (0700).

這種額外的安全檢查應該確保您的資料目錄不能被某些使用者意外讀取。因此，從安全的角度來考慮，一個明確的許可權更改絕對是一個優勢(有備無患)。

既然所有的工作都已經就緒，我們可以通過啟動PostgreSQL來啟動重放進程：

iMac:target_directoryhs$ pg_ctl –D /target_directory \

start

server starting

LOG: database system was interrupted; last known up at 2013-03-10

18:04:29 CET

LOG: creating missing WAL directory "pg_xlog/archive_status"

LOG: starting point-in-time recovery to 2013-10-10 13:43:12+02

LOG: restored log file "000000010000000000000006" from archive

LOG: redo starts at 0/6000020

LOG: consistent recovery state reached at 0/60000B8

LOG: restored log file "000000010000000000000007" from archive

LOG: restored log file "000000010000000000000008" from archive

LOG: restored log file "000000010000000000000009" from archive

LOG: restored log file "00000001000000000000000A" from archive

cp: /tmp/archive/00000001000000000000000B: No such file or

directory

LOG: could not open file "pg_xlog/00000001000000000000000B" (log

file 0, segment 11): No such file or directory

LOG: redo done at 0/AD5CE40

LOG: last completed transaction was at log time 2013-03-10

18:05:33.852992+01

LOG: restored log file "00000001000000000000000A" from archive

cp: /tmp/archive/00000002.history: No such file or directory

LOG: selected new timeline ID: 2

cp: /tmp/archive/00000001.history: No such file or directory

LOG: archive recovery complete

LOG: database system is ready to accept connections

LOG: autovacuum launcher started

資料庫產生的日誌的量告訴我們，我們需要知道的關於恢複進程的所有事情，這是絕對值得詳細調查的資訊。

第一行表明，PostgreSQL已經發現它已經被終止了，並且它必須重新啟動。從資料庫執行個體的角度來看，基礎備份看起來或多或少像一個立即需要通過重放XLOG來照顧的崩潰；這正是我們想要的。

接下來幾行(恢複記錄檔…)表明，我們正在一個一個地重放由基礎備份建立的XLOG檔案。值得一提的是，重放進程於第六個檔案處開始啟動。基礎備份知道從哪裡啟動，因此，PostgreSQL將自動尋找合適的XLOG檔案。

PostgreSQL到達第六個檔案(consistent recovery state reached at 0/60000B8)之後顯示的資訊是非常之重要的。PostgreSQL表明，它已經到達一致狀態。這是很重要的。其原因是，基礎備份中的資料檔案實際上被明確中斷(這裡請參閱我們前面關於XLOG的章節)，但是資料檔案不是被損壞的無法修複。只要我們有足夠多的XLOG來恢複，我們就沒有問題。如果您不能達到一致的狀態，您的資料庫執行個體將不可用，在不提供額外的XLOG的情況下，您的恢複不能工作。

[實事求是的講，不能達到一致的狀態通常表示您的歸檔進程和您系統設定有問題。到現在為止，如果一切事情都正常工作，沒有理由不達到一致狀態。] 

一旦我們達到一致的狀態，一個又一個的檔案將被成功重放，直到系統最終尋找00000001000000000000000B檔案。問題是，該檔案沒有被來源資料庫執行個體建立。邏輯上，將會彈出一個錯誤。

[沒有找到最後一個檔案是完全正常的；如果在到達XLOG流的末尾之前，recovery_target_time不讓PostgreSQL停止恢複這種類型的錯誤在意料之中的。不要擔心，您的系統其實很好。在錯誤訊息之前，您已經成功地重放了出現的檔案的所有東西。]

一旦所有的XLOG都被消耗，並且在前面已經討論了錯誤訊息，PostgreSQL報告最後一個能夠或者應該重放的事務，並啟動。現在您有一個完全的恢複資料庫執行個體，您可以立即串連到資料庫。一旦恢複結束，PostgreSQL將把recovery.conf重新命名為recovery.done，以確保當稍後某個時間點重新啟動新的執行個體時，沒有任何傷害。

在XLOG中更先進的定位

到現在為止，我們已經使用16MB的交易記錄塊恢複了一個資料庫到最新可用的時間。我們也看到，您可以定義期望的恢復戳。但現在的問題是：您怎麼知道到哪個時間點來執行恢複？試想，某人在白天刪除了一個表。要是您不能輕易確定恢復戳會怎麼樣呢？要是您要恢複到一個特定的事務將會怎樣呢？

recovery.conf 中有所有您所需要。如果您要重放，直到一個特定的事務，您可以參考 recovery_target_xid.。只需指定您所需要的事務並配置 recovery_target_inclusive 來包括這個非常特別的事務或者不配置。如前面所提到的，技術地使用這個設定是相當容易的，目前為止，找到正確的位置來重放是不容易的。

在典型的設定中，找到一個合理的終止恢複的點的最好的方法是使用pause_at_recovery_target。如果它被設定為ture，達到復原點時，PostgreSQL將不會自動轉變為生產執行個體。相反，他將等待資料庫管理員的指令。如果您不知道要重放到什麼位置，這是非常有用的。您可以重放，登入，看看到資料庫的哪個位置，更改為下一個目標時間，並不斷以小步長來重放。

[您必須在postgresql.conf中設定hot_standby = on 以允許在恢複中讀取。]

在通過調用一個簡單的SQL語句：SELECT pg_xlog_replay_resume()來終止PostgreSQL之後回到恢複。它將使執行個體移動到您在recovery.conf中設定的下一個位置。一旦您找到了正確的位置，您可以設定pause_at_recovery_target 為false，並調用pg_xlog_replay_resume。或者，您可以簡單地使用pg_ctl –D ... promote來停止恢複，並使執行個體工作。

這個解釋太複雜了嗎 ？讓我們把它列成一個清單：

• 把 restore_command 添加到 recovery.conf 檔案。

• 把 recovery_target_time 添加到 recovery.conf 檔案。

•在 recovery.conf 檔案中，設定 pause_at_recovery_target 為 true。

•在 postgresql.conf 檔案中，設定 hot_standby 為 on。

• 啟動恢複執行個體。

• 一旦達到了一致的狀態，並且停止恢複，就立即串連到執行個體。

• 檢查您是否已經處於您要去的地方了。

• 如果您不在:

° 更改 recovery_target_time。

° 運行SELECT pg_xlog_replay_resume()。

° 如果需要的話，在檢查一遍並重複這段。

[請記住，一旦恢複完成，一旦PostgreSQL作為一個正常的資料庫執行個體啟動，稍後(如 9.2)就不能重放XLOG。不採用這個過程，您當然可以直接使用檔案系統快照。檔案系統快照將始終與PostgreSQL一起工作，因為當您重新啟動一個快照資料庫執行個體，它會簡單地認為，它 之前已經崩潰，並且正常恢複。]

中途清理XLOG                         

一旦您配置了歸檔，您必須儲存由原始伺服器建立的XLOG。從邏輯上講，這是永遠都不可能發生的。有些時候，您必須擺脫這些XLOG；對您的檔案來說，有一個健全和可持續的清理策略是必須的。

但是，請記住，您必須保持足夠的XLOG以便您總是可以從最新的基礎備份執行恢複。但是，如果您確定，某個特定的基礎備份不再需要了，您可以安全地清理掉所有的比您要保持的基礎備份的XLOG還要早的XLOG。

管理員如何找出要刪除什嗎？最簡單的方法是看看您的存檔目錄：

000000010000000000000005

000000010000000000000006

000000010000000000000006.00000020.backup

000000010000000000000007

000000010000000000000008

在列表的中間檢查檔案名稱。備份檔案已經被基礎備份建立了。它包含了一些關於建立基礎備份的方式，並告訴系統在哪裡繼續重放XLOG。如果備份檔案屬於您需要的最早的基礎備份，您可以安全地清除所有低於數字6的XLOG；在這種情況下，5號檔案可以被安全地刪除。

在我們的例子中，000000010000000000000006.00000020.backup 包含了下面的資訊：

START WAL LOCATION: 0/6000020 (file 000000010000000000000006)

STOP WAL LOCATION: 0/60000E0 (file 000000010000000000000006)

CHECKPOINT LOCATION: 0/6000058

BACKUP METHOD: streamed

BACKUP FROM: master

START TIME: 2013-03-10 18:04:29 CET

LABEL: pg_basebackup base backup

STOP TIME: 2013-03-10 18:04:30 CET 

.backup 檔案也將為您提供相關的資訊，如基礎備份建立的時間。它是普通檔案，因此，對普通使用者來說，閱讀這些資訊應該很容易。作為一種在某一點刪除所有XLOG 檔案的選擇，在重放它們期間清除它們也是可能的。方法之一是在您的restore_command中隱藏一個rm 命令。雖然在技術上是可能的，但這樣做並不一定是明智的(如果您想再次恢複怎麼辦呢？)。

同時，您也可以在您的recovery.conf檔案中添加recovery_end_command命令。recovery_end_command的目標是允許您只要恢複結束，就自動觸發一些行動。再次，PostgreSQL將調用一個指令碼做您要做的事。當資料庫聲明它自己為主庫時，您可以很容易地使用這個設定來清理較早的XLOG。

切換XLOG檔案

如果您要做一個基於XLOG檔案的恢複，您已經看到了，每個XLOG將被存檔為16MB。如果您不設法創造16MB的變化會發生什麼呢？如果您是一個小超市，這隻會產生每天50筆交易。最後，您的系統將永遠不可能填滿16MB。

然而，如果您的系統崩潰，潛在的資料丟失可以看作是在您最後沒有完成的XLOG檔案的資料量。也許這對您不夠好。

在來源資料庫中的一個postgresql.conf的設定可能對這個問題有協助。

archive_timeout 告訴PostgreSQL至少每X秒建立一個新的XLOG檔案。因此，如果您是這個小超市，您可以讓資料庫每天在您回家之前建立一個新的XLOG檔案。在這種情況下，您可以確定，當天的資料將安全地在您的備份裝置上。

手動使PostgreSQL切換到下一個XLOG檔案也是可能的。伺服器提供了一個稱為pg_switch_xlog()的過程來做這個工作：

test=# SELECT pg_switch_xlog();

pg_switch_xlog

----------------

0/17C0EF8

(1 row)

當一些重要的修補工作完成時或者您要確保一個特定的資料庫安全地存在於您的XLOG歸檔時，您可能會調用這個過程。

3.5總結

在本章中，您已經學習了即時恢複，這是一個恢複您的PostgreSQL資料庫到任何需啊喲的時間的的一種安全，簡單的方法。即時恢複將協助您實現較好的備份策略並且使您的設定更加健壯。

在下一章中，我們將擴充這個話題，並轉到非同步複製。您將學習如何使用PostgreSQL的交易記錄複製整個資料庫執行個體。

PostgreSQL Replication之第三章 理解即時恢複（4）