調試postgres 9.0.1表損壞

我有一個9.0.1數據庫有兩個損壞的表（一個表有20行，其他140）。似乎細進行讀/選擇操作，但在表中產生錯誤消息更新某些行的表：調試postgres 9.0.1表損壞

update media set updated_at = now() at time zone 'UTC';

錯誤：在文件無法讀取塊2「鹼/16485分之16384」：只讀0的8192個字節

update media_status set updated_at = now() at time zone 'UTC';

2011-04-14 0點15分15秒UTC ERROR：不能在文件讀取塊3 「鹼/16543分之16384」：只讀0 8192個字節
2011-04- 14 00:15:15 UTC STATEMENT：update'media_status set updated_at = now（）at'UTC';

檢查損壞的文件在文件系統中（Linux）的，它們不是零字節： LL鹼/一萬六千四百八十五分之一萬六千三百八十四 -rwx ------ 1個Postgres的postgres的16384 2011-04-07 9時43基地/ 16384/16485

我運行了一個「真空（FULL，VERBOSE）」命令和腐敗（至少在更新上的錯誤）已經消失。預計「真空（FULL）」命令是否會/可以修復表損壞？這是否提供了可能發生的線索？

有什麼方法可以確定如何/何時發生這種腐敗？

我懷疑它可能發生在文件系統級備份期間（即pg_start_backup（），tar -czf ...，pg_stop_backup（）），因爲我執行了備份並將數據庫移至其他系統。恢復文件並啓動postgres後，我開始收到這些錯誤。我曾嘗試使用相同的tar歸檔進行多次恢復（在不同的系統上）。

感謝，丹

來源

2011-04-14 Dan B

很難做出這一情況明確的說法，但我會調查的存儲層。短讀取像錯誤消息通常表示在本地，通常連接的存儲上「不可能發生」。因此，如果您有SAN，NAS，NFS，一些不重要的RAID配置或其他感興趣的東西，請在那裏檢查日誌或錯誤計數器。

如果這些文件存在，那麼這意味着它不是PostgreSQL中的損壞。

有一件事本來會很有趣，但現在可能已經太遲了，那就是嘗試手動讀取文件，看看會發生什麼。

VACUUM FULL修正了這個問題，可能只是因爲它將表格完全重寫到新文件中，所以無論是什麼原因導致舊文件的混搭都消失了。

來源

2011-04-14 04:42:22

謝謝@Peter，這是僅使用本地存儲（RAID 1）。我實際上仍然有文件損壞版本的副本，但不知道如何解釋/讀取它們。我能夠'貓'他們。 – 2011-04-14 15:52:29

調試postgres 9.0.1表損壞

回答

相關問題