從 Postgres FATAL 中恢復：無法打開文件 pg_tblspc/

我在 Ubuntu 10.04 上執行了一個相當大的 PostgreSQL 9.1.3。數據分佈在多個表空間 = 物理驅動器上。

其中一個驅動器消失了，因此該表空間的目錄不再存在。例如：我失去了“pg_tblspc/176967555”中的符號連結連結到的目錄。

好吧。狀態：重新啟動後，該 DBMS 沒有出現錯誤。雖然無法訪問該特定數據庫

psql：致命：無法打開文件 pg_tblspc/176967555/

我試圖簡單地將這些文件夾創建為空，但是 PG 想要在該目錄中創建一個文件PG_VERSION，pg_filenode.map我不能簡單地創建它。

受影響數據庫中 90% 的數據儲存在其他健全的表空間中。但我無法訪問數據庫中的任何表，因為有些表儲存在現已消失的表空間中。

我的目標是從未受影響的表空間中讀取數據。如果 postgres 只刪除該表空間上的任何內容，那會很好。

我從失去的表空間目錄中恢復了大部分文件（例如 pg_tblspc/176967555/）。當我將恢復的文件夾放回原位時，PG 在訪問該數據庫時仍然對失去的文件感到不滿——這是一個我無法恢復的文件。

可以用zero_damaged_pa​​ges =true啟動 DBMS來忽略失去的文件嗎？如果zero_damaged_pages打算用於’‘失去文件’’ szenario？編輯：沒有運氣 - 它仍然會抱怨失去的文件：

set zero_damaged_pages = true;
SET
postgres=# \connect problemdb ;
FATAL:  could not open file "pg_tblspc/176967555/PG_9.1_201105231/123304298/135285149": No such file or directory

我有哪些選擇？

我應該繼續嘗試用損壞的表空間恢復數據庫嗎？這個討論似乎提供了一些關於如何在單個文件失去時恢復的提示。我可以以某種方式使用 dd 創建這些文件嗎？

我應該嘗試使用pg_filedump從二進製文件中獲取所需的表嗎？

有人在 2009 年的 postgres 郵件列表上討論了將表空間導入新數據庫的選項，但似乎沒有辦法。

這不是一個很正常的崩潰場景嗎：某個文件已經消失了——而您仍然不想訪問儲存在其他文件中的表？

非常感謝您的幫助。史蒂夫

首先要做的是複制您仍然擁有的任何數據文件，並確保它和任何備份的安全，直到您完成恢復工作很久之後。請閱讀此（簡短）Wiki 頁面：

http://wiki.postgresql.org/wiki/Corruption

一旦你這樣做了，你可以嘗試各種恢復策略，而不用擔心你會因為嘗試而變得更糟，超出了嘗試所需的時間。一般來說，我建議仔細遵循文件中描述的技術之一——試圖偷工減料或創造性往往會導致腐敗。只有對 PostgreSQL 內部有很好理解的經驗豐富的專家才應該嘗試偏離記錄的步驟。

你沒有描述你的備份策略；那裡可用的詳細資訊可能會建議您沒有其他選擇。

最後，如果您有未備份的有價值數據，您可能需要手動編輯系統表以消除對失去表空間的引用。這不適合膽小的人。您可以與許多公司簽訂此類服務的契約，其中許多公司都有從此類災難性硬體故障中恢復的經驗。

http://www.postgresql.org/support/professional_support/

我不隸屬於任何這些公司。

@bachr 的回答幫助了我。

就我而言，我嘗試了幾次手動啟動服務，但同時被中斷了。因此，我訪問了 bin 文件夾中的日誌文件，閱讀後，我了解到問題是由失去的文件夾引起的。在每個錯過並手動創建的文件夾中，我嘗試再次啟動服務，但沒有成功……但是，每次嘗試時，日誌文件都會給我帶來另一個錯過的文件夾（要創建）。

因此，這是要在數據文件夾中創建的失去文件夾列表：

• pg_tblspc
• pg_replslot
• pg_twophase
• pg_stat
• pg_commit_ts
• pg_logical/快照 （注意：這是一個子文件夾）
• pg_logical/映射 （注意：這是一個子文件夾）

希望對您有所幫助！

再見

引用自：https://dba.stackexchange.com/questions/17481