Postgres 恢復不清楚的行為
我有以下內容：2 個節點，其中一個是目前生產數據庫，另一個用於故障恢復。我使用以下命令在第一個節點上進行了基本備份
pg_basebackup -h 127.0.0.1 -U postgres -D bckp -Ft -z -P -R -x並獲得了 bacup 文件base.tar.gz。現在我正在嘗試在故障轉移節點上恢復它。我清除了數據目錄並解壓縮了備份的內容。由於我不需要來自主節點的 wal 日誌流式傳輸到此伺服器，因此我應該recovery.conf使用至少restore_command指定將 wal 日誌從存檔目錄複製到xp_log. 但它已經在裡面了xp_log。有文件000000010000000000000017。由於我是 postgres 和 linux 的新手，我決定將此文件移動到archive目錄並將recovery.conf內容設置為restore_command = 'cp /var/lib/postgresql/archive/%f /var/lib/postgresql/data/%p'然後啟動 postgres。它列印了 ot 日誌2015-10-26 14:06:16 UTC [16-3] LOG: starting archive recovery 2015-10-26 14:06:16 UTC [16-4] LOG: restored log file "000000010000000000000017" from archive 2015-10-26 14:06:16 UTC [16-5] LOG: redo starts at 0/17000060 2015-10-26 14:06:16 UTC [16-6] LOG: consistent recovery state reached at 0/17000160 cp: cannot stat ‘/var/lib/postgresql/backup/000000010000000000000018’: No such file or directory 2015-10-26 14:06:16 UTC [16-7] LOG: redo done at 0/17000160 2015-10-26 14:06:16 UTC [16-8] LOG: restored log file "000000010000000000000017" from archive cp: cannot stat ‘/var/lib/postgresql/backup/00000002.history’: No such file or directory 2015-10-26 14:06:16 UTC [16-9] LOG: selected new timeline ID: 2 cp: cannot stat ‘/var/lib/postgresql/backup/00000001.history’: No such file or directory 2015-10-26 14:06:16 UTC [16-10] LOG: archive recovery complete 2015-10-26 14:06:17 UTC [16-11] LOG: MultiXact member wraparound protections are now enabled 2015-10-26 14:06:17 UTC [30-1] LOG: autovacuum launcher started 2015-10-26 14:06:17 UTC [1-2] LOG: database system is ready to accept connections最後它恢復並正常工作，但對我來說有一些不清楚的時刻：
000000010000000000000017我理解的恢復，但為什麼它試圖恢復000000010000000000000018，因為它不存在？00000002.history和文件是什麼00000001.history以及為什麼它試圖找到它們？
關於您的問題，請完整閱讀文件，因為它解決了您的所有問題。
就尋找
000000010000000000000018它何時不存在而言..恢復過程只是解析所有 WAL 文件，直到遇到“EOF”.. 這通常發生在它嘗試從下一個 WAL 文件讀取但它不存在時..所以它使用這種情況作為恢復過程的終止點。這裡的重要一點是它到達了恢復過程中的一個檢查點，如consistent recovery state reached at 0/17000160. 這意味著您的恢復是可靠的。連續歸檔文件第 24.3.5 節。- 時間線
可以說，時間線是 Postgres 處理“備用宇宙”的一種方式……例如，如果你的複制以某種方式搞砸了，突然你將奴隸提升為主人狀態（而你的主人從未去過下）…有些機器仍在向主機寫入，而有些機器仍在向從機寫入。但是沒關係，因為對目前主機的寫入都將發生在時間線 1 上，而對從機的寫入將全部發生在時間線上2 ..所以理論上你仍然可以將所有更改合併在一起（儘管我相信這並不容易）..我想它類似於版本控制系統中的一個分支。除了沒有真正的“樹幹”。
對於那裡的 postgres 大師 - 如果我有任何不正確的地方，請糾正我。:)