Postgresql - 使用 recovery.conf 恢復
我正在嘗試使用 recovery.conf 文件來恢復數據庫以進行時間點複製。
在 recovery.conf 文件中，我添加了一個恢復目標時間，如下所示。
recovery_target_time = '2011-06-16 04:10:00 IST'但是在日誌中，我可以看到它是否將時間提前了 3.5 小時到 07:40，並且嘗試在這段時間內進行實際恢復，而不是我在 recovery_target_time 中給出的時間。
2011-06-16 12:53:45 IST LOG: starting archive recovery 2011-06-16 12:53:45 IST LOG: restore_command = '/app/postgresinstall/bin/pg_standby -l /dbdata/archive %f %p %r' 2011-06-16 12:53:45 IST LOG: recovery_target_time = '2011-06-16 07:40:00+05:30' cp: cannot stat `/dbdata/archive/00000001.history': No such file or directory為什麼會有 3.5 小時的差異，我需要幫助來弄清楚在決定恢復目標時間時發生了什麼？
**更新：**這是來自數據庫的時間詳細資訊
postgres=# SELECT EXTRACT(timezone_hour FROM now()),EXTRACT(timezone_minute FROM now()); date_part | date_part -----------+----------- 5 | 30 (1 row) postgres=# select now(); now ---------------------------------- 2011-08-12 13:08:19.333068+05:30 (1 row) OS Date/Time: postgres@xxxxx:~$ date Fri Aug 12 13:10:19 IST 2011當我嘗試從同一伺服器和我的備份伺服器上的 WAL 檔案恢復時，我遇到了同樣的問題。此外，我可以在兩台伺服器上始終如一地重現此問題。
因此，如果我需要創建接近目前時間的備份，我會使用比目前時間晚 3.5 小時的 recovery_target_time 並使用 recovery.conf 啟動數據庫
免責聲明：我不是 PostgreSQL DBA，儘管我涉獵很多。
您可能需要在作業系統和 psql 中檢查您的時區。
在作業系統中執行這個：
[postgres@radarPG-db1 ~]$ date Fri Jun 17 12:55:37 EDT 2011在 psql 中，執行以下命令：
postgres=# SELECT EXTRACT(timezone_hour FROM now()),EXTRACT(timezone_minute FROM now()); date_part | date_part -----------+----------- -4 | 0 postgres=# select now(); now ------------------------------- 2011-06-17 12:54:39.195291-04很多時候，有些人忘記讓 postgres 將時區預設為作業系統的時區。如果 WAL 文件的內部時間戳也包含時區，則必須將 postgres 中設置的時區與 WAL 文件的時區對齊。
需要考慮的其他事項如下：
恢復的預設行為是沿進行基本備份時的目前時間線進行恢復。如果您想恢復到某個子時間線（即，您想返回到恢復嘗試後自身生成的某個狀態），您需要在“recovery.conf”中指定目標時間線 ID。您無法恢復到早於基本備份分支的時間線。
更新 2011-06-20 15:08 EDT
這直接來自線上文件。請仔細檢查一下，看看您是否遺漏了任何 WAL 文件。如果您在新伺服器上設置 WAL 文件等待的時間過長，postgres 可能在啟動時已將其刪除。您可能需要找到那些 WAL 文件。查看它們是否位於舊伺服器的 pg_xlog 文件夾中。
- 停止伺服器，如果它正在執行。
- 如果您有空間這樣做，請將整個集群數據目錄和任何表空間複製到一個臨時位置，以備日後需要它們時使用。請注意，此預防措施將要求您的系統上有足夠的可用空間來保存現有數據庫的兩個副本。如果你沒有足夠的空間，你至少需要複製集群數據目錄的 pg_xlog 子目錄的內容，因為它可能包含在系統宕機之前沒有歸檔的日誌。
- 清除集群數據目錄下以及您正在使用的任何表空間的根目錄下的所有現有文件和子目錄。
- 從基本備份中恢復數據庫文件。請注意，以正確的所有權（數據庫系統使用者，而不是 root！）和正確的權限來恢復它們。如果您正在使用表空間，您應該驗證 pg_tblspc/ 中的符號連結是否已正確恢復。
- 刪除 pg_xlog/ 中存在的所有文件；這些來自備份轉儲，因此可能已過時而不是目前。如果您根本沒有歸檔 pg_xlog/，則重新創建它，如果您之前以這種方式設置過，請注意確保將其重新建立為符號連結。
- 如果您在步驟 2 中保存了未歸檔的 WAL 段文件，請將它們複製到 pg_xlog/。（最好是複制它們，而不是移動它們，這樣如果出現問題，你仍然有未修改的文件，你必須重新開始。）
- 在集群數據目錄中創建恢復命令文件 recovery.conf（請參閱恢復設置）。您可能還想臨時修改 pg_hba.conf 以防止普通使用者連接，直到您確定恢復已成功。
- 啟動伺服器。伺服器將進入恢復模式並繼續讀取它需要的存檔 WAL 文件。如果由於外部錯誤而終止恢復，則可以簡單地重新啟動伺服器並繼續恢復。恢復過程完成後，伺服器會將recovery.conf 重命名為recovery.done（以防止以後發生崩潰時意外重新進入恢復模式），然後開始正常的數據庫操作。
- 檢查數據庫的內容以確保您已恢復到您想要的位置。如果沒有，請返回步驟 1。如果一切正常，請通過將 pg_hba.conf 恢復為正常來讓您的使用者進入。