☰

找不到「時間軸歷史文件」來使複製工作

tag-icon • tag-icon postgresql replication
找不到「時間軸歷史文件」來使複製工作

我正在運行 PostgreSQL 9.4，試圖讓複製繼續進行。

我正在做的事情，從維基百科上的說明和文件:

  1. SELECT pg_start_backup('clone', true);
  2. rsync資料庫到可能的副本
  3. SELECT pg_stop_backup();
  4. rsync將資料夾pg_xlog複製到想要的副本

我啟動副本，它說：

LOG:  fetching timeline history file for timeline 3 from primary server
FATAL:  could not receive timeline history file from the primary server:
    ERROR:  could not open file "pg_xlog/00000003.history": No such file or directory

當然，我正在兩台伺服器上尋找該.history文件pg_xlog/，但沒有。

我正在瀏覽文件以找出這一點

若要使用備份，您需要保留檔案系統備份期間和之後產生的所有 WAL 段檔案。為了幫助您完成此操作，pg_stop_backup 函數會建立一個備份歷史文件，該文件立即儲存到 WAL 歸檔區域中。該檔案以檔案系統備份所需的第一個 WAL 段檔案命名。例如，如果起始 WAL 檔案是 0000000100001234000055CD，則備份歷史記錄檔案的名稱將類似於 0000000100001234000055CD.007C9330.backup。

然而，碰巧的是，在我這樣做之後，pg_stop_backup()仍然沒有這樣的東西pg_xlog/，也沒有任何地方。

那我從哪裡可以獲得這個「時間軸歷史文件」呢？

答案1

根據六對二發布後，您可能只能創建一個文件，然後它將繼續進行複製設置，但本質上這是一個 PostgresSQL 錯誤，它需要此文件，即使它不適用或根據操作已刪除。

筆記： 對於 Postgresql 10 及更高版本，該函數已重新命名為pg_current_wal_lsn()

當 PostgreSQL 升級新的主伺服器時，它會以放置在 WAL 檔案目錄中的小文字檔案的形式建立時間軸分割的標記。該文件使得在一些相當複雜的故障轉移和故障恢復場景下實現時間點恢復成為可能。

所以看來您必須重新建立該文件。你可以找到一個 非常好的總結 Postgres wiki 上的 .history 檔案。不過，由於資訊採用 .pdf 格式，因此索引起來往往比較困難，因此，如果您還不知道該文件的存在，則可能很難找到該文件。

但我們永遠不會回到那個時間線，因為那是在我們升級之前。重新建立遺失的檔案所需的只是一個足夠好的數字。你可以透過運行獲得一個：

# SELECT pg_current_xlog_location();
 pg_current_xlog_location
--------------------------
 1/38F70328
(1 row)

使用這些值在 WAL 目錄中模擬一個 .history 文件，以此類推。副本將立即能夠啟動。

來源

使用這些（上面）結果建立文件，但使用每個錯誤的預期名稱。

更多資源

  • 了解 PostgreSQL 時間表

  • 系統管理功能

    姓名： pg_current_xlog_location()

    返回類型： 文字

    描述： 取得目前交易日誌寫入位置

    pg_current_xlog_location以與上述函數使用的相同格式顯示目前交易日誌寫入位置。類似地，pg_current_xlog_insert_location 顯示目前交易日誌插入點。插入點是交易日誌在任何時刻的「邏輯」末尾，而寫入位置是實際從伺服器內部緩衝區寫出的內容的末尾。寫入位置是可以從伺服器外部檢查的內容的末尾，如果您有興趣歸檔部分完整的交易日誌文件，通常就是您想要的位置。插入點主要用於伺服器調試目的。這些都是唯讀操作，不需要超級使用者權限。

    您可以使用pg_xlogfile_name_offset從上述任何函數的結果中提取相應的交易日誌檔案名稱和位元組偏移量。

    同樣，pg_xlogfile_name僅提取交易日誌檔案名稱。當給定的交易日誌位置恰好位於交易日誌檔案邊界時，這兩個函數都傳回前一個交易日誌檔案的名稱。這通常是管理交易日誌歸檔行為所需的行為，因為前一個檔案是目前需要歸檔的最後一個檔案。

    來源

相關內容